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

If -spkreuse=0, ensure transactions in mempool always have unique scriptPubKeys #9749

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@luke-jr
Member

luke-jr commented Feb 13, 2017

Exceptions:

  • Multiple inputs in the same transaction are allowed to spend against the same scriptPubKey
  • The same scriptPubKey may be used in the mempool as both first an output, and then spent in a later transaction's input

Changes since original 2013 patch (pre-squashed):

  • Refactor: Move CScript::ScriptPubkeyReuseHash to ScriptHashkey(CScript) in txmempool
  • Update mempool duplicate-scriptPubKey limiting with C++11 and misc formatting improvements
  • Bugfix: Use bitwise operators for mempool SPK states
  • Use CValidationState for SPK reuse rejections
  • Move mapTxSPK to CTxMemPoolEntry.mapSPK
  • Make SPK reuse filtering optional (use -spkreuse)

Known issues:

  • This breaks RBF in most usage scenarios.
  • Someone could watch for transactions and spam dust to block them on nodes using this.
@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Feb 13, 2017

Member

@sdaftuar pointed out on IRC that someone could watch the p2p network and screw up people by sending dust to SPKs they see. I also noticed this breaks common RBF usage since the SPK conflict rejects the transaction before it can be replaced.

To address both of these, I refactored the logic so that it treats non-inherent (that is, within the same tx) SPK conflicts in the same manner as TxIn conflicts. Although in the SPK case, the RBF optin flag is ignored, and a conflict in the parents of the transaction don't cause a DoS ban.

Member

luke-jr commented Feb 13, 2017

@sdaftuar pointed out on IRC that someone could watch the p2p network and screw up people by sending dust to SPKs they see. I also noticed this breaks common RBF usage since the SPK conflict rejects the transaction before it can be replaced.

To address both of these, I refactored the logic so that it treats non-inherent (that is, within the same tx) SPK conflicts in the same manner as TxIn conflicts. Although in the SPK case, the RBF optin flag is ignored, and a conflict in the parents of the transaction don't cause a DoS ban.

@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Feb 13, 2017

Member

As mentioned on IRC, I'm opposed to this feature. Would not object to more optional safeguards against reuse in the wallet code though.

Member

morcos commented Feb 13, 2017

As mentioned on IRC, I'm opposed to this feature. Would not object to more optional safeguards against reuse in the wallet code though.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Feb 14, 2017

Member

And as mentioned on IRC, I don't like the idea of changing Core's direction to where it is no longer a reference implementation, but a specific political agenda to the exclusion of others. If you don't like the feature, just don't use it.

Member

luke-jr commented Feb 14, 2017

And as mentioned on IRC, I don't like the idea of changing Core's direction to where it is no longer a reference implementation, but a specific political agenda to the exclusion of others. If you don't like the feature, just don't use it.

@sdaftuar

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Feb 14, 2017

Member

@luke-jr Please explain in the pull request, and ideally in code comments, what this patch is intended to do and why. Concept NACK policy change PRs that are made without providing motivation.

Member

sdaftuar commented Feb 14, 2017

@luke-jr Please explain in the pull request, and ideally in code comments, what this patch is intended to do and why. Concept NACK policy change PRs that are made without providing motivation.

@luke-jr

This comment has been minimized.

Show comment
Hide comment

luke-jr added some commits Feb 13, 2017

If -spkreuse=0, ensure transactions in mempool always have unique scr…
…iptPubKeys

Exceptions:
- Multiple inputs in the same transaction are allowed to spend against the same scriptPubKey
- The same scriptPubKey may be used in the mempool as both first an output, and then spent in a later transaction's input
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment