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