Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop automatic transaction pushing by wallets #17436

Merged
merged 26 commits into from Jan 31, 2024
Merged

Conversation

Quexington
Copy link
Contributor

Recreation of #16314 & #16354 @ main. Two PRs are included because the latter is a bug fix for the former.

Source hash: 008f3ba^..33a053e
Remaining commits: 14

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.
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).
@Quexington Quexington added the Changed Required label for PR that categorizes merge commit message as "Changed" for changelog label Jan 30, 2024
@github-actions github-actions bot added the merge_conflict Branch has conflicts that prevent merge to main label Jan 30, 2024
@Chia-Network Chia-Network deleted a comment from github-actions bot Jan 30, 2024
@github-actions github-actions bot removed the merge_conflict Branch has conflicts that prevent merge to main label Jan 30, 2024
@Chia-Network Chia-Network deleted a comment from github-actions bot Jan 30, 2024
@Quexington Quexington marked this pull request as ready for review January 30, 2024 20:10
@Quexington Quexington requested a review from a team as a code owner January 30, 2024 20:10
@Chia-Network Chia-Network deleted a comment from github-actions bot Jan 30, 2024
Copy link
Contributor

@wjblanke wjblanke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aok

@Starttoaster Starttoaster merged commit 9bdc178 into main Jan 31, 2024
265 checks passed
@Starttoaster Starttoaster deleted the quex.no_auto_push branch January 31, 2024 20:33
Copy link
Contributor

@arvidn arvidn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was interrupted in my review, and missed it. sorry. I think there might be an opportunity for simplification though

*args,
tx_config=tx_config,
extra_conditions=extra_conditions,
**({"push": push} if push is not None else {}),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't looks like the function distinguishes between this argument being passed as True and not being passed at all. wouldn't it look a bit simpler to just say:

Suggested change
**({"push": push} if push is not None else {}),
push = False if push is None else True,

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some cases default to true and some default to false.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah as @AmineKhaldi said, the idea is to omit the push key for the API side default if no value is specified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changed Required label for PR that categorizes merge commit message as "Changed" for changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants