Miners: Time to deprioritise/filter address reuse!

[DeathAndTaxes]

People already have the right incentives to not re-use coins (privacy).

This is not the case.  My privacy is not an incentive for someone who wants to pay me coin, nor for someone whom I want to pay coin to.  It is only an incentive for me, and I need the cooperation of these other parties to make it work.  In the absence of some further incentive that works for all the parties involved, privacy simply has not happened and evidently will not happen.

It's nice to think it's "coming" in these newer clients, but my privacy is more secure, AFAICT, if when it does so people have some substantial reason to *USE* and *PREFER* these features of the newer clients. Otherwise I wind up out on the short end of the stick dealing with people who don't want the new client for some reason and who aren't sufficiently inconvenienced by my lack of privacy to care.

This.  Privacy doesn't end at a single persons addresses.  It involves everyone one you interact with and everyone they interact with.  One can be perfectly anonymous and if the people they interact with are not well that can provide an indirect method of identifying transactions.

[safeminer]

this is a real good idea with some small road bumps which can be solved.

I see:

Mining pools with a auto payout, slight problem here. I dont want to change my payout adress every 2 days... But maybe you can import a batch of addresses or maybe there is some way to link your wallet api with your pool to auto generate an adress. Not really sure about that since im not really a professional programmer.

Bitcoin wallet software should Automaticaly generate an adress whenever you send BTC.

Bet there is more bumps but these came to my mind now

[Peter R]

I'm not a miner but I just discovered this important thread.  Excuse me if this has already been covered (thread now too long to read in full) but let me share my 2 satoshis:

I setup all my "converts" with the blockchain.info wallet on a smart phone.  People just send and receive to the same address over and over and I can see all the money flows into and out of their account.  You can't tell them to do anything different--they *think* they don't care, and besides it can't really be done on blockchain.info for mobile anyways. Most new users don't realize the potential for future privacy/security problems with address re-use.

I like Luke's idea because it would incentivize people like piuk to implement BIP32 for the main web wallet on blockchain.info.  Users would just see a balance in their "spend" account and the fact that a new address is being created for each transaction would be invisible to them.  This adds no complexity that I can see, but lots of privacy and security.  It seems only a good thing.  

[btcdrak]

this is a real good idea with some small road bumps which can be solved.

I see:

Mining pools with a auto payout, slight problem here. I dont want to change my payout adress every 2 days... But maybe you can import a batch of addresses or maybe there is some way to link your wallet api with your pool to auto generate an adress. Not really sure about that since im not really a professional programmer.

Bitcoin wallet software should Automaticaly generate an adress whenever you send BTC.

Bet there is more bumps but these came to my mind now

BIP32 means you can give the pool your public key and it can generate a new pubic address for you.

[Barek]

First off, thank you for taking initiative and time to explain.

Another reason not to reuse addresses for sending is a compromised RNG. You may recall the issue with Android just recently. Only worked because private keys were reused for signatures.

http://crypto.stackexchange.com/questions/9694/technical-details-of-attack-on-android-bitcoin-usage-of-securerandom

[waxwing]

I like what's being done here. At first glance, it seems rather rushed to throw this into miners straight away; but I guess it could be looked at as a shot across the bow, since it doesn't break any kind of transaction right now, just makes a certain subset slightly slower.

Also, I stumbled across this by accident. Shouldn't something like this be disseminated to the broad community? Maybe I missed it, if so apologies.

A third thought cropped up: put yourself in place of the regulator determined to implement rainbow-lists or whatever they're called nowadays. The first thing you're going to see is miners deliberately blocking your ability to trace "illicit payments". So you go after the miners ... wouldn't it be ironic if, by attacking large mining pools, the regulators pushed Bitcoin back into a totally decentralised mining model (maybe with less hashing power to start with, but not for long)? (yeah I know it's mostly nonsense what with the international nature of mining, but a fun thought).

[Peter R]

Also, I stumbled across this by accident. Shouldn't something like this be disseminated to the broad community? Maybe I missed it, if so apologies.

I agree.  I just discovered this thread this morning by accident and then learn about this effective yet non-invasive way to incentive privacy.  We've been discussing black/white/red listing in the main discussion area and this idea has not been given its due share of attention.   

