Bitcoin Forum

Bitcoin => Mining => Topic started by: Syke on November 24, 2013, 06:03:28 AM


Title: Miners: Don't deprioritise/filter address reuse!
Post by: Syke on November 24, 2013, 06:03:28 AM
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 17, 2013, 02:29:55 AM
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.

Title: Re: Miners: Don't deprioritise/filter address reuse!
Post by: BurtW on November 24, 2013, 06:07:04 AM
Quote from: Syke on November 24, 2013, 06: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.

Title: Re: Miners: Don't deprioritise/filter address reuse!
Post by: Syke on November 24, 2013, 03:55:14 PM
Quote from: Cryddit on November 24, 2013, 03:28:39 PM
Quote from: Syke on November 24, 2013, 04:17:11 AM
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.

Title: Re: Miners: Don't deprioritise/filter address reuse!
Post by: Syke on November 24, 2013, 04:23:40 PM
Quote from: Luke-Jr on November 16, 2013, 09: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.

Title: Re: Miners: Don't deprioritise/filter address reuse!
Post by: Zelek Uther on November 24, 2013, 07:02:44 PM
Quote from: Syke on November 24, 2013, 04:23:40 PM
Quote from: Luke-Jr on November 16, 2013, 09: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://bitcointalk.org/index.php?topic=337619.0


Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines