{"type":"rich","version":"1.0","author_name":"npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9h","author_url":"https://nostr.ae/npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-08-06\n📝 Original message:Hi,\n\nI can clearly see some advantages for such a feature, but it's kind of\nin conflict with Bitcoin's fundamental design. This design might be\nproblematic when it comes to hacks/thefts, but it's what gives Bitcoin\nstrength and make it differentiate from other currencies:\n\n* reversal of transactions is impossible\n* keep private keys private and safe. Lose them, it's like losing cash,\nyou can just forget about it.\n* while we try hard to make 0-conf as safe as possible (if there's no\nRBF flag on the transaction), we make it almost impossible or very very\nexpensive to reverse a confirmed transaction.\n\nAlso, we don't have a clear way to properly decide a good settlement\nperiod length. It doesn't fix the problem any more than nLockTime fixes\nit -- you can't know ahead of time when a withdraw needs to be made.\nFair enough, but even if the withdraw is made with a settlement layer,\nwill the user be able to spend it further immediately? Who will accept\nsuch an input and treat it as a payment if it can be reversed during the\nsettlement layer? So, if you can't know ahead of time when a withdraw\nneeds to be made (nLockTime) how can you know ahead of time+settlement\nperiod when a transaction needs to be declared irrevocable?\n\nThe linked page describes that merchants will never accept payments from\n'vaults', and it will take 24 hours for coins to be irreversible moved\noutside the 'vault'. This covers the part \"is the user able to spend a\ntransaction with settlement layer\" but it has security properties equal\nto nLockTime = 24 hours - you can't benefit and use the coins\nimmediately and in 24 hours price might go up or down in an undesirable\nway for a certain user. It however raises a lot of other questions: what\nif the attacker manages to steal both the private key and vault key (we\nhave strong reasons to assume this can happen: if you can't keep a\nprivate key safe, why would you be able to keep the vault key any\nsafer?) and starts a race with the actual user to unlock and lock back\nthe vault?\n\nI think this is a wrong approach. hacks and big losses are sad, but all\nthe time users / exchanges are to blame for wrong implementations or\nterrible security practices.\n\nThanks!\n\nOn 8/3/2016 9:16 PM, 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\u003e \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\n\u003e transaction's progress was publicly visible so transparent fraud\n\u003e prevention and auditing 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\n\u003e seem suitable for a secure clearing mechanism; Nlocktimed TXs won't work\n\u003e for this since you can't know ahead of time when and where a withdrawal\n\u003e needs to be made, plus there's still the potential for key\n\u003e mismanagement; Similar problems with OP_CHECKLOCKTIMEVERIFY apply too –\n\u003e unless you keep a private key around on the server which would defeat\n\u003e the purpose. The main use case here, would be specifically to improve\n\u003e centralized exchange security by making it impossible for a hot wallet\n\u003e 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 \u003chttp://roberts.pm/timechain\u003e -- My original paper\n\u003e written in 2015 which proposed a similar idea for secure wallet design\n\u003e but implemented using time-locked ECDSA keys. Obviously a blockchain\n\u003e 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\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160806/e7d9caab/attachment.sig\u003e"}