Perhaps someone with more activity points than me should post this topic in the main discussion area....

[waxwing]

Also, I stumbled across this by accident. Shouldn't something like this be disseminated to the broad community? Maybe I missed it, if so apologies.

I agree.  I just discovered this thread this morning by accident and then learn about this effective yet non-invasive way to incentive privacy.  We've been discussing black/white/red listing in the main discussion area and this idea has not been given its due share of attention.  

Perhaps someone with more activity points than me should post this topic in the main discussion area....

I'll link it to reddit. Perhaps the peanut gallery redditors will appreciate it

Edit: scratch that, it's already up: http://www.reddit.com/r/Bitcoin/comments/1qpay8/eligius_pools_response_to_coinvalidation_nonesense/

[Carlton Banks]

The software ecosystem is missing a useful piece:

When you are receiving regular payouts, from a job salary or mining pool for example, there needs to be address rotation.

Right now, the only way to do that is manually logging into the payer's website, and replacing the current payout address with a new one.

Software should communicate with the payer, or give the payer a list of addresses, or an HD seed that may generate additional public keys, etc.

Address reuse in these circumstances is annoying, hurting privacy, but inevitable until software improves.

All yes.

This is (basically) my argument at the moment against this.  In the case of BTC Guild, the *highest* level of security an account can have is locking the wallet address.  With this, you can not change it unless you digitally sign a message using the private key, confirming ownership.  Removing the lock is a manual process, nothing on the site is capable of removing the wallet lock once it's in place (even an SQL injection would not be able to do it due to lack of permissions).

No.

Similarly, it discourages automatic payouts, since those would use the same address every time unless changed.  The last thing I want is automatic payouts adding hassle, considering they're the best way to encourage users to not use the pool as a bank.

BIP32

The only fix on this I can see would be on my end adding some kind of "wallet queue" to accounts where they can pre-make a batch of wallets to use (maybe even using the BIP32 suggestions), but my limited knowledge of BIP32 leads me to believe this would still require manual entry on the user part.  If somebody else could generate the chain of public addresses to use, it seems like it wouldn't be very anonymous (they'd actually be able to follow all your transactions forever on that wallet-chain?).

No. More than one chain. BIP32.

[Carlton Banks]

I will most definitely be using this patched client with my p2pool node.


But I also agree that we should not be enforcing any absolutely transaction exclusion policy on an address basis. HD wallets are not implemented yet, I'm not sure that the standard has even been totally finalised. De-prioritisation sets the right balance until the landscape of listing develops further, we must in the meantime educate users across the whole community of users about the issues surrounding all of this.


Edit: Question to Luke Jr.

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

[DeathAndTaxes]

I like what's being done here. At first glance, it seems rather rushed to throw this into miners straight away; but I guess it could be looked at as a shot across the bow, since it doesn't break any kind of transaction right now, just makes a certain subset slightly slower.

Well so far only one major pool (plus maybe a few solo miners) is using it.  That is the nice thing about decentralized network.  Some parts can try out new code (outside of core protocol) at different times.   Right now 15% of hashpower is using this.   Maybe by the time BIP32 is more ubiquitous 80% of the hashpower will be using it.

[phillipsjk]

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

As I understand it, P2Pool needs to implement BIP32 as well.

[btcdrak]

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

As I understand it, P2Pool needs to implement BIP32 as well.

I think we all need to lobbying pools and wallets to pull their act together and implement this asap.

[DeathAndTaxes]

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.

p2pool could implement BIP32 or in the interim given that p2pool nodes also run bitcoind could just implement a direct getnewaddress() RPC call after any successful block to ensure future blocks use a unique address.

[DeathAndTaxes]

I'm not a miner but I just discovered this important thread.  Excuse me if this has already been covered (thread now too long to read in full) but let me share my 2 satoshis:

I setup all my "converts" with the blockchain.info wallet on a smart phone.  People just send and receive to the same address over and over and I can see all the money flows into and out of their account.  You can't tell them to do anything different--they *think* they don't care, and besides it can't really be done on blockchain.info for mobile anyways. Most new users don't realize the potential for future privacy/security problems with address re-use.

