Topic: Miners: Time to deprioritise/filter address reuse! - page 5. (Read 51830 times)

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.

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.

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.

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...

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

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.

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.

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.

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.

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.

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.

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.

I think this is what gmaxwell was suggesting: https://bitcointalksearch.org/topic/m.3588058

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.  

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.

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? 

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

+1 

There are many benefits to public addresses and address reuse.  In banking it would NOT BE SAFE to give out your bank account numbers, but with Bitcoin since the transactions are one way, it is not as problematic.  The whole idea is Bitcoin gives the user CHOICE.  Why would we start to take that benefit away from users as a reaction to something that probably will not happen?

If you create a pool with a clear mission, miners will join it no matter if you have less than one block per week. Spread enough fud about the big pools and yours will grow. Even though I don't agree on that subject, more pools and more solo miners that care about these behind the scenes politics are a good thing.

Mining reminds me a lot of liquid democracy. This is great

Just do it. And keep it coming.