Miners: Time to deprioritise/filter address reuse!

[Cryddit]

Just a note, but.... 

All those in favor of "open transactions" and "transparency" can achieve it in the post BIP32 world by making their master addresses public. 

IOW, if a charity wants everybody to be able to see all the payments it's recieved and made on a particular issue, wants anybody to be able to donate on a particular issue, etc, they just publish the master address that all those bitcoin addresses are to be derived from, the same way they'd publish the bitcoin address itself now.  You can use the master address to identify payment addresses derived from it. In the "normal" case the master address is a secret between the payer and the payee, but if it's not secret, it doesn't create secrecy.

And if a sandwich shop in bratislavia wants to put a public QR code for making sandwich payments on the menu, it just needs to put the QR code of a master address on the menu; customers can scan it, create a payment address, and pay for their sandwiches.  Now, those customers could also see how much money other customers are spending to that master address so they could tell how much sales in bitcoin are being made at the shop, but if the shop doesn't mind, then they don't mind.   

It isn't a problem as long as the software isn't so braindead that everyone with the same "master" address creates the same payment address.  Right? 

[1715136002]

1715136002

[1715136002]

1715136002

[1715136002]

1715136002

[Cryddit]

Another note, to those who've been claiming that the current patch creates infinite delays in payment processing on addresses that take more than one payment per ten minutes;

With 100% adoption of this patch that would be true, but nobody is now looking at 100% deployment even as a remote possibility.

With 90% adoption of this patch, you'd get one transaction per block on 9/10 of blocks, and then all the transactions that had been delayed, all going through at once, on 10% of the blocks.  So, if for silly reasons you're taking one payment per ten seconds on a given bitcoin address, your expected time to first confirmation for a given transaction would be slightly less than 90 minutes instead of 10 minutes, but without 100% adoption, would not be spiraling to infinity.

Even if every pool adopted this patch you'd still get all your transactions through any time a solo miner who had not adopted the patch solved a single block.

If I'd been writing the patch I'd have hit it in transaction fees instead of delay;  ie, I'd have written a bitcoind/bitcoin-qt patch that made repeat-using a bitcoin address be a nonstandard transaction unless accompanied by an additional transaction fee.  But that would be a much less 'measured and predictable' effect than the patch we're looking at now; it would be more likely to cause chaotic unpredictable failure of such tx that depend on things far more random than this one.  This is more elegant and gentle than what I'd have written, because it is more subtle.

[Peter R]

If I'd been writing the patch I'd have hit it in transaction fees instead of delay.

I think this is what gmaxwell was suggesting: https://bitcointalk.org/index.php?topic=334316.msg3588058#msg3588058

I think we should look at Luke-Jr's patch as just that: a patch.  It is doing the important job of getting the discussion going, but I expect something more along the lines of what gmaxwell proposed (scaling tx priority) is a better long-term solution.  

I don't think anyone wants to "ban" address re-use or make things like Mastercoin unusable.  We just want a reasonable and effective way to incentivize *not* re-using addresses.  If you want to re-use your address then you should be able to: I personally think it should just cost you more in fees to get your TX priority up to what it would have been had you not re-used addresses, but perhaps I am missing something.  

Here's what I want: when a new bitcoin user picks a wallet and begins to use it, the wallet should *by default* not re-use addresses and the user should be none the wiser.  Let's put the right incentives in place to make this happen.  

[Carlton Banks]

Another note, to those who've been claiming that the current patch creates infinite delays in payment processing on addresses that take more than one payment per ten minutes;

With 100% adoption of this patch that would be true, but nobody is now looking at 100% deployment even as a remote possibility.

With 90% adoption of this patch, you'd get one transaction per block on 9/10 of blocks, and then all the transactions that had been delayed, all going through at once, on 10% of the blocks.  So, if for silly reasons you're taking one payment per ten seconds on a given bitcoin address, your expected time to first confirmation for a given transaction would be slightly less than 90 minutes instead of 10 minutes, but without 100% adoption, would not be spiraling to infinity.

Even if every pool adopted this patch you'd still get all your transactions through any time a solo miner who had not adopted the patch solved a single block.

