Re: [bitcoin-dev] BIP clearing house addresses

[Tier Nolan <tier.nolan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3678 bytes --]