On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote:
> * reversal of transactions is impossible > I think it would be more accurate to say that the requirement is that reversal doesn't happen unexpectedly. If it is clear in the script that reversal is possible, then obviously the recipient can take that into consideration. > * keep private keys private and safe. Lose them, it's like losing cash, > you can just forget about it. > Key management is a thing. Managing risk by keeping some keys offline is an important part of that. > * 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. > BitGo has an "instant" system where they promise to only sign one transaction for a given output. If you trust BitGo, then this is safe from double spending, since a double spender can't sign two transactions. If BitGo had actually implemented a daily withdrawal limit, then their system ends up similar to cold storage. Only 10% of the funds at Bitfinex could have been withdrawn before manual intervention was required (with offline keys). Who will accept > such an input and treat it as a payment if it can be reversed during the > settlement layer? Obviously, if a payment is reversible, then you treat it as a reversible payment. The protection here relates to moving coins from the equivalent of cold storage to hot storage. It is OK if it takes longer, since security is more important than convenience for coins in cold storage. > 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 relates to the reserves held by the exchange. A portion of the funds are in hot storage with live keys. These funds can be stolen by anyone who gets access to the servers. The remaining funds are held in cold storage and they cannot be accessed unless you have the offline keys. These funds are supposed to be hard to reach and require manual intervention. 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. > Setting up offline keys to act as firebreaks is part of good security practices.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
