Post
Topic
Board Mining
Re: Miners: Time to deprioritise/filter address reuse!
by
mikegogulski
on 16/11/2013, 15:24:31 UTC
Hmm, I only scan read this thread, but as bitcoinj based wallets are one of the primary guilty parties in address re-use I'll just pop in to give my view:

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

Quote
People already have the right incentives to not re-use coins (privacy). SPV wallets suck at it today because I chose backup safety over privacy, but BIP32 let's us have our cake and eat it in that regard and it's now being implemented. So at some point SPV wallets will update and addresses will start automatically changing, users won't have to do anything. I'm figuring out ways existing wallets can be upgraded in place.

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.

Quote
Punishing address re-use NOW, when many users who are doing it don't have any good way to stop, is just attempting to pressure volunteer wallet developers through their userbase. That's not cool. I already spend a lot of my spare time at evenings and weekends fixing bugs and keeping up with the Bitcoin protocol (20% only gets you so far and can't always be taken). Being "forced" to do it by punishing my users would be quite upsetting, especially as it's coming anyway and Bitcoin-Qt itself doesn't even implement BIP32 properly yet (AFAIK only Electrum has done this?).

Another very good perspective on this.