path: root/e1/c558ec6f63461c8360d83c9720e9cc04688898

Return-Path: <matthew@roberts.pm>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 25D3A412
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Aug 2016 05:35:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f45.google.com (mail-it0-f45.google.com
	[209.85.214.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB866155
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Aug 2016 05:35:50 +0000 (UTC)
Received: by mail-it0-f45.google.com with SMTP id f6so57528620ith.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 06 Aug 2016 22:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=roberts-pm.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=bKInoWSAjjNY+BueLBQG9xEJyP6ZQAKQqr3jVI80HgY=;
	b=gPzYivFQaWILSbLb8Psu+YVwK0xRmLYtvdGQ6au04hCwYqiEWnE6rivC3GNNpzI5H+
	7BxJNTrWtMwf1t0Na3ShXJuPvJXfRR8B98/Y/T+lOVtNw5kWC6ilLvDVSdsHW9bj93BT
	oZNhpuSlnmOFejUhjva5V/mVKiMbOWsvv6QASp+aTfSBmOH4SBkzmdhvQvszBVDvahY5
	b/hshOlv5LtcpiV/zwWeFuGythRuDuXrXuMv2v22rvyFbn13EXIP324HGuq6+Ra1dKyE
	wOPIjm1R+ZaPYGt4KG6IREFzi86CREN6laqZrtyYjMA8NMKplxM9BddyCSIOX2fnzIdS
	JefA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=bKInoWSAjjNY+BueLBQG9xEJyP6ZQAKQqr3jVI80HgY=;
	b=UmHzwUw+yo2CH8YYyRlRLRXH7jSs8u8pfL7RkASDwgvizv1gNhIEY7V1PeqHPeqEfW
	qC6AW901tFjD7z3GalWpO/6FYrUCN+/DqLY1YjiFAbbC4miVtaRlRNRiZnmy9S4a8BrK
	tenuwhJOAtktCAxtgm2u3gw+6yheLLdidE04ONEXrMb+ynOn2f2Fp75lO7O4LBk4DdM3
	B1sw3rJZifi4Hv+K30G+rRaTRIISSwXV0hGS32Zpj8sL2eU+fc6XxEc+oGqMHFl1+JkS
	lCiK7TICgO738CId3e0qtK41yCth/Z6jy8BjU3CyH0pUlm+mfdTTwMbT8LWd5jQzi1P0
	NChg==
X-Gm-Message-State: AEkooutmK3fGfrRTNDwVt0DOlUgy5ZN3aLFxT1tiWVN1mqGxaUXjF9Gv4FNPXgHkOU52F7cifLsYDbzH7A5xMQ==
X-Received: by 10.36.20.9 with SMTP id 9mr11624054itg.24.1470548149930; Sat,
	06 Aug 2016 22:35:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.57.69 with HTTP; Sat, 6 Aug 2016 22:35:49 -0700 (PDT)
X-Originating-IP: [115.70.56.56]
In-Reply-To: <CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
	<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
From: Matthew Roberts <matthew@roberts.pm>
Date: Sun, 7 Aug 2016 15:35:49 +1000
Message-ID: <CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11446af81a2e5f053974acd4
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 07 Aug 2016 05:57:39 +0000
Subject: Re: [bitcoin-dev] BIP clearing house addresses
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Aug 2016 05:35:53 -0000

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

I'm wondering if we're fully on the same page here. What I was thinking was
that this protection mechanism would be applied to the coins in the hot
wallet (I wasn't talking about moving coins from the cold wallet to the hot
wallet -- though such a mechanism is also needed.)

With the hot wallet you would have an output script that only allowed coins
to be sent to a new transaction whose output script was then only
redeemable after N confirmations (the output is relative time-locked) but
which can also be recovered to a fixed fail-safe address before the
time-lock is reached (exactly like TierNolan already listed only the
time-locked destination shouldn't be completely fixed.) So the private key
for this hot wallet can still sign valid transactions to withdraw coins to
any known destination and these transactions still reach the blockchain.

The key difference from a regular transaction is that the destination only
has access to the coins -after- the relative time-lock is reached (N blocks
after first confirm) so everyone knows where withdrawals are suppose to be
going and how many coins are being withdrawn at any given time. Deposits to
the hot wallet would therefore need to be encumbered by the same protection
so that from then on this time-lock to redeem coins can be applied to every
new transaction trying to move coins (withdrawn by a user of the exchange
or sent to the cold wallet.)

Notice we don't care about the destination in the TX script for the hot
wallet because to process user's withdrawals we can't know ahead of time
where they need to be sent (so it isn't possible to use a fixed address
here =E2=80=93 though you might want to remove the clearing phase and set a=
 fixed
address for coins sent from the hot wallet to the cold wallet.) The benefit
here comes from being able to see what withdrawals are being cleared,
matching those up to our expectations, and being able to "cancel"
withdrawals if they look suspicious, and you get the benefits for transfers
made from the hot wallet to the cold wallet and visa-versa.


This approach is good for a number of crucial services:

1. Wallets could be built that grouped coins into different "accounts" with
different time-frames required for clearing / unlocking coins. Your savings
or investment account would say -- take up to a week to clear -- whereas
your everyday account used for smaller purchases (with less money) would
only take a few hours. This could all be linked up to services that
notified you of your money being moved + made any phone calls needed to
verify any larger transfers.

The service could also be entrusted with the =E2=80=9Ccancellation=E2=80=9D=
 key which can
only be used to move money to your offline fail-safe address. This would be
quite an interesting way to mitigate fraud without the user having to be
trusted to do anything (except I suppose =E2=80=93 not storing their recove=
ry keys
online =E2=80=A6 but this could be partially solved with BIP 32-style =E2=
=80=9Cmaster=E2=80=9D
public keys + hardware wallets + multi-sig, N factor auth, etc ...)

2. Gambling websites that process a lot of Bitcoins also have a hot wallet
which could be better protected by this.

3. Various other e-commerce websites also accept Bitcoins directly. (Deep
web markets come to mind -- hey, people breaking the law need good security
too.)

4. Provable dead man's switches on the protocol level is another idea -- no
need to keep special time-locked transactions around and rely on them to be
broadcast =3D more reliable escrow services.

5. And obviously exchange hot (and cold) wallets - enemy number 1.

I hope that makes sense. I think I initially managed to confuse a lot of
people by talking about revoking transactions / =E2=80=9Csettlement layers=
=E2=80=9D, etc.
But IMO: all of this needs to take place on the blockchain with a new set
of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
the general idea would still work.


tl; dr, A pseudo-reversal mechanism for transactions would mean that stolen
private keys were no longer such an issue. This is desperately needed for
exchanges, wallets, and other services that are forced to manage private
keys, and whose users (I argue) already expect for this to be possible (or
at least will when they're hacked.)




On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 th=
e
> 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 fr=
om
> 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 Bitfine=
x
> 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 fund=
s
> are in hot storage with live keys.  These funds can be stolen by anyone w=
ho
> 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 fund=
s
> 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
>
>

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

<div dir=3D"ltr">
<p style=3D"margin-bottom:0in">I&#39;m wondering if we&#39;re fully on the
same page here. What I was thinking was that this protection
mechanism would be applied to the coins in the hot wallet (I wasn&#39;t
talking about moving coins from the cold wallet to the hot wallet --
though such a mechanism is also needed.)</p>

<p style=3D"margin-bottom:0in">With the hot wallet you would have an
output script that only allowed coins to be sent to a new transaction
whose output script was then only redeemable after N confirmations (the
output is relative time-locked) but which can also be recovered to a
fixed fail-safe address before the time-lock is reached (exactly like
TierNolan already listed only the time-locked destination shouldn&#39;t
be completely fixed.) So the private key for this hot wallet can still sign
valid transactions to withdraw coins to any known destination and
these transactions still reach the blockchain.</p>

<p style=3D"margin-bottom:0in">The key difference from a regular
transaction is that the destination only has access to the coins
-after- the relative time-lock is reached (N blocks after first
confirm) so everyone knows where withdrawals are suppose to be going
and how many coins are being withdrawn at any given time. Deposits to
the hot wallet would therefore need to be encumbered by the same
protection so that from then on this time-lock to redeem coins can be
applied to every new transaction trying to move coins (withdrawn by a
user of the exchange or sent to the cold wallet.)</p>

<p style=3D"margin-bottom:0in">Notice we don&#39;t care about the
destination in the TX script for the hot wallet because to process
user&#39;s withdrawals we can&#39;t know ahead of time where they need to b=
e
sent (so it isn&#39;t possible to use a fixed address here =E2=80=93 though=
 you
might want to remove the clearing phase and set a fixed address for
coins sent from the hot wallet to the cold wallet.) The benefit here
comes from being able to see what withdrawals are being cleared,
matching those up to our expectations, and being able to &quot;cancel&quot;
withdrawals if they look suspicious, and you get the benefits for transfers=
 made from the hot wallet to the cold wallet and visa-versa.<br></p>
<p style=3D"margin-bottom:0in"><br>
</p>
<p style=3D"margin-bottom:0in">This approach is good for a number of
crucial services:</p>

<p style=3D"margin-bottom:0in">1. Wallets could be built that grouped
coins into different &quot;accounts&quot; with different time-frames
required for clearing / unlocking coins. Your savings or investment
account would say -- take up to a week to clear -- whereas your
everyday account used for smaller purchases (with less money) would
only take a few hours. This could all be linked up to services that
notified you of your money being moved + made any phone calls needed
to verify any larger transfers.</p>

<p style=3D"margin-bottom:0in">The service could also be entrusted
with the =E2=80=9Ccancellation=E2=80=9D key which can only be used to move =
money
to your offline fail-safe address. This would be quite an interesting
way to mitigate fraud without the user having to be trusted to do
anything (except I suppose =E2=80=93 not storing their recovery keys online
=E2=80=A6 but this could be partially solved with BIP 32-style =E2=80=9Cmas=
ter=E2=80=9D
public keys + hardware wallets + multi-sig, N factor auth, etc ...)</p>

<p style=3D"margin-bottom:0in">2. Gambling websites that process a lot
of Bitcoins also have a hot wallet which could be better protected by
this.</p>

<p style=3D"margin-bottom:0in">3. Various other e-commerce websites
also accept Bitcoins directly. (Deep web markets come to mind -- hey,
people breaking the law need good security too.)</p>

<p style=3D"margin-bottom:0in">4. Provable dead man&#39;s switches on the
protocol level is another idea -- no need to keep special time-locked
transactions around and rely on them to be broadcast =3D more reliable
escrow services.</p>
<br>5. And obviously exchange hot (and
	cold) wallets - enemy number 1.
<br><br>
<p style=3D"margin-bottom:0in">I hope that makes sense. I think I
initially managed to confuse a lot of people by talking about
revoking transactions / =E2=80=9Csettlement layers=E2=80=9D, etc. But IMO: =
all of
this needs to take place on the blockchain with a new set of OP_CODES
and other than the fixed address issue with OP_SPENDTO, I think the
general idea would still work.</p><p style=3D"margin-bottom:0in"><br></p>tl=
; dr, A pseudo-reversal mechanism for transactions would mean that stolen p=
rivate keys were no longer such an issue. This is desperately needed for ex=
changes, wallets, and other services that are forced to manage private keys=
, and whose users (I argue) already expect for this to be possible (or at l=
east will when they&#39;re hacked.)<br><p style=3D"margin-bottom:0in"><br>
</p>
<p style=3D"margin-bottom:0in"><br>
</p>
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Aug=
 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><span class=3D"">On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin=
-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* reversal of transactions is impossible<br></blockquote><div><br></div></s=
pan><div>I think it would be more accurate to say that the requirement is t=
hat reversal 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 t=
ake that into consideration.<br></div><span class=3D""><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
* 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></span><div>Ke=
y management is a thing.=C2=A0 Managing risk by keeping some keys offline i=
s an important part of that.<br></div><span class=3D""><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
* 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></span>BitGo has an &quot;instant&quot; system where they promise to only=
 sign one transaction for a given output.=C2=A0 If you trust BitGo, then th=
is is safe from double spending, since a double spender can&#39;t sign two =
transactions.<br><br></div><div class=3D"gmail_quote">If BitGo had actually=
 implemented a daily withdrawal limit, then their system ends up similar to=
 cold storage.=C2=A0 Only 10% of the funds at Bitfinex could have been with=
drawn before manual intervention was required (with offline keys).<br><br><=
/div><div class=3D"gmail_quote"><span class=3D""><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></span><div>Obviously, if a p=
ayment is reversible, then you treat it as a reversible payment.=C2=A0 The =
protection 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><spa=
n class=3D""><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-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></span><div>This re=
lates to the reserves held by the exchange.=C2=A0 A portion of the funds ar=
e in hot storage with live keys.=C2=A0 These funds can be stolen by anyone =
who gets 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 interventi=
on.<br><br></div><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-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></span><div>Set=
ting up offline keys to act as firebreaks is part of good security practice=
s.<br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a11446af81a2e5f053974acd4--