path: root/c1/cdfd4102cb7ceff70b550a7cb713ba069484f3

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 941F783D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  4 Aug 2016 12:43:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com
	[209.85.161.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51B66FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  4 Aug 2016 12:43:36 +0000 (UTC)
Received: by mail-yw0-f172.google.com with SMTP id j12so249167099ywb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 04 Aug 2016 05:43:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=c0xsnD7eTzmeQ4vXWEvLOzCzBwv90/wrbw2WdHrJUvY=;
	b=AIE5c182/Eh3mFkJ576qMV9f9yuOmraA2j098bMAwkfPDUylacr/vJ5rpqBn9nPksj
	RMm5zOw2Q1wsJoBcAp8E3ECNZhWhoYBbxbpkpmYLvXxGuKu5zNUygKCHysn+YXFd+Keq
	TfVWdKC7dth+u0iTo7XovXBoAwiZbuIOsTkqYIbA0HrswkHfmQ0X40PRv/S3lNnhITYV
	gNqYkYV1/dGnGNZcLjShjKjxdlbP5UgrzHfus7PqYD3f+BRDr1Y3RZWuQ8IGlXAZVSu8
	/225/iQHgGPriN/TcyxX1Mj4k3IXMsZ2Ky6DHDHzSv6sHyzMXDj7NVxkP83of6cf88W7
	RWPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=c0xsnD7eTzmeQ4vXWEvLOzCzBwv90/wrbw2WdHrJUvY=;
	b=C5oknNKIXMzjEf4RygWg3qbtRP/BxX27+LWg0l9Lqy2zGbbjxZi34U7YZYHri/Ky0z
	A582VdD7Yd/9mmyR7qSO/9H8D/RqS/CXUMVuOdGlnGBFgW85GpOb/LBtkFuHqB89VMdj
	lHzikjqubVSj7wv/SAzX8AGpZsk8D+C7TxxaVaYtVgO8NAcaXkgnfKxJfjFMBKDD32c0
	VO3fFlbtSRkEYMb8xily1JR4y2ClYT/DoieqPL6Zon8XN+rE3JcGLqFdMEeGiyV16lXi
	7o93MxkOEbemvJuJDnC35zODeTBpdZrrSyDM6pRovXcvVqygzUvxC0PZjh9V9Lh/I8a7
	3IIw==
X-Gm-Message-State: AEkoousw3z7jIy8wYaF1vt5EH/9Fr2sfwf0X3Grvh/Fv47UUQE6NU76vgF9WRj+yGCevZDKaJ8Di0Y9GRpBqew==
X-Received: by 10.13.239.193 with SMTP id y184mr55341428ywe.85.1470314615473; 
	Thu, 04 Aug 2016 05:43:35 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.37.88.214 with HTTP; Thu, 4 Aug 2016 05:43:34 -0700 (PDT)
In-Reply-To: <CAAEDBiGYz+q=1iTEQjQu2ewDw7QRS+EZQOrq6v4y6Z9RT+e-aQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<201608040327.36571.luke@dashjr.org>
	<CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>
	<CAAEDBiGYz+q=1iTEQjQu2ewDw7QRS+EZQOrq6v4y6Z9RT+e-aQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 4 Aug 2016 08:43:34 -0400
X-Google-Sender-Auth: RV_W6VYIB76iTIlO-sgr9qmMj04
Message-ID: <CAJowKgJXAJSJc=AiBSYWFBTRYk539hpQt-Q=xetCv3YhdhvQ1Q@mail.gmail.com>
To: Matthew Roberts <matthew@roberts.pm>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c033e125d0d4505393e4c78
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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: Thu, 04 Aug 2016 12:43:37 -0000

--94eb2c033e125d0d4505393e4c78
Content-Type: text/plain; charset=UTF-8

https://www.reddit.com/r/Bitcoin/comments/4w016b/use_of_payment_channels_to_mitigate_exchange_risk/

On Thu, Aug 4, 2016 at 12:53 AM, Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip.
>
> The problem with nLockTimed transactions is a centralized exchange isn't
> going to know ahead of time where those locked transactions need to go or
> the amount that needs to be signed so you will end up having to keep the
> private key around. If there was a way to create these transactions offline
> with special SIG_HASH flags (and I don't think there is) there's nothing
> about nLockTime that forces that the transactions be broadcast straight
> away and plus: since the TXs aren't confirmed until the lock-time expires
> they can be overwritten anyway.
>
> I think given the requirements that a centralized exchange has:
> TierNolan's idea is the best so far. Essentially, you have a new type of
> output script that forces the redeemer to use a designated output script
> template in the redeeming transaction, meaning that you can actually force
> people to send coins into another transaction with "relative lock-timed"
> outputs. The new transaction can then only be redeemed at the destination
> after the relative lock-time expires OR it can be moved before-hand to a
> designated off-line recovery address. This is much better than creating a
> new transaction system, IMO.
>
> >And the refund TXN would need to be able to go to a new address entirely.
>
> Agreed.
>
> On Thu, Aug 4, 2016 at 1:49 PM, Andrew Johnson <andrew.johnson83@gmail.com
> > wrote:
>
>> "This is already possible. Just nLockTime your withdrawls for some future
>> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
>> beyond the present tip."
>>
>> This would have prevented the Bitfinex hack if BitGo did this, but it
>> wouldn't have helped if the Bitfinex offline key had been compromised
>> instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
>> by Bitfinex's hot key and BitGo's key, they required 2 of 2.
>>
>> If I'm understanding correctly, what Matthew is proposing is a new type
>> of UTXO that is only valid to be spent as an nLockTime transaction and can
>> be reversed by some sort of RBF-type transaction within that time period, I
>> believe.
>>
>> But I don't think this will work. What do you do if the keys are
>> compromised?  What's to stop the attacker from locking the coins up
>> indefinitely by repeatedly broadcasting a refund transaction each time you
>> try to spend to an uncompromised address?
>>
>> You'd need a third distinct key required for the refund TXN that's
>> separate from the keys used to sign the initial nLockTime TXN.  And the
>> refund TXN would need to be able to go to a new address entirely.
>>
>> On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Wednesday, August 03, 2016 6:16:20 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?
>>>
>>> This isn't something that makes sense at the address, since it
>>> represents the
>>> recipient and not the sender. Transactions are not sent from addresses
>>> ever.
>>>
>>> > 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.
>>>
>>> This is already possible. Just nLockTime your withdrawls for some future
>>> block. Don't sign any transaction that isn't nLockTime'd at least N
>>> blocks
>>> beyond the present tip.
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><a href=3D"https://www.reddit.com/r/Bitcoin/comments/4w016=
b/use_of_payment_channels_to_mitigate_exchange_risk/">https://www.reddit.co=
m/r/Bitcoin/comments/4w016b/use_of_payment_channels_to_mitigate_exchange_ri=
sk/</a><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Aug 4, 2016 at 12:53 AM, Matthew Roberts via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><span class=3D""=
>&gt;This is already possible. Just nLockTime your withdrawls for some futu=
re<br>
block. Don&#39;t sign any transaction that isn&#39;t nLockTime&#39;d at lea=
st N blocks<br>
beyond the present tip.<br><br></span>The problem with nLockTimed transacti=
ons is a centralized exchange isn&#39;t going to know ahead of time where t=
hose locked transactions need to go or the amount that needs to be signed s=
o you will end up having to keep the private key around. If there was a way=
 to create these transactions offline with special SIG_HASH flags (and I do=
n&#39;t think there is) there&#39;s nothing about nLockTime that forces tha=
t the transactions be broadcast straight away and plus: since the TXs aren&=
#39;t confirmed until the lock-time expires they can be overwritten anyway.=
<br><br></div>I think given the requirements that a centralized exchange ha=
s: TierNolan&#39;s idea is the best so far. Essentially, you have a new typ=
e of output script that forces the redeemer to use a designated output scri=
pt template in the redeeming transaction, meaning that you can actually for=
ce people to send coins into another transaction with &quot;relative lock-t=
imed&quot; outputs. The new transaction can then only be redeemed at the de=
stination after the relative lock-time expires OR it can be moved before-ha=
nd to a designated off-line recovery address. This is much better than crea=
ting a new transaction system, IMO.<span class=3D""><br><br>&gt;And the ref=
und TXN would need to be able to go to a new address entirely.<br><br></spa=
n></div>Agreed.<br></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Aug 4, 2016 at 1:49=
 PM, Andrew Johnson <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew.johnson8=
3@gmail.com" target=3D"_blank">andrew.johnson83@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span><p dir=3D"ltr">&quot;This is a=
lready possible. Just nLockTime your withdrawls for some future<br>
block. Don&#39;t sign any transaction that isn&#39;t nLockTime&#39;d at lea=
st N blocks<br>
beyond the present tip.&quot;</p>
</span><p dir=3D"ltr">This would have prevented the Bitfinex hack if BitGo =
did this, but it wouldn&#39;t have helped if the Bitfinex offline key had b=
een compromised instead of BitGo doing the 2nd sig.=C2=A0 In the BFX hack t=
he TXNs were signed by Bitfinex&#39;s hot key and BitGo&#39;s key, they req=
uired 2 of 2.</p>
<p dir=3D"ltr">If I&#39;m understanding correctly, what Matthew is proposin=
g is a new type of UTXO that is only valid to be spent as an nLockTime tran=
saction and can be reversed by some sort of RBF-type transaction within tha=
t time period, I believe.</p>
<p dir=3D"ltr">But I don&#39;t think this will work. What do you do if the =
keys are compromised?=C2=A0 What&#39;s to stop the attacker from locking th=
e coins up indefinitely by repeatedly broadcasting a refund transaction eac=
h time you try to spend to an uncompromised address?</p>
<p dir=3D"ltr">You&#39;d need a third distinct key required for the refund =
TXN that&#39;s separate from the keys used to sign the initial nLockTime TX=
N.=C2=A0 And the refund TXN would need to be able to go to a new address en=
tirely.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div>On Aug =
3, 2016 11:28 PM, &quot;Luke Dashjr via bitcoin-dev&quot; &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"></div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><div>On Wednesday, August 03, 201=
6 6:16:20 PM Matthew Roberts via bitcoin-dev<br>
wrote:<br>
&gt; In light of the recent hack: what does everyone think of the idea of<b=
r>
&gt; creating a new address type that has a reversal key and settlement lay=
er<br>
&gt; that can be used to revoke transactions?<br>
<br>
This isn&#39;t something that makes sense at the address, since it represen=
ts the<br>
recipient and not the sender. Transactions are not sent from addresses ever=
.<br>
<br>
&gt; You could specify so that transactions &quot;sent&quot; from these add=
resses must<br>
&gt; receive N confirmations before they can&#39;t be revoked, after which =
the<br>
&gt; transaction is &quot;settled&quot; and the coins become redeemable fro=
m their<br>
&gt; destination output. A settlement phase would also mean that a transact=
ion&#39;s<br>
&gt; progress was publicly visible so transparent fraud prevention and audi=
ting<br>
&gt; would become possible by anyone.<br>
<br>
This is already possible. Just nLockTime your withdrawls for some future<br=
>
block. Don&#39;t sign any transaction that isn&#39;t nLockTime&#39;d at lea=
st N blocks<br>
beyond the present tip.<br>
<br>
Luke<br></div></div><span>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</span></blockquote></div></div>
</blockquote></div><br></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>

--94eb2c033e125d0d4505393e4c78--