rich1.0npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9hhttps://nostr.ae/npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9hnjumphttps://nostr.ae📅 Original date posted:2016-08-06 📝 Original message:Hi, I can clearly see some advantages for such a feature, but it's kind of in conflict with Bitcoin's fundamental design. This design might be problematic when it comes to hacks/thefts, but it's what gives Bitcoin strength and make it differentiate from other currencies: * reversal of transactions is impossible * keep private keys private and safe. Lose them, it's like losing cash, you can just forget about it. * while we try hard to make 0-conf as safe as possible (if there's no RBF flag on the transaction), we make it almost impossible or very very expensive to reverse a confirmed transaction. Also, we don't have a clear way to properly decide a good settlement period length. It doesn't fix the problem any more than nLockTime fixes it -- you can't know ahead of time when a withdraw needs to be made. Fair enough, but even if the withdraw is made with a settlement layer, will the user be able to spend it further immediately? Who will accept such an input and treat it as a payment if it can be reversed during the settlement layer? So, if you can't know ahead of time when a withdraw needs to be made (nLockTime) how can you know ahead of time+settlement period when a transaction needs to be declared irrevocable? The linked page describes that merchants will never accept payments from 'vaults', and it will take 24 hours for coins to be irreversible moved outside the 'vault'. This covers the part "is the user able to spend a transaction with settlement layer" but it has security properties equal to nLockTime = 24 hours - you can't benefit and use the coins immediately and in 24 hours price might go up or down in an undesirable way for a certain user. It however raises a lot of other questions: what if the attacker manages to steal both the private key and vault key (we have strong reasons to assume this can happen: if you can't keep a private key safe, why would you be able to keep the vault key any safer?) and starts a race with the actual user to unlock and lock back the vault? I think this is a wrong approach. hacks and big losses are sad, but all the time users / exchanges are to blame for wrong implementations or terrible security practices. Thanks! On 8/3/2016 9:16 PM, 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? > > 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 <http://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. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160806/e7d9caab/attachment.sig>