If I'd been writing the patch I'd have hit it in transaction fees instead of delay;  ie, I'd have written a bitcoind/bitcoin-qt patch that made repeat-using a bitcoin address be a nonstandard transaction unless accompanied by an additional transaction fee.  But that would be a much less 'measured and predictable' effect than the patch we're looking at now; it would be more likely to cause chaotic unpredictable failure of such tx that depend on things far more random than this one.  This is more elegant and gentle than what I'd have written, because it is more subtle.

Even this isn't right, but you're along the right lines. With this type of patch, confirmation time "spiralling to infinite" doesn't happen for re-used addresses. All this is doing is putting transactions using un-used addresses to the front of the queue. If un-used addresses make up the whole block, then no re-used addresses will make it into that block. But if the block has space in it before it hits 1Mb limit, the re-used addresses will still have their transactions processed.

If Luke had made a patch that stopped re-used addresses in transactions from ever being processed by the software, never to be included in the block under any circumstances, I would not support it. Good thing that this is not what he's come up with.

[Cryddit]

I will go reread the patch; If you're right, then I misunderstood it.

I thought its effect was that a block could hold only one transaction per address.  If an address were reused then additional uses would have to be in separate blocks rather than the same block. And I'd consider that to be a 'reasonable' restriction given less than 90% adoption. (so that *all* reuses could clear occasionally, just after a somewhat unpredictable delay...  )

If you're right, then its effect is much much milder than that.   If it only rejects reuses of addresses until it has as many non-reused addresses as it can find, and then fills them in on a space-available basis, then it's actually nothing but a prioritization mechanism;  Since block space is rarely an issue, this has almost no effect at all on reused addresses; the effect of prioritizing tx with only non-reused addresses, even with 100% adoption is a very small change in the reliability and timeliness of transactions, hardly noticeable in the larger scheme, and has as many winners (people getting tx confirmed earlier) as losers (people having to wait an extra block time for a confirmation).

In that case, this is probably the mildest incentive I can imagine going up and I'm amazed that anyone is having a problem with it.  It's not so much the effect that people are debating here as the intent, I guess.  It shows an *intent* to deprecate reuse of addresses that people want to discuss.  But it doesn't present any noticeable obstacle to it; reusing addresses will see either zero or one additional block-time before confirmation.  And more likely zero than one.  Meanwhile, non-reuse will become slightly more reliable and timely, making the average wait exactly the same. 

This also means the miners aren't in the position of foregoing any tx fees.  If they can still fill up their blocks, they can still collect a whole block's worth of fees.  So there's no disincentive for the miners to deploy the patch, as I was afraid there might be given my earlier understanding of it.

So, yes, this is a very subtle effect.  I'd have even guessed possibly too subtle to be effective, except that people do seem to be paying attention to it here.

[Carlton Banks]

I will go reread the patch; If you're right, then I misunderstood it.

I thought its effect was that a block could hold only one transaction per address.  If an address were reused then additional uses would have to be in separate blocks rather than the same block. And I'd consider that to be a 'reasonable' restriction given less than 90% adoption. (so that *all* reuses could clear occasionally, just after a somewhat unpredictable delay...  )

If you're right, then its effect is much much milder than that.   If it only rejects reuses of addresses until it has as many non-reused addresses as it can find, and then fills them in on a space-available basis, then it's actually nothing but a prioritization mechanism;  Since block space is rarely an issue, this has almost no effect at all on reused addresses; the effect of prioritizing tx with only non-reused addresses, even with 100% adoption is a very small change in the reliability and timeliness of transactions, hardly noticeable in the larger scheme, and has as many winners (people getting tx confirmed earlier) as losers (people having to wait an extra block time for a confirmation).

In that case, this is probably the mildest incentive I can imagine going up and I'm amazed that anyone is having a problem with it.  It's not so much the effect that people are debating here as the intent, I guess.  It shows an *intent* to deprecate reuse of addresses that people want to discuss.  But it doesn't present any noticeable obstacle to it; reusing addresses will see either zero or one additional block-time before confirmation.  And more likely zero than one.  Meanwhile, non-reuse will become slightly more reliable and timely, making the average wait exactly the same. 

