Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 941F783D for ; 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 ; Thu, 4 Aug 2016 12:43:36 +0000 (UTC) Received: by mail-yw0-f172.google.com with SMTP id j12so249167099ywb.2 for ; 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: References: <201608040327.36571.luke@dashjr.org> From: Erik Aronesty Date: Thu, 4 Aug 2016 08:43:34 -0400 X-Google-Sender-Auth: RV_W6VYIB76iTIlO-sgr9qmMj04 Message-ID: To: Matthew Roberts , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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

= 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 futu= re
block. Don't sign any transaction that isn't nLockTime'd at lea= st N blocks
beyond the present tip.

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.=

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.

>And the ref= und 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> wr= ote:

"This is a= lready possible. Just nLockTime your withdrawls for some future
block. Don't sign any transaction that isn't nLockTime'd at lea= st 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 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.

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.

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?

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.


On Aug = 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
=
On Wednesday, August 03, 201= 6 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 lay= er
> that can be used to revoke transactions?

This isn't something that makes sense at the address, since it represen= ts the
recipient and not the sender. Transactions are not sent from addresses ever= .

> You could specify so that transactions "sent" from these add= resses must
> receive N confirmations before they can't be revoked, after which = the
> transaction is "settled" and the coins become redeemable fro= m their
> destination output. A settlement phase would also mean that a transact= ion's
> progress was publicly visible so transparent fraud prevention and audi= ting
> 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 lea= st 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--