Miners: Time to deprioritise/filter address reuse!

[Luke-Jr]

A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question?

The risks (which are not limited to mere privacy, I might note) are the same for both of these cases.

In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term.

[1714295344]

1714295344

[1714295344]

1714295344

[franky1]

i just grabbed a random block
http://blockchain.info/block-index/440384/0000000000000000a1bf1c65136cbd618e356179fec857d583e7a9373ca8386d (269989)

and looked at the transactions in it..

within the first 20 transactions there were around 10 where the destination was at that time used address.

so is Luke JR telling us that the first transaction goes into this block(269989) the next transaction has to wait for the next block(269990)

and so on for the 10 addresses i looked at(269998) that there is causing atleast 1 hour 40 minute delay for that 10th transaction.

so lets say there were 10 used addressed transactions per block, what about other transactions time stamped at (269990). they have no spaces in block(269990) through to (269998)

each of those 10 transactions have to wait even further before filling up blocks  (269999-270008) . making the 10th transaction sent at the timestamp of 269990 finally enter a block over 3 hours 20 minutes later(270008)

now imagine the transactions timestamped at the times of blocks 269991-270008.. imagine how long they have to wait. (300 transactions of used addresses waiting......)

Luke JR i guess you never watched the butterfly effect, or what happens when you throw a pebble into the water..

[Luke-Jr]

i just grabbed a random block
http://blockchain.info/block-index/440384/0000000000000000a1bf1c65136cbd618e356179fec857d583e7a9373ca8386d (269989)

and looked at the transactions in it..

within the first 20 transactions there were around 10 where the destination was at that time used address.

so is Luke JR telling us that the first transaction goes into this block(269989) the next transaction has to wait for the next block(269990)

and so on for the 10 addresses i looked at(269999) that there is causing atleast 1 hour 40 minute delay for that 10th transaction. and what about other transactions sent 10 minutes after(269989). they have no spaces in block(269990) through to (269999)

so lets say there were 10 used addressed transactions per block

in block(269990). after waiting 1 hour 40 minutes, each of those 10 transactions have to wait a further 10 minutes filling up blocks  (270000-270009) . making the 10th transaction sent at the timestamp of 269990 finally enter a block over 3 hours 20 minutes later

now imagine the transactions timestamped at the times of blocks 269991-270009.. imagine how long they have to wait. (300 transactions of used addresses waiting......)

Luke JR i guess you never watched the butterfly effect, or what happens when you throw a pebble into the water..

The point is that people need to stop this bad behaviour and start using Bitcoin correctly.

[Carlton Banks]

I assume this cannot affect the prioritisation of the Coinbase transaction that constitutes p2pool miner's reward payments? Can you clarify this?

The coinbase tx itself?  No (it would be in the block you solve, nothing can change that).
Spending the outputs of the coinbase tx?  Yes.

I'm not sure that the bolded part is correct. It depends on Luke's patch implementation, as well as the protocol rules.

Do multiple inputs to the same address constitute address re-use in the same way that multiple outputs from a single address do? LukeJr does indicate that this initial version of his patched client isn't the most aggressive. If inputs are being relegated, would it be possible to make this more subtle, and exclude inputs from CoinBase tx's? I'm deferring to Luke again.

[franky1]

The point is that people need to stop this bad behaviour and start using Bitcoin correctly.

then teach them how to transact properly through a youtube tutorial. instead of putting in protocol bureaucracy that will cause transaction delays..

this to me is not about teaching people the right way, but to hit people with a delay stick as many times as it takes until they get it right.

have you atleast made a massive announcement that there will be expected transaction delays if people do not transact properly, on bitcointalks main thread, or the foundations website.

no? well start tutoring people before knocking their financial kneecaps with block change protocols