This also means the miners aren't in the position of foregoing any tx fees.  If they can still fill up their blocks, they can still collect a whole block's worth of fees.  So there's no disincentive for the miners to deploy the patch, as I was afraid there might be given my earlier understanding of it.

So, yes, this is a very subtle effect.  I'd have even guessed possibly too subtle to be effective, except that people do seem to be paying attention to it here.

Well, it's actually a little ambiguous to me now that I scrutinize it closely. Luke refers to it as re-use de-prioritisation, and that is an appropriate description of what you understand the patch to be. It would introduce perhaps significant latency to getting a block solution propagated on the network if a mining client were to search the list of re-used addresses for matches in the current transaction pool. Perhaps Luke can enlighten us.

[DeathAndTaxes]

Why would block propogation be slowed?  The patch modifies how tx are "ordered" for inclusion into a block. Once a block solution has been found the block is simply broadcast.  Nodes just validate and relay like they would any other block.

Do you mean it may introduce a delay in the creation of the tx set (which is used to construct merkle tree, which is used for merkle root, which is part of block header) BEFORE workers attempt to find a solution for the block?  I can't see it being more than a minimal additional processing and pools already use "tricks" to rapidly generate work for all workers after a block change.

[Carlton Banks]

Do you mean it may introduce a delay in the creation of the tx set (which is used to construct merkle tree, which is used for merkle root, which is part of block header) BEFORE workers attempt to find a solution for the block?  I can't see it being more than a minimal additional processing and pools already use "tricks" to rapidly generate work for all workers after a block change.

That is what I mean, yes. I wasn't aware that the transaction set is developed before the solution is attempted, that is an interesting and crucial fact when considering the applying of novel tx prioritising logic. It then appears there would be only a small additional system memory cost to maintaining a list of re-used addresses for demotion in priority for block inclusion.

[Luke-Jr]

Admittedly, the deprioritisation could be done much better.
The problem is, the code that creates the blocks is a total mess, and rewriting it is a sensitive area that would be a real pain to get merged, even with no behavioural changes.
So, it's easier for a miner to see that this patch won't make invalid blocks, than it would be if I started touching that code.

[prophetx]

Wouldnt doing this provide further economic justification for selfish mining,  as the researchers call it, because people whose tx are deprioritized will have further economic incentive to alter the blockchain?

I think you guys should really think things through a few steps ahead, the 2nd and 3rd order effects. Even if it was the original intention to not reuse addys, it was never enforced, and changing the rules now, changes the dynamics of the system possibly in unpredictable ways.

[DeathAndTaxes]

Wouldnt doing this provide further economic justification for selfish mining,  as the researchers call it, because people whose tx are deprioritized will have further economic incentive to alter the blockchain?

I think you guys should really think things through a few steps ahead, the 2nd and 3rd order effects. Even if it was the original intention to not reuse addys, it was never enforced, and changing the rules now, changes the dynamics of the system possibly in unpredictable ways.

The rules aren't being changed.  The rules are encoded in the protocol.  Changing them requires a hard fork.  The rules have ALWAYS allowed miners to choose which tx to include in a block (including none) and under what criteria they will be ranked/sorted/selected.

The patch simply gives miners an effective way to use the power they are already granted by the "rules" of the game.

[Luke-Jr]

Wouldnt doing this provide further economic justification for selfish mining,  as the researchers call it, because people whose tx are deprioritized will have further economic incentive to alter the blockchain?

I think you guys should really think things through a few steps ahead, the 2nd and 3rd order effects. Even if it was the original intention to not reuse addys, it was never enforced, and changing the rules now, changes the dynamics of the system possibly in unpredictable ways.

The rules aren't being changed.  The rules are encoded in the protocol.  Changing them requires a hard fork.  The rules have ALWAYS allowed miners to choose which tx to include in a block (including none) and under what criteria they will be ranked/sorted/selected.

The patch simply gives miners an effective way to use the power they are already granted by the "rules" of the game.

