rich1.0npub1m6p5kgcd428x6pxyfege98zjmlwrdhp0gyz6pdnsvrvalscddnxqurdjn5https://nostr.ae/npub1m6p5kgcd428x6pxyfege98zjmlwrdhp0gyz6pdnsvrvalscddnxqurdjn5njumphttps://nostr.ae📅 Original date posted:2016-08-03 📝 Original message:On Thu, Aug 04, 2016 at 04:16:20AM +1000, Matthew Roberts via bitcoin-dev wrote: > In light of the recent hack: what does everyone think of the idea of > creating a new address type that has a reversal key and settlement layer > that can be used to revoke transactions? I think many of us who think about human - computer interactions see the need for a well defined process to roll back unexpected behavior in a computer system. My 2014 era proposal is https://bitbucket.org/tmagik/catoshi/issues/24 The fundamental assumption around cryptocoins is you have a secret (private key) known only by you. Currently in bitcoin if that assumption changes, the response is blame the user. 'Incompetence, etc, etc' This is bad business. For any cryptocurrency to really get mass market, we need to provide our users with key revocation, to be used when the assumption about being the only holder of a secret is broken. I think there's a hardfork-worthy choice here: 1) implement reversal/revocation as an add-on feature 2) implement reversal/revocation as a fundamental that every address gets. Ethereum made a quick hardfork choice to reverse a *single* instance of unexpected behavior, and looks a lot like a bank bailout. We have the chance to learn from this mistake, and, apparently, make a lot of money trading on both sides of the hardfork. > You could specify so that transactions "sent" from these addresses must > receive N confirmations before they can't be revoked, after which the > transaction is "settled" and the coins become redeemable from their > destination output. A settlement phase would also mean that a transaction's > progress was publicly visible so transparent fraud prevention and auditing > would become possible by anyone. > > The reason why I bring this up is existing OP codes and TX types don't seem > suitable for a secure clearing mechanism; Nlocktimed TXs won't work for > this since you can't know ahead of time when and where a withdrawal needs > to be made, plus there's still the potential for key mismanagement; Similar > problems with OP_CHECKLOCKTIMEVERIFY apply too ??? unless you keep a private > key around on the server which would defeat the purpose. The main use case > here, would be specifically to improve centralized exchange security by > making it impossible for a hot wallet to be raided all at once. > > Thoughts? > > Some existing background: > > http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/ > -- Proposed the basic idea for a time-based clearing house but using > blockchains directly, this is a much better idea than my own. > > roberts.pm/timechain -- My original paper written in 2015 which proposed a > similar idea for secure wallet design but implemented using time-locked > ECDSA keys. Obviously a blockchain would work better for this. > > Other -- if the idea has already been brought up by other people, I > apologize. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev