diff options
| author | Erik Aronesty <erik@q32.com> | 2016-08-04 08:43:34 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-04 12:43:37 +0000 |
| commit | 341878f168ce75c0d45d2114f1af608a6c351dd5 (patch) | |
| tree | 91d321f0a537521c3da16e3e08d74b90b5e410ff | |
| parent | 514657d3e26302e130693002954c14fa3d2e0a0b (diff) | |
| download | pi-bitcoindev-341878f168ce75c0d45d2114f1af608a6c351dd5.tar.gz pi-bitcoindev-341878f168ce75c0d45d2114f1af608a6c351dd5.zip | |
Re: [bitcoin-dev] BIP clearing house addresses
| -rw-r--r-- | c1/cdfd4102cb7ceff70b550a7cb713ba069484f3 | 298 |
1 files changed, 298 insertions, 0 deletions
diff --git a/c1/cdfd4102cb7ceff70b550a7cb713ba069484f3 b/c1/cdfd4102cb7ceff70b550a7cb713ba069484f3 new file mode 100644 index 000000000..ee350e51f --- /dev/null +++ b/c1/cdfd4102cb7ceff70b550a7cb713ba069484f3 @@ -0,0 +1,298 @@ +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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= +t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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""= +>>This is already possible. Just nLockTime your withdrawls for some futu= +re<br> +block. Don't sign any transaction that isn't nLockTime'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'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't think there is) there'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'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 "relative lock-t= +imed" 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>>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"><<a href=3D"mailto:andrew.johnson8= +3@gmail.com" target=3D"_blank">andrew.johnson83@gmail.com</a>></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">"This is a= +lready possible. Just nLockTime your withdrawls for some future<br> +block. Don't sign any transaction that isn't nLockTime'd at lea= +st N blocks<br> +beyond the present tip."</p> +</span><p dir=3D"ltr">This would have prevented the Bitfinex hack if BitGo = +did this, but it wouldn'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's hot key and BitGo's key, they req= +uired 2 of 2.</p> +<p dir=3D"ltr">If I'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't think this will work. What do you do if the = +keys are compromised?=C2=A0 What'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'd need a third distinct key required for the refund = +TXN that'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, "Luke Dashjr via bitcoin-dev" <<a href=3D"ma= +ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l= +ists.<wbr>linuxfoundation.org</a>> 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> +> In light of the recent hack: what does everyone think of the idea of<b= +r> +> creating a new address type that has a reversal key and settlement lay= +er<br> +> that can be used to revoke transactions?<br> +<br> +This isn'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> +> You could specify so that transactions "sent" from these add= +resses must<br> +> receive N confirmations before they can't be revoked, after which = +the<br> +> transaction is "settled" and the coins become redeemable fro= +m their<br> +> destination output. A settlement phase would also mean that a transact= +ion's<br> +> progress was publicly visible so transparent fraud prevention and audi= +ting<br> +> would become possible by anyone.<br> +<br> +This is already possible. Just nLockTime your withdrawls for some future<br= +> +block. Don't sign any transaction that isn't nLockTime'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-- + |