Minor correction: changing the rules in this case only requires a softfork.

[prophetx]

Okay the dynamics are being changed.  Whatever.......

I worked with guys who were running the first virtual economies in the late 80s and one of the big lessons they learned was when you start tweaking the dynamics shit happens that you never expected. 

You have been warned...  think it through...

[prophetx]

Another more fun option imho is to encourage altruistic behavior by criminals to use stolen btc to send dust to all known active addresses and then all those wallets become dirty.  Not sure anyone would actually do that but it would be fun.

You would need to turn off the dust rule and tx fee temporarily for that. Sort of like a jubilee.

[justusranvier]

Another more fun option imho is to encourage altruistic behavior by criminals to use stolen btc to send dust to all known active addresses and then all those wallets become dirty.  Not sure anyone would actually do that but it would be fun.

You would need to turn off the dust rule and tx fee temporarily for that. Sort of like a jubilee.

It wouldn't work the way you think it does.

Sending someone a dust output in no way interferes with any future spending they might choose to do. That's like saying that if somebody throws a penny at you and it lands in your pocket all of a sudden you'll have problem spending your $100 bill.

[DeathAndTaxes]

Another more fun option imho is to encourage altruistic behavior by criminals to use stolen btc to send dust to all known active addresses and then all those wallets become dirty.  Not sure anyone would actually do that but it would be fun.

You would need to turn off the dust rule and tx fee temporarily for that. Sort of like a jubilee.

It wouldn't work the way you think it does.

Sending someone a dust output in no way interferes with any future spending they might choose to do. That's like saying that if somebody throws a penny at you and it lands in your pocket all of a sudden you'll have problem spending your $100 bill.

Good analogy however if user is unaware they have received this "bad" input it is possible they will create a tx and combine it with a larger "good" input.  Note: good & bad is simply in reflection of CoinValidator's asinine system IMHO coins are simply coins.

[justusranvier]

IMHO coins are simply coins.

On a related note, that's what I tried to express here: http://bitcoinism.blogspot.com/2013/11/eli5-bitcoin.html

[Mondy]

What exactly is this? I newish, sorry.

[BitThink]

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

No everyone's fate is in the hands of miners.   However it HAS ALWAYS BEEN in the hands of miners (since the genesis block).  Don't like that concept?  Then become a miner.  

Not in the hands of miners, but in the hands of the operators of big mining pools. That's a big difference. A small miner is as powerless as non-miner.

Can't tell if trolling or stupid.... at least try to stick to one mumbling complaint at a time


Your complaint was true yesterday, the day before, the previous week, the previous month, and the entire history of pooled mining. Give yourself a round of applause for finally working out that pools represent multiple miners working for a single node. BITCIONS IS DIEEEING

It's not as true when the difficulty was not as high as now and increased as quickly as now. In the early days, it was much easier to create a new pool and get enough miners to join to survive. Now may I ask a simple question to you? How many hash rate do you have to get before anyone will be interested in joining the new pool you created? This situation becomes worse and worse every time the difficulty increases.

Why should I troll when my benefit lies on the appreciation of the BTC? I am just worrying. One of the main reasons why people love BTC is  that they think BTC is democratic and nobody can damage it since it is protected by millions of users. Call me stupid if you want cause I feel quite unconformable now when I realized just 3 to 5 persons (the operators of BTCGuild, GHash, Eligius, BitMinter, and Slush) can effectively damage the who ecosystem.

Yes, this time this patch may be not so harmful and you happen to side with the OP. But eventually you may disagree on other more serious issues. Considering it more before calling others FUD or stupid. Problems have to be warned by some FUDers before they can be fixed, because the Lovers are often too blind to find them.

Finally maybe off topic, a proposal to OP, as I believe he really cares about the future of BTC. Could you please also considering a patch that restricts the market share of one pool. I think that is at least as important as your current patch. Maybe we could open a new topic on that?

EDIT: create a new topic here: https://bitcointalk.org/index.php?topic=337260.msg3618577#msg3618577

[BurtW]

What exactly is this? I newish, sorry.

Read my new signature.  It is my personal summary of the situation.