i must also highlight the voting (stats taken at time stamp of this post

You're an idiot, don't do this!   - 59 (36.6%)
I don't like this, but I agree we need to move forward with it.   - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now.   - 19 (11.8%)
Great, it's about time!   - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP!   - 35 (21.7%)
If it's from Luke, it can't be any good.   - 11 (6.8%)

which simplified down is
103 say no to implementation 64%
58 say yes implement the change to miner protocol 36%

so why luke have you decided to go against consensus and implement it with elegius?

[mikegogulski]

The point is that people need to stop this bad behaviour and start using Bitcoin correctly.

Meanwhile, outside the bubble of authoritarian-minded mining pool operators:



(via http://www.reddit.com/r/Bitcoin/comments/1qrp1h/subway_accepting_bitcoins_in_slovakia_bratislava/ )

[DobZombie]

What about donation addresses?

[DeathAndTaxes]

What about donation addresses?

An address is an address.  The protocol/network cares not the purpose.  It is possible to use a dynamic address for donations.

[mdopro1]

A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question?

The risks (which are not limited to mere privacy, I might note) are the same for both of these cases.

In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term.

What?

What's the risk?

[btcdrak]

A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question?

The risks (which are not limited to mere privacy, I might note) are the same for both of these cases.

In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term.

What?

What's the risk?

It leaks cryptographic information - that's how that recent 55BTC hack occurred (in combination with the PRNG issues in Java SecureRandom lib).

[DeathAndTaxes]

A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question?

The risks (which are not limited to mere privacy, I might note) are the same for both of these cases.

In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term.

What?

What's the risk?

It leaks cryptographic information - that's how that recent 55BTC hack occurred (in combination with the PRNG issues in Java SecureRandom lib).

Also in the event that ECDSA is degraded the pubkey being unknown (payments are to pubkeyhash) provides an added layer of security.   Commonly people assumes algorithms are either "safe" or "broken" where broken means someone can instantly find a private key from the public key.  The reality is often algorithms are merely degraded.  As an an example a flaw could be found in ECDSA such that it takes on average 2^60 operations to perform a preimage attack (normally 2^128 by brute force.  Now 2^60 is a relatively large number but a dedicated attacker with sufficient resources could attack (over the course of months) a known PubKey.  If the PubKey is unknown no attack is possible. 

[Carlton Banks]

What about donation addresses?

Address Chains, forthcoming in the new version of Bitcoin Qt.

[btcdrak]

What about donation addresses?

Address Chains, forthcoming in the new version of Bitcoin Qt.

Is it actually being implemented or one of those things that has been sidelined?

[ArticMine]

The point is that people need to stop this bad behaviour and start using Bitcoin correctly.

then teach them how to transact properly through a youtube tutorial. instead of putting in protocol bureaucracy that will cause transaction delays..

this to me is not about teaching people the right way, but to hit people with a delay stick as many times as it takes until they get it right.

have you atleast made a massive announcement that there will be expected transaction delays if people do not transact properly, on bitcointalks main thread, or the foundations website.

no? well start tutoring people before knocking their financial kneecaps with block change protocols

i must also highlight the voting (stats taken at time stamp of this post

You're an idiot, don't do this!   - 59 (36.6%)
I don't like this, but I agree we need to move forward with it.   - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now.   - 19 (11.8%)
Great, it's about time!   - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP!   - 35 (21.7%)
If it's from Luke, it can't be any good.   - 11 (6.8%)

which simplified down is
103 say no to implementation 64%
58 say yes implement the change to miner protocol 36%

so why luke have you decided to go against consensus and implement it with elegius?

You're an idiot, don't do this!   - 59 (36.6%)
I don't like this, but I agree we need to move forward with it.   - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now.   - 19 (11.8%)
Great, it's about time!   - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP!   - 35 (21.7%)
If it's from Luke, it can't be any good.   - 11 (6.8%)

I read the poll more along these lines. Opposed: 43.2% In favour with varying degrees of support: 56.5% Rounding 0.3%. There is a fair degree of support for this. We must also keep in mind the following

Why does my Bitcoin address keep changing?

Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances anonymity. All of your old addresses are still usable: you can see them in Settings -> Your Receiving Addresses.

from https://en.bitcoin.it/wiki/FAQ#Why_does_my_Bitcoin_address_keep_changing.3F The original design of Bitcoin was that address reuse is to be the exception rather than the norm and what is been done here follows this intent. I get the distinct impression here that Coin Validation has fired a shot across the bow of Bitcoin and someone has just shot back.

[ArticMine]

A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question?

The risks (which are not limited to mere privacy, I might note) are the same for both of these cases.

In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term.

What?

What's the risk?

It leaks cryptographic information - that's how that recent 55BTC hack occurred (in combination with the PRNG issues in Java SecureRandom lib).

Also in the event that ECDSA is degraded the pubkey being unknown (payments are to pubkeyhash) provides an added layer of security.   Commonly people assumes algorithms are either "safe" or "broken" where broken means someone can instantly find a private key from the public key.  The reality is often algorithms are merely degraded.  As an an example a flaw could be found in ECDSA such that it takes on average 2^60 operations to perform a preimage attack (normally 2^128 by brute force.  Now 2^60 is a relatively large number but a dedicated attacker with sufficient resources could attack (over the course of months) a known PubKey.  If the PubKey is unknown no attack is possible. 

Yes. This is a crucial difference between reuse for inputs only (for example a donation address) and reuse after an output.

[ProfMac]

I have used bitcoin the following ways with address re-use.  I thought it was a strength of bitcoin.

I.  Auction bidding.

I sold shares in my Avalon to different people.  They were careful to pay my auction address from an address that they controlled.  This auction address received many payments, often times payments from the same source.

This let me and all the people interested in bidding be confident that we were not victims of joy-bidding.  I think this was a good way to run an auction, it was transparent.

I refunded non-winning bids to their payment address.  Again, everyone was able to see that I refunded those bids.  I think this was a good use of bitcoin.


II.  Payouts of mining pool

I receive my mining proceeds into an address that is only used to receive and disburse these proceeds.  Each Tuesday I take the proceeds of this week's mining earnings and issue a bitcoin sendmany to the successful addresses.

At this time, I do not know the identity of many of my shareholders.  I only have their address.

I don't see the increased danger in making many disbursement payments to the same set of addresses instead of 1.  I also don't see how to communicate with my shareholders to ask them for new payment addresses, as I don't know their identity.

[DeathAndTaxes]

I.  Auction bidding.

This can be accomplished with a BIP32 address chain

II.  Payouts of mining pool
I also don't see how to communicate with my shareholders to ask them for new payment addresses, as I don't know their identity.

Worst case scenario if you stop sending regular payments I am sure they will contact you.
In the future you could have them generate a BIP32 public key, put that PubKey in a message and sign the message with the existing address as a cryptographically secure way to transition.

[ProfMac]

I.  Auction bidding.

This can be accomplished with a BIP32 address chain

Is this supported with blockchain.info or bitcoin-qt at this time?

[DeathAndTaxes]

I.  Auction bidding.

This can be accomplished with a BIP32 address chain

Is this supported with blockchain.info or bitcoin-qt at this time?

No however I would strongly encourage you to advocate for them to update.

[franky1]

the other thing to note is:

Gavin A proposes adding API callbacks into the bitcoin URI so that retailers do not have to use unique addresses per customer, but using one address and be able to track which TXID belongs to which customer by use of the API callback.

so we have Gavin A trying to reduce the need for unique addresses. and we have Luke Jr trying to increase the need for unique addresses.

can we find a room for the main dev's to go in and slug it out for a few matches as to something that can be agreed on that is best for the community..