Unify transaction pushing #17458
Merged
Unify transaction pushing #17458
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
…end_clawback_coins
…ve_ignore_max_send_amount
…tx_pushing_optional
…tx_pushing_optional
…ve_ignore_max_send_amount
…ve_ignore_max_send_amount
…tx_pushing_optional
…ve_ignore_max_send_amount
This is a very old parameter that we've been propogating through new version of generate signed transaction for (it seems to me) no reason. The only instances in which this parameter is actually set to `True` we manually specify the set of coins anyway. Perhaps the idea is to prevent choosing coins that won't fit in a block, but such an unlikely error will still get caught by the mempool and there's a million other similar errors that would behave that way as well. I think more likely the intention was simply for testing in tests that have since been re-written or deleted.
…tx_pushing_optional
This PR is a step in the direction of a more observer-style wallet. Currently, most of our wallet functions just push directly to the network as a matter of course when creating a transaction. While this is convenient (especially in tests) it will be impossible should we get to a wallet design that does not contain the private key as a key component to wallet operations. For now, the wallet still signs the transaction and has it ready to be pushed to the network should the user specify that. But all of the pushing logic has been migrated to the top-most layer available (usually the RPC) so that the user always has control over whether or not they would like to immediately push the transaction. In addition, any transaction method in the RPC now returns a `"transactions"` key so that it is easy for a front-end client to have everything they need to push the transaction as if the wallet was doing it (using the `push_transactions` endpoint).
…end_clawback_coins (#16354) Previously, this logic depended on pushing clawback transactions to the wallet DB to be submitted so that on further transaction generations, the same coins would not be selected. With the change to make all transaction pushing optional, this logic no longer functioned correctly. This change leverages the `excluded_coin_ids` key in the `TXConfig` to exclude coins between transaction batches instead, resulting in a stateless generation of these transactions (fitting the new pattern).
The main section of this change is here: https://github.com/Chia-Network/chia-blockchain/pull/16346/files#diff-a367f650aed3b60eba2c253ce15852630c1baf5e9891223d1557ac9cb3333d20L1995 Right now, there exists two different ways of pushing transactions and wallets seem to use either almost arbitrarily. This change combines the `Wallet.push_transaction` and `WalletStateManager.add_pending_transaction` into a single method that includes the union of their two functionalities. In addition, this method now takes a list of transactions by default and will consolidate the spend bundles of all of transactions onto the first transaction in the list to ensure that all transactions make it into the mempool at the same time. Most wallets already do this manually and I have not refactored them not to do so (yet) but this gives the option for wallets going forward to not have to worry about that particular aspect.
Source hash: bf4cdf2 Remaining commits: 17 Merge conflict resolutions: https://quexington.github.io/merge-diffs/f7ecf6e05303b72b63b30d974d0518331debe6b3.html
…long_lived_vault_from_main_e986d1e3eead6badf43dc7fdd54292f8a43fde18
source hash: e986d1e remaining commits: 0 merge diffs: https://quexington.github.io/merge-diffs/f5f93cac60e894a74c8d5ba4aae0a1fac9328323.html
Quexington
added
the
Changed
|
this seems ok to me - probably could use a second look from Arvid or Amine |
arvidn
reviewed
Feb 2, 2024
Quexington
added
ready_to_merge
Pull Request Test Coverage Report for Build 7787191505Warning: This coverage report may be inaccurate.We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
💛 - Coveralls |
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.
Recreation of #16346 @ main
Source hash: 3b1fcf2
Remaining commits: 14