I like Luke's idea because it would incentivize people like piuk to implement BIP32 for the main web wallet on blockchain.info.  Users would just see a balance in their "spend" account and the fact that a new address is being created for each transaction would be invisible to them.  This adds no complexity that I can see, but lots of privacy and security.  It seems only a good thing. 

Yup. That is the important part.  Luke's patch can't FORCE anyone to use unique addresses however it can provide an incentive and if/when more of the hashpower implements it the incentive grows.  Without any incentive we likely will be in the exact same situation a year from now.  The current "lazy" static address use scenario is the easiest to implement.  Privacy minded miners can push for this patch which provides an incentive to make the Bitcoin network more what they want it to be.   Voting for change with hashpower.

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

p2pool could implement BIP32 or in the interim given that p2pool nodes also run bitcoind could just implement a direct getnewaddress() RPC call after any successful block to ensure future blocks use a unique address.

I'm not sure which I prefer, an RPC call to generate a new random address, or supplying a keychain of addresses that are predetermined... I guess it depends on whether the keychain appears on the blockchain or is made public through the p2pool network. I can't think of a reason for the latter to happen, I don't see how other p2pool nodes need the keychain itself, they should only need the latest iteration of address from within the keychain sequence. But this all depends on how p2pool and BIP32 neccesarily operate (and how the pair of them operate together).

forrestv, LukeJr, anyone else who can shine a light: we welcome your comments

[Kyune]

I'm not a miner but I just discovered this important thread.  Excuse me if this has already been covered (thread now too long to read in full) but let me share my 2 satoshis:

I setup all my "converts" with the blockchain.info wallet on a smart phone.  People just send and receive to the same address over and over and I can see all the money flows into and out of their account.  You can't tell them to do anything different--they *think* they don't care, and besides it can't really be done on blockchain.info for mobile anyways. Most new users don't realize the potential for future privacy/security problems with address re-use.

I like Luke's idea because it would incentivize people like piuk to implement BIP32 for the main web wallet on blockchain.info.  Users would just see a balance in their "spend" account and the fact that a new address is being created for each transaction would be invisible to them.  This adds no complexity that I can see, but lots of privacy and security.  It seems only a good thing. 

Yup. That is the important part.  Luke's patch can't FORCE anyone to use unique addresses however it can provide an incentive and if/when more of the hashpower implements it the incentive grows.  Without any incentive we likely will be in the exact same situation a year from now.  The current "lazy" static address use scenario is the easiest to implement.  Privacy minded miners can push for this patch which provides an incentive to make the Bitcoin network more what they want it to be.   Voting for change with hashpower.

A key point, and a reminder of the sway that miners may ultimately hold over the future of bitcoin.  Miners can switch to Eligius if they support this policy, and increase its network hash percentage, or switch away if they don't.  Is this a harbinger of things to come...will we see more examples of political "policy" differences between how pools process transactions in the future?

[Carlton Banks]

A key point, and a reminder of the sway that miners may ultimately hold over the future of bitcoin.  Miners can switch to Eligius if they support this policy, and increase its network hash percentage, or switch away if they don't.  Is this a harbinger of things to come...will we see more examples of political "policy" differences between how pools process transactions in the future?

I'm mining strictly on p2pool, so I'll be switching my own personal mining client instead. But Eligius just became my 1st preference failover pool (not that I've had any downtime so far using p2pool, but the machine my p2pool node runs on could drop dead one time when I'm not there to deal with it).

[Luke-Jr]

Luke, can you describe more clearly what the patch does?
in particular:
- one reuse of any given address per block, or one address reuse per block?
- does it concern only  inputs, outputs, or both?  for example, an address
that has several inputs and tries to spend them all is deprioritized or not ?

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.

And then there's Blockchain.info. Did you know Blockchain.info wallets reuse addresses by default unless you create new ones?

Any software which reuses addresses by default is broken.
I am okay with forcing incompetent* software developers to fix their software.

* Sorry, they should really know better.

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

This will not affect any generation transactions, nor any miners who choose not to use it.

[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?

To give an example.

In the first example a donation address is set up that receives multiple inputs. Then a spend is made that triggers an output from the address. Then after the spend the same address in used again for inputs. In the second example a donation address is set up that receives multiple inputs. Then a spend is made that triggers an output from the address. After the spend a new address is generated for subsequent donations.