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
flips nonce/non-nonce blockhash check #25711
Conversation
7fe8ae5
to
9b84bc5
Compare
9b84bc5
to
7e6abf2
Compare
7e6abf2
to
bcab86a
Compare
bcab86a
to
9f1cd5a
Compare
runtime/src/bank.rs
Outdated
| || self.cluster_type() != ClusterType::MainnetBeta | ||
| || self.slot() <= 135986379) | ||
| .then(|| self.check_message_for_nonce(tx.message())) | ||
| .flatten() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, flatten! that's what i was looking for
no, can't produce failure on master. |
i'll try to fix up the test this evening |
sry, changing my mind. this change is insufficient on its own because nonce_account::verify_nonce_account only returns bool. so even with the hash checks swapped, if a transaction leads with a SystemProgram::AdvanceNonceAccount ix, but references some other rbh that's still extant in the queue, we fall back to the non-nonced tx check and the transaction is accepted.
i can pick this up in the morning
|
Hi, is there any ETA for fix of nonce account? My software relies on the nonce account feature for durable transaction due to offline signing. Thank you. |
9f1cd5a
to
35cf451
Compare
36c76ce
to
1c3bf59
Compare
Durable nonce transactions can be executed twice. @t-nelson: > gist is to flip the nonce/non-nonce blockhash check so that whether a > durable nonce transaction is flagged is not dependent up whether the > blockhash is extant in the rbh queue
adcd09e
to
d043479
Compare
@t-nelson How about the last commit here? The code is now distinguishing between cases where:
Whereas transaction message is referring to a durable nonce address but:
|
d043479
to
a3cff7e
Compare
|
Added a 2nd feature activation:
This should prevent double execution at epoch boundary when the 1st feature is activated. |
| &self, | ||
| message: &SanitizedMessage, | ||
| ) -> std::result::Result<TransactionAccount, NonceError> { | ||
| let nonce_address = message | ||
| .get_durable_nonce(self.feature_set.is_active(&nonce_must_be_writable::id())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to plumb NonceError through here and discern between the SystemProgram::AdvanceNonceAccount marker ix existing (nonced tx or not) and the referenced nonce account not existing (nonced tx that's going to fail)
| let nonce_account = self | ||
| .get_account_with_fixed_root(nonce_address) | ||
| .ok_or(NonceError::NonceAccountNotFound)?; | ||
| if nonce_account::verify_nonce_account(&nonce_account, message.recent_blockhash()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was considering plumbing NonceError through here too, so we can discern between an invalid nonce account and a blockhash mismatch, but I think it'd just be informational (and we'd eat that info immediately)
|
Will this be closed in favor of #25744 ? |
We'll release guidance on this soon once the patch is finalized |
Thank you for the answer! I accidentally posted the question in this issue so deleted it and posted in the more recent issue. |
Problem
Durable nonce transactions can be executed twice.
Summary of Changes
@t-nelson: