Miners: Don't deprioritise/filter address reuse!

Zelek Uther

hero member

Activity: 700

Merit: 504

Run a Bitcoin node.

Quote from: Syke on November 24, 2013, 11:23:40 AM

Quote from: Luke-Jr on November 16, 2013, 04:09:30 PM

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://bitcointalksearch.org/topic/miners-time-to-not-deprioritisefilter-address-reuse-337619

Syke

legendary

Activity: 3878

Merit: 1193

Quote from: Luke-Jr on November 16, 2013, 04:09:30 PM

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.

Syke

legendary

Activity: 3878

Merit: 1193

Quote from: Cryddit on November 24, 2013, 10:28:39 AM

Quote from: Syke on November 23, 2013, 11:17:11 PM

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.

Quote

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.

BurtW

legendary

Activity: 2646

Merit: 1137

All paid signature campaigns should be banned.

Quote from: Syke on November 24, 2013, 01:03:28 AM

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

legendary

Activity: 3878

Merit: 1193

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.

Quote from: Luke-Jr on November 16, 2013, 09:29:55 PM

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.

Topic: Miners: Don't deprioritise/filter address reuse! (Read 739 times)