Skip to content

Conversation

troygiorshev
Copy link
Contributor

@troygiorshev troygiorshev commented Aug 17, 2020

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.

@DrahtBot DrahtBot added the P2P label Aug 17, 2020
@benthecarman
Copy link
Contributor

Concept ACK

Looks like the p2p_permissions.py test is failing

https://travis-ci.org/github/bitcoin/bitcoin/jobs/718732253#L3341

@amitiuttarwar
Copy link
Contributor

strong concept ACK! nice find :)

@jnewbery
Copy link
Contributor

Concept ACK

@troygiorshev troygiorshev force-pushed the 2020-08-clean-tx-processing branch from 8d90d0f to 9325a06 Compare August 18, 2020 15:19
@troygiorshev
Copy link
Contributor Author

Fixed the broken test

@jnewbery jnewbery changed the title p2p: fix recentRejects filling bug p2p: don't add AlreadyHave transactions to recentRejects Aug 19, 2020
@jnewbery jnewbery force-pushed the 2020-08-clean-tx-processing branch from 9325a06 to 95134c8 Compare August 19, 2020 09:06
Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

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

utACK. One suggested change to the test.

@@ -146,7 +146,7 @@ def check_tx_relay(self):
[tx],
self.nodes[1],
success=False,
reject_reason='Not relaying non-mempool transaction {} from forcerelay peer=0'.format(txid),
reject_reason='{} from peer=0 was not accepted: txn-mempool-conflict'.format(txid)
Copy link
Contributor

Choose a reason for hiding this comment

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

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:

+        p2p_rebroadcast_wallet.send_txs_and_test(
+            [tx],
+            self.nodes[1],
+            success=False,
+            reject_reason='Not relaying non-mempool transaction {} from forcerelay peer=0'.format(txid)
+        )
+

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, fixed

Copy link
Contributor

Choose a reason for hiding this comment

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

You should also add a comment here to explain why you're sending the transaction twice.

@DrahtBot
Copy link
Contributor

DrahtBot commented Aug 20, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

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.

Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

Not sure if this is the right approach. One could also argue that all txs accepted to the mempool should be added to recentRejects, so that prior versions of rbfed txs will be rejected right away without going through another costly ATMP round. No strong opinion though.

@jnewbery
Copy link
Contributor

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.

@guardian939
Copy link

Concept ACK

Looks like the p2p_permissions.py test is failing

https://travis-ci.org/github/bitcoin/bitcoin/jobs/718732253#L3341

@troygiorshev troygiorshev force-pushed the 2020-08-clean-tx-processing branch from 95134c8 to 47132bb Compare August 24, 2020 16:19
@troygiorshev
Copy link
Contributor Author

git range-diff master 95134c8 47132bb

  • rebase
  • now uses early exit
  • made suggested test change

I'll leave any idea changes to recentRejects for a follow-up.

@troygiorshev troygiorshev force-pushed the 2020-08-clean-tx-processing branch from 47132bb to 68bb294 Compare August 24, 2020 16:57
@troygiorshev
Copy link
Contributor Author

git range-diff master 47132bb 68bb294

  • early return now returns earlier

Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

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

@instagibbs
Copy link
Member

anyone track this regression's origin? concept ack

@jnewbery
Copy link
Contributor

anyone track this regression's origin? concept ack

a9f3d3d#diff-7ec3c68a81efff79b6ca22ac1f1eabbaL4424-L4428

Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

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

utACK 68bb294

One request for better commenting. Not essential.

@@ -146,7 +146,7 @@ def check_tx_relay(self):
[tx],
self.nodes[1],
success=False,
reject_reason='Not relaying non-mempool transaction {} from forcerelay peer=0'.format(txid),
reject_reason='{} from peer=0 was not accepted: txn-mempool-conflict'.format(txid)
Copy link
Contributor

Choose a reason for hiding this comment

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

You should also add a comment here to explain why you're sending the transaction twice.

@jnewbery jnewbery force-pushed the 2020-08-clean-tx-processing branch from 68bb294 to 39b2418 Compare September 4, 2020 08:09
@troygiorshev troygiorshev force-pushed the 2020-08-clean-tx-processing branch 2 times, most recently from d7aa195 to 77ebed1 Compare September 16, 2020 12:46
@troygiorshev troygiorshev force-pushed the 2020-08-clean-tx-processing branch 2 times, most recently from 9bcdd34 to f996019 Compare September 16, 2020 12:52
@troygiorshev
Copy link
Contributor Author

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.
@troygiorshev troygiorshev force-pushed the 2020-08-clean-tx-processing branch from f996019 to d419fde Compare October 28, 2020 02:16
@troygiorshev
Copy link
Contributor Author

troygiorshev commented Oct 28, 2020

git range-diff master f996019 d419fde

  • Rebased

PR Status: Ready For Review

Should be quick for anyone interested 😄

@jnewbery
Copy link
Contributor

Code review ACK d419fde

@jnewbery jnewbery added the Bug label Oct 28, 2020
@laanwj laanwj modified the milestones: 0.21.1, 0.21.0 Oct 28, 2020
@jonatack
Copy link
Member

Concept ACK

@laanwj
Copy link
Member

laanwj commented Oct 29, 2020

Code review ACK d419fde

@laanwj laanwj merged commit 6196cf7 into bitcoin:master Oct 29, 2020
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Oct 29, 2020
…tRejects

d419fde [net processing] Don't add AlreadyHave txs to recentRejects (Troy Giorshev)

Pull request description:

  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.

ACKs for top commit:
  jnewbery:
    Code review ACK d419fde
  laanwj:
    Code review ACK d419fde

Tree-SHA512: cff5c1ba36c4700e2d6ab3eec4a3e51e1bef28fb3cc1bc850c84e06d6e5a9f6c32825207c253cc9cdf596b2eaadb6b5be68b3f8ca752b4ef6c31cf85138e3c99
Copy link
Member

@jonatack jonatack left a comment

Choose a reason for hiding this comment

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

Posthumous ACK d419fde

Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Dec 15, 2021
Summary:
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.

This is a backport of [[bitcoin/bitcoin#19753 |  core#19753]]

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D10681
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants