Miners: Don't deprioritise/filter address reuse!

[Syke]

Since Luke-jr doesn't want to have an actual debate in his thread, I've started a new non-censored thread so a real debate can happen.

Bitcoin is never anonymous, no matter how you use it.

Show me their personal identity. If you cannot provide their personal identity, they are anonymous.

Bitcoin doesn't need slower transaction confirmations. Bitcoin clients need to make unique address use easier.

[1714174418]

1714174418

[1714174418]

1714174418

[1714174418]

1714174418

[BurtW]

Bitcoin clients need to make unique address use easier.

I think we all agree on this.  Everyone should demand BIP32 be implemented in every wallet they use.

[Syke]

Slowing down transactions is not the right way of accomplishing the intented purpose. The right way is to make unique addresses easier to use.

First, this doesn't slow down transactions unless blocks are full (at the 1Mb limit) in which case *some* transactions would be slowed down anyway.  This just gives the *FIRST* transactions to all addresses higher priority than the *SECOND* or later transactions to all addresses.

That's not how it was explained.

this just deprioritises it to one reuse per block.

Read that again. "one reuse per block." The second reuse will be delayed no matter the size of the first block. Delaying transactions is a bad implementation.

[Syke]

This first patch just rejects from your memorypool any transaction which:

• Sends to a scriptPubKey which is already sent to (output) by another transaction in the memorypool.
• Sends to a scriptPubKey which is already being used to redeem a coin (input) by another transaction in the memorypool.
• Sends to the same scriptPubKey in two different outputs, within the same transaction.
• Uses a scriptPubKey to redeem a coin (input) which has already been used to redeem a coin (input) by another transaction in the memorypool.

This patch rejects perfectly valid transactions. This is a very bad patch.

[Zelek Uther]

This first patch just rejects from your memorypool any transaction which:

• Sends to a scriptPubKey which is already sent to (output) by another transaction in the memorypool.
• Sends to a scriptPubKey which is already being used to redeem a coin (input) by another transaction in the memorypool.
• Sends to the same scriptPubKey in two different outputs, within the same transaction.
• Uses a scriptPubKey to redeem a coin (input) which has already been used to redeem a coin (input) by another transaction in the memorypool.

This patch rejects perfectly valid transactions. This is a very bad patch.

Agreed.

Also see https://bitcointalk.org/index.php?topic=337619.0