Bitcoin Forum
December 12, 2024, 04:44:32 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Miners: Don't deprioritise/filter address reuse!  (Read 744 times)
Syke (OP)
Legendary
*
Offline Offline

Activity: 3878
Merit: 1193


View Profile
November 24, 2013, 06:03:28 AM
 #1

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.

Buy & Hold
BurtW
Legendary
*
Offline Offline

Activity: 2646
Merit: 1138

All paid signature campaigns should be banned.


View Profile WWW
November 24, 2013, 06:07:04 AM
 #2

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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
Syke (OP)
Legendary
*
Offline Offline

Activity: 3878
Merit: 1193


View Profile
November 24, 2013, 03:55:14 PM
 #3

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.

Buy & Hold
Syke (OP)
Legendary
*
Offline Offline

Activity: 3878
Merit: 1193


View Profile
November 24, 2013, 04:23:40 PM
 #4

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.

Buy & Hold
Zelek Uther
Hero Member
*****
Offline Offline

Activity: 700
Merit: 504


Run a Bitcoin node.


View Profile
November 24, 2013, 07:02:44 PM
 #5

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

Run a Bitcoin node, support the network.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!