Re: [Bitcoin-development] Key retirement and key compromise
On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote: > On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami wrote: > > I'm not envisaging something as drastic as changing the rules to make > > transactions to revoked addresses invalid - just an overlay protocol. > > Although to be useful such a protocol would have to be pretty much > > universally implemented by clients. > > That is quite drastic enough, as it requires adding more perpetual > data that must remain in fast lookup for all validating nodes (the set > of revoked 'addresses'). Maybe it should be possible for addresses to contain expiry dates, so that revocation lists don't need to hang around forever. > Keep in mind that this is only improvement for what is a usually > inadvisable usage of Bitcoin to begin with... you should not be > reusing addresses. It may be inadvisable but in many cases it is pretty much unavoidable as Bitcoin stands today. Granted, the payment protocol will help with that in many use cases... roy -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Key retirement and key compromise
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami wrote: > I'm not envisaging something as drastic as changing the rules to make > transactions to revoked addresses invalid - just an overlay protocol. > Although to be useful such a protocol would have to be pretty much > universally implemented by clients. That is quite drastic enough, as it requires adding more perpetual data that must remain in fast lookup for all validating nodes (the set of revoked 'addresses'). Keep in mind that this is only improvement for what is a usually inadvisable usage of Bitcoin to begin with... you should not be reusing addresses. -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Key retirement and key compromise
On Fri, Feb 22, 2013 at 11:08:51PM +, I wrote: > What would be really nice is for bitcoin to have a big key compromise > button, which would automatically transfer all coins to newly > generated addresses (optionally with a pause between generation and > transaction - to allow for a new wallet backup). Optionally, too, the > compromised/retired addresses could be marked with a flag such that if > someone sends coins to that address bitcoind immediately generates a > transaction to transfer the coins to address(es) which are good. On Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote: > The problem with automatic transactions would be: by repeatedly sending > money to an address and seeing if it always moves quickly, an attacker > can identify (a) that an address is in use, (b) which public key it has > (if this isn't already public), and (c) that the key is believed to be > compromised. I realise on reflection that what I really want is not automatic transmissions, but a means to revoke an address. The problem is that after transfering the coins from the compromised addresses to a new, hopefully safe address, what to do about the fact that third parties might still try to send me coins to an old, compromised address. So what I think I'm suggesting is that there should be an address revocation protocol, such that clients will give an error if their user tries to send coins to a revoked address. Unless we think that direct payments to addresses will become completely obsolete once the payment protocol is in use, in which case (maybe) this functionality belongs in the payment protocol instead - but I remain unconvinced of that. I'm not envisaging something as drastic as changing the rules to make transactions to revoked addresses invalid - just an overlay protocol. Although to be useful such a protocol would have to be pretty much universally implemented by clients. Thoughts? roy -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
