chore: merge development into feature dan #4764
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add lint to prevent dbg! in repo
Description --- - Send compact inputs when the full block is requested - Only load full inputs when required Motivation and Context --- Full blocks are requested if any transactions are missing. This PR reduces the size of those full blocks. This also improves slightly optimizes block sync by removing the need to load inputs for blocks that are being sent. How Has This Been Tested? --- Modified existing rust integration test to include a single transaction, forcing reconcile block to request the full block and testing the fetching of full inputs from the local db.
Description --- Adds in the ability to retrigger the mempool sync if a larger re_org or block sync occurred. Motivation and Context --- As of tari-project#4706 the mempool will now properly handle re-orgs and block syncs. But when the base_node is not at the "correct" tip its mempool will reject all invalid transactions. In order to get those transactions back, we need to trigger a mempool sync. This adds in a new config setting to control the maximum number of blocks the base_node added during a reorg or sync before it starts a sync process. The assumption is that in most cases, the blocks removed will be less or the same as the blocks added, so we only need to look at the blocks added. Open Questions --- Do we just sync to one peer, or do we sync to `initial_sync_num_peers` peer? Prerequisite ---- Requires: tari-project#4706
…ct#4737) Description --- Changes the mempool to look at insertion time and not input maturity. These changes reflect the new updated [mempool rfc](tari-project/rfcs#13) Motivation and Context --- The current code looks at the min input maturity, aka spending the oldest input, as an equalizer on the fee_per_gram when determining the transaction to pick for mining. This check is moot as even our default implementation of transaction sending uses 0 for all transactions except the coinbases which have their maturity checked on consensus rules. This means that most users will just keep that 0 as its not enforceable and, it will in most cases be 0, meaning this check is moot. This update adds in a local time as the equalizer for the same fee_per_gram so that we still choose the oldest transactions to put in a block. Adding in this behavior gives preference to older transactions and is desireable for the network as it means most transactions will be mined at some point, and it won't lead to stale transactions sitting in a mempool.
Description --- Disallow onion v2 addresses. tari-project#4681
Description --- Uses correct path for proto files for nodejs wallet client Motivation and Context --- NodeJS clients were put in `nodejs` directory, however the relative path to the proto files were not updated How Has This Been Tested? --- Running integration tests
Description --- Fix the burn cli cucumber. The command run for wallet didn't start with grpc. And the wallet in non-interactive mode without grpc will not start. So it was not in sync with the base node. Modify the standard cucumber burn test to do the same as the cli test. How Has This Been Tested? --- npm test -- --name "As a user I want to burn tari via command line"
Description --- - Adds ToRistrettoPoint opcodes - Added scalar stack item Motivation and Context --- As per RFC-202 Ref tari-project/rfcs#15 Ref tari-project#4742 How Has This Been Tested? --- Additional unit tests + tests updated
…ll_request (tari-project#4757) Description add cargo cache, reduce Ubuntu dependencies and action on pull_request Motivation and Context Make CI faster, use the same Ubuntu dependencies and run on pull_requests How Has This Been Tested? Tested mostly in local fork
…ari-project#4748) Description --- - adds migration to remove peers with onionv2 addresses Motivation and Context --- Nodes are transmitting peers with (now invalid) onionv2 addresses and getting banned. How Has This Been Tested? --- Checking that migration was run in logs
Description --- Provides more context and background on how the emission parameters are derived and why some design choices (1-e) vs (k) were made. Hopefully this helps auditors understand the motiviation behind the code. Motivation and Context --- Helps illuminate a crucial, yet somewhat difficult part to grok, of the codebase How Has This Been Tested? --- Doc changes only
…ssaging (tari-project#4753) Description --- - Encrypt, decrypt and message padding mutate a single buffer for encrypted messages Motivation and Context --- Encrypted message handling should be as efficient as possible. The previous implementation performed allocations of the full padded message size twice for encryption and twice for decryption. Increasing memory usage, and negating the performance benefits of using an encryption keystream. This PR allocates a single buffer for the message to be de/encrypted and de/encrypts the contents in-place using the BytesMut type from the `bytes` crate. How Has This Been Tested? --- This change is backwards compatible, tested on current esme network and updated existing tests as required. Discovery: OK Memorynet: OK PingPong: OK InteractiveTransactions: OK SafTransactions: OK
…blished (tari-project#4756) Description --- Ensures that connectivity status events are always published if a status change has occurred. Motivation and Context --- An online/degraded event should be emitted if any connections are present, including if only connected to walllets. Some edge cases where connectivity status event was not emitted. These events are typically only used for logging and tests, but could be used in an application to wait for conenctivity to become available. How Has This Been Tested? --- Added to existing unit test, manually with DAN node
Description --- Run coverage on all PRs Motivation and Context --- Currently, this is only run after merge. This is often missed. With fewer PRs, and a more stable code base, I think we can run it on every PR How Has This Been Tested? --- Since this is CI related, I'll be using the PR itself to test
Description --- Broken doctest Motivation and Context --- https://github.com/tari-project/tari/actions/runs/3174089465/jobs/5170456712 How Has This Been Tested? --- cargo test --doc
…ct#4755) Description --- Use different _default_ GRPC ports for different networks - BaseNode - Dibbler: 18122 - Esmeralda: 18142 - Igor: 18152 - ConsoleWallet - Dibbler: 18123 - Esmeralda: 18143 - Igor: 18153 Motivation and Context --- More explicit separation of networks allowing GRPC to work when running two different networks on the same machine. How Has This Been Tested? --- Manually
* development: v0.38.5 feat: different default grpc ports for different networks (tari-project#4755) fix(core): broken doctests (tari-project#4763) ci: fix coverage job ci: run coverage on prs (tari-project#4738) fix(comms): fixes edge case where online status event does not get published (tari-project#4756) fix(dht/encryption): greatly reduce heap allocations for encrypted messaging (tari-project#4753) docs: explain the emission curve parameters (tari-project#4750) fix(comms/peer_manager): add migration to remove onionv2 addresses (tari-project#4748) fix(ci): add cargo cache, reduce Ubuntu dependencies and action on pull_request (tari-project#4757) feat(tariscript): adds ToRistrettoPoint op-code (tari-project#4749) fix: cli wallet cucumber (tari-project#4739) fix(clients): fix tari nodejs client proto paths (tari-project#4743) chore: disallow onion v2 (tari-project#4745) feat: change priority in mempool to take into account age (tari-project#4737) feat: trigger mempool sync on lag (tari-project#4730) fix(core): use compact inputs for block propagation (tari-project#4714) ci: deny dbg macro (tari-project#4740)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Merge development into feature dan