If we already have a transaction, don’t add it to recentRejects
Now, we only add a transaction to our recentRejects filter if we didn’t already have it, meaning that it is added at most once, as intended.
If we already have a transaction, don’t add it to recentRejects
Now, we only add a transaction to our recentRejects filter if we didn’t already have it, meaning that it is added at most once, as intended.
Concept ACK
Looks like the p2p_permissions.py
test is failing
https://travis-ci.org/github/bitcoin/bitcoin/jobs/718732253#L3341
145@@ -146,7 +146,7 @@ def check_tx_relay(self):
146 [tx],
147 self.nodes[1],
148 success=False,
149- reject_reason='Not relaying non-mempool transaction {} from forcerelay peer=0'.format(txid),
150+ reject_reason='{} from peer=0 was not accepted: txn-mempool-conflict'.format(txid)
I think to fully test that sending an invalid transaction from a forcerelay peer doesn’t result in the tx being relayed, you’d need to add:
0+ p2p_rebroadcast_wallet.send_txs_and_test(
1+ [tx],
2+ self.nodes[1],
3+ success=False,
4+ reject_reason='Not relaying non-mempool transaction {} from forcerelay peer=0'.format(txid)
5+ )
6+
The first time the transaction is sent, it’s rejected and not added to the mempool, but is added to recentRejects. The second time the transaction is sent, we AlreadyHave it and choose not to relay it because it’s not in the mempool.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
2988+ LogPrintf("Not relaying non-mempool transaction %s from forcerelay peer=%d\n", tx.GetHash().ToString(), pfrom.GetId());
2989+ } else {
2990+ LogPrintf("Force relaying tx %s from peer=%d\n", tx.GetHash().ToString(), pfrom.GetId());
2991+ RelayTransaction(tx.GetHash(), tx.GetWitnessHash(), connman);
2992+ }
2993+ }
An early return would simplify the code flow
0 }
1 return;
Neither state
, nor lRemovedTxn
will be set, so there is no need for the fallthrough over 200 LOC for nothing.
state
and lRemovedTxn
can now be moved down to after the return. They are not needed in this scope at all
One could also argue that all txs accepted to the mempool should be added to recentRejects
No. That’s completely changing the meaning of recentRejects.
Concept ACK
Looks like the
p2p_permissions.py
test is failinghttps://travis-ci.org/github/bitcoin/bitcoin/jobs/718732253#L3341
git range-diff master 95134c8 47132bb
I’ll leave any idea changes to recentRejects for a follow-up.
145@@ -146,7 +146,14 @@ def check_tx_relay(self):
146 [tx],
nit: Could add a comment here that this first relay is only needed to make the node think it already has the transaction
(sorry for leaving nits in succession instead of in one reply, feel free to ignore)
git range-diff master 47132bb 68bb294
I wanted to point out the slight behaviour change with regard to rbf’ed txs, but that doesn’t seem to open any issues.
Approach ACK
anyone track this regression’s origin? concept ack
utACK 68bb2940d9589d6a7146916c8096c22aafaf047e
One request for better commenting. Not essential.
I’ve rebased and added the suggested comment here: #19753 (review)
Also removed the second commit, which wasn’t necessary as part of this fix.
git range-diff master 9bcdd34 f996019
Trivial rebase
Now, we only add a transaction to our recentRejects filter if we didn't
already have it, meaning that it is added at most once, as intended.
git range-diff master f996019 d419fde
PR Status: Ready For Review
Should be quick for anyone interested 😄
troygiorshev
benthecarman
amitiuttarwar
jnewbery
DrahtBot
MarcoFalke
guardian939
instagibbs
jonatack
laanwj
Milestone
0.21.0