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

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

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.

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 think we all need to lobbying pools and wallets to pull their act together and implement this asap.

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

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.

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?

All yes.


No.


BIP32


No. More than one chain. BIP32.

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/

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

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

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

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.  

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

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.

Really as a tech savy person you can't think of a better workaround?  How about generate and import 1,000 private keys.  Then when you need to change the address simply use the python tool to find the next one in the sequence.


Well they won't until there is a reason to do so and the patch gives them a reason.  In the interim if a site allows posting 50 addresses why would you need to manually change them.  It would be a trivial amount of coding for a site to use the next one automatically and notify you when the queue is low or out.  Still BIP32 is a better longer term solution.  However if sites don't implement them you can still use funds with a small disincentive.  That would encourage people to use sites which do promote single use addresses.


Then encourage blockchain.info to change their default behavior.  The issue of reuse has been known since a YEAR PRIOR to the genesis block.  It is unlikely without an incentive anything will change.  Lastly remember this doesn't prohibit reuse, it doesn't make coins sent to a used address lost, it doesn't even mean higher mandatory fees.  It is merely delaying secondary spends from the same address.


Chicken or the egg.  Without the incentive will the infrastructure ever exist.  Blockchain.info could easily (within minutes) change their code.  Will they?  Probably not.  Not until users complain.  Will users complain unless their is an incentive?  Once again probably not.  It isn't like Bitcoin just launched.  There has been years to do things right and the lazy, easy approach has been used in most cases.

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.

"Guilty" is rather too strong a word, especially given that a library like bitcoinj sits fairly distant from the wallet UIs, which is where the flags and cautions need to be shown to the user.

What would be very nice to see as at least a minor mitigation here would be wallet clients presenting users with an additional challenge when attempting to send to an address the client has already spent to. That only takes a chink out of the systemic problem under discussion, but has a nice side effect in reducing the risk of a mis-click someplace leading to an unintended irrevocable spend to an incorrect address (which, er, I've done more than once).


Cool. I'd be thrilled if wallet clients used the BIP32 scheme as the default. It's a win for the whole ecosystem -- provided that, in light of the use cases above and others -- the choice to re-use addresses is not phased out.


Another very good perspective on this.

I was not commenting on the advisability of the patch in the OP, just pointing out that just because people are using single address wallets does not mean that it's the right thing to keep doing.

That behaviour was known broken ever since the beginning, but since Satoshi didn't worry about the ability of users to backup their keys when he wrote the client (otherwise he would have gone with deterministic key generation), client developers responded by making wallets with a single key. Now a bunch of new users have been trained with bad practises and it will take some now to reverse.