MIME-Version: 1.0
In-Reply-To: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Sat, 6 Aug 2016 12:13:52 +0100
Message-ID: <CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114588d43fcc9f053965478f
Subject: Re: [bitcoin-dev] BIP clearing house addresses
Precedence: list

--001a114588d43fcc9f053965478f
Content-Type: text/plain; charset=UTF-8

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.

--001a114588d43fcc9f053965478f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
* reversal of transactions is impossible<br></blockquote><div><br></div><di=
v>I think it would be more accurate to say that the requirement is that rev=
ersal doesn&#39;t happen unexpectedly.=C2=A0 <br><br>If it is clear in the =
script that reversal is possible, then obviously the recipient can take tha=
t into consideration.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
* keep private keys private and safe. Lose them, it&#39;s like losing cash,=
<br>
you can just forget about it.<br></blockquote><div><br></div><div>Key manag=
ement is a thing.=C2=A0 Managing risk by keeping some keys offline is an im=
portant part of that.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
* while we try hard to make 0-conf as safe as possible (if there&#39;s no<b=
r>
RBF flag on the transaction), we make it almost impossible or very very<br>
expensive to reverse a confirmed transaction.<br></blockquote><div><br></di=
v>BitGo has an &quot;instant&quot; system where they promise to only sign o=
ne transaction for a given output.=C2=A0 If you trust BitGo, then this is s=
afe from double spending, since a double spender can&#39;t sign two transac=
tions.<br><br></div><div class=3D"gmail_quote">If BitGo had actually implem=
ented a daily withdrawal limit, then their system ends up similar to cold s=
torage.=C2=A0 Only 10% of the funds at Bitfinex could have been withdrawn b=
efore manual intervention was required (with offline keys).<br><br></div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Who will accept<br>
such an input and treat it as a payment if it can be reversed during the<br=
>
settlement layer? </blockquote><div><br></div><div>Obviously, if a payment =
is reversible, then you treat it as a reversible payment.=C2=A0 The protect=
ion here relates to moving coins from the equivalent of cold storage to hot=
 storage.=C2=A0 <br><br>It is OK if it takes longer, since security is more=
 important than convenience for coins in cold storage.<br></div><div>=C2=A0=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
The linked page describes that merchants will never accept payments from<br=
>
&#39;vaults&#39;, and it will take 24 hours for coins to be irreversible mo=
ved<br>
outside the &#39;vault&#39;.</blockquote><div><br></div><div>This relates t=
o the reserves held by the exchange.=C2=A0 A portion of the funds are in ho=
t storage with live keys.=C2=A0 These funds can be stolen by anyone who get=
s access to the servers.=C2=A0 The remaining funds are held in cold storage=
 and they cannot be accessed unless you have the offline keys.=C2=A0 These =
funds are supposed to be hard to reach and require manual intervention.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
I think this is a wrong approach. hacks and big losses are sad, but all<br>
the time users / exchanges are to blame for wrong implementations or<br>
terrible security practices.<br></blockquote><div><br></div><div>Setting up=
 offline keys to act as firebreaks is part of good security practices.<br><=
/div></div></div></div>

--001a114588d43fcc9f053965478f--