Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C8C3E92 for ; Mon, 8 Aug 2016 00:48:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 608461B9 for ; Mon, 8 Aug 2016 00:48:53 +0000 (UTC) Received: by mail-it0-f44.google.com with SMTP id x130so62632599ite.1 for ; Sun, 07 Aug 2016 17:48:53 -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 :cc; bh=BKsIeRYens47BRP7K6sGYHn9lJ6OShP7O4MKMoh+OMo=; b=LMYM1vehJzdR70Dc40kOwzb3UVDVumjS6nD6dkidbsCUUNs9LsvPMm1+VHFyC6C/Nt 5xXeMkecKe7XBm37mnpIoIQgiqZNt/P+gWGv3YjmxndiVfV2+taorkQTo0xQvPFqwMq6 X/e7Ma3PnlKtQ77+0f3tjQnRBDZbfY3pHJEgrflSjDoCpPVtDTAr2NzLN0Yme7rK3UFn zxBgK38sU6hbmYnZkPyJxiI859hEu8rFJulP8az3HIFRJCCq9PgK33JnQ/qlTD6rEhHl c7hhVfUOwbqS7vt8FUKawGdu6T8hORyraiOEaP3kJGIwW5YvAo89yAS6s0xS2ZPV9Wfo 5zXw== 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:cc; bh=BKsIeRYens47BRP7K6sGYHn9lJ6OShP7O4MKMoh+OMo=; b=ZwzOz+YKl8wal3G3CbFHqKk44+Oy15YtiO0Jw1qthzjsynfDAgngi96zA6ubG7EuU1 EOhuO+RA5hoNbV4ujS0TUv+ximsJJhjEuMioAaZN37TztuWNwyPTK/0QvTo2BZJlTtdO qXBiJNtLbwIhL8T3X9W9IFXtcJ5K9ILCdFGPkoMjkE/409e2AgHEcNpTawhsgJzkaalo b+kxOVHjCB7Ex4a4rNTjsC34ALnkW4+b5diKF26wmNzZkBNwgTBglX2S48uOsv22nIZB +JoMjcJ3zxa+wzeZR80ry0YRzmmpmU1O3u1+FP7vEXSHkkTZWV89Tny537F4SuhKUoNr JhVQ== X-Gm-Message-State: AEkoouvshP4UPg+hTcvcSYQkl7ANP8amaS13hMK+3TNVm55+RAjNubAbLndeSZ+E14Fg8LfJO7BLEzEmEEeHTQ== X-Received: by 10.36.212.6 with SMTP id x6mr14282978itg.71.1470617333207; Sun, 07 Aug 2016 17:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.57.69 with HTTP; Sun, 7 Aug 2016 17:48:52 -0700 (PDT) X-Originating-IP: [115.70.56.56] In-Reply-To: References: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org> From: Matthew Roberts Date: Mon, 8 Aug 2016 10:48:52 +1000 Message-ID: To: Erik Aronesty Content-Type: multipart/alternative; boundary=94eb2c0b046abf5f96053984c7c3 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: Mon, 08 Aug 2016 13:26:35 +0000 Cc: Bitcoin Protocol Discussion 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: Mon, 08 Aug 2016 00:48:56 -0000 --94eb2c0b046abf5f96053984c7c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not everyone who uses centralized exchanges are there to obtain the currency though. A large portion are speculators who need to be able to enter and exit complex positions in milliseconds and don't care about decentralization, security, and often even the asset that they're buying. Try telling everyone who currently uses Btc-e to go do their margin trading over lightning channels, for example. They're not going to want to do that because these exchanges are already meeting their needs perfectly well, and like I argued before -- it would be very hard to do that as efficiently with any other design (there are major drawbacks for traders with a decentralized exchange.) Like it or not, these exchanges play an integral role in the current Bitcoin eco-system since they allow us to most efficiently discover price and help improve liquidity. A decentralized exchange isn't going to stop any more centralized exchanges from being hacked even if they are more secure simply because traders don't want to use them. (Sorry for the duplicate message Erik, I haven't used many mailing lists before. I think I have the hang of it now though :) ) On Mon, Aug 8, 2016 at 8:59 AM, Erik Aronesty wrote: > I still feel like you're better off getting rid of "hot wallets" and use > lightning-esqe networks to route orders. I don't think either speed or > flexibility is an issue there. > > IMO, the point of Bitcoin is to avoid the centralization that seems to be > happening on the network now. By making "hot wallets" more "secure", we > encourage things to keep heading downhill with massive centralized > crappy-security exchanges. > > Because, ultimately, there's no security that will prevent an inside > job. And all of these thefts have, in my opinion, been at least partly > inside jobs. > > And centralization is the actually demon that needs slaying here. > > A client-side library with P2P order routing, tether.to + bitcoin .... > and you've got a decentralized exchange... with orders matched to users > directly, and channel-trades executed instantly. And "market makers" > running nodes to facilitate routing, etc. > > No center... nothing to shut down or sue... and no one holds your funds. > That's a real Bitcoin exchange. > > > > On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 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) bu= t >> 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 k= ey >> 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 supp= ose >> 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 us= er >> 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 se= t a fixed >> address for coins sent from the hot wallet to the cold wallet.) The bene= fit >> 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 transf= ers >> 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 mone= y) >> would only take a few hours. This could all be linked up to services tha= t >> 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 rec= overy 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. (Dee= p >> web markets come to mind -- hey, people breaking the law need good secur= ity >> 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 laye= rs=E2=80=9D, etc. >> But IMO: all of this needs to take place on the blockchain with a new se= t >> of OP_CODES and other than the fixed address issue with OP_SPENDTO, I th= ink >> 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 man= age >> 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 >>> 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 ver= y >>>> 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 Bitfi= nex >>> 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 t= he >>>> settlement layer? >>> >>> >>> Obviously, if a payment is reversible, then you treat it as a reversibl= e >>> payment. The protection here relates to moving coins from the equivale= nt >>> 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 fr= om >>>> '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 ke= ys. >>> 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. >>> >>> _______________________________________________ >>> 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 >> >> > --94eb2c0b046abf5f96053984c7c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Not everyone who uses centr= alized exchanges are there to obtain the currency though. A large portion are speculators who need to be able to enter and exit complex positions in milliseconds and don't care about decentralization, securi= ty, and often even the asset that they're buying.

Try telling everyone who currently uses Btc-e to go do their margin trading over lightning channels, for example. They're not going to want to do that because these exchanges are already meeting their needs perfectly well, and like I argued before --= it would be very hard to do that as efficiently with any other design (there are major drawbacks for traders with a decentralized exchange.)

Like it or not, these exchanges play an integral role in the current Bitcoin eco-system since they allow us to most efficiently discover price and help improve liquidity. A decentralized exchange isn't going to stop any more centralized exchanges from being hacked even if they are more secure simply because traders don't want to use them.

(Sorry for the duplicate message Erik, I haven't used many mailing l= ists before. I think I have the hang of it now though :) )


On Mon, Aug 8, 2016 = at 8:59 AM, Erik Aronesty <erik@q32.com> wrote:
I still feel like you're better = off getting rid of "hot wallets" and use lightning-esqe networks = to route orders.=C2=A0 I don't think either speed or flexibility is an = issue there.=C2=A0=C2=A0

IMO, the point of Bitcoin is to avoid the = centralization that seems to be happening on the network now.=C2=A0=C2=A0 B= y making "hot wallets" more "secure", we encourage thin= gs to keep heading downhill with massive centralized crappy-security exchan= ges.

Because, ultimately, there's no security that wi= ll prevent an inside job.=C2=A0=C2=A0 And all of these thefts have, in my o= pinion, been at least partly inside jobs.

And centralizat= ion is the actually demon that needs slaying here.

A clie= nt-side library with P2P order routing, tether.to + bitcoin ....=C2=A0 and you've got a decentr= alized exchange... with orders matched to users directly, and channel-trade= s executed instantly.=C2=A0=C2=A0 And "market makers" running nod= es to facilitate routing, etc.

No center... nothing to sh= ut down or sue... and no one holds your funds.=C2=A0=C2=A0 That's a rea= l Bitcoin exchange.



On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:

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 b= e 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 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 ...)

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 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're hacked.)




O= n 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.linu= xfoundation.org> wrote:
* keep private keys private and safe. Lose them, it's like losing cash,=
you can just forget about it.

Ke= y management is a thing.=C2=A0 Managing risk by keeping some keys offline i= s an important part of that.
=C2=A0
* 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.=C2=A0 If you trust BitGo, then th= is 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.=C2=A0 Only 10% of the funds at Bitfinex could have been with= drawn before manual intervention was required (with offline keys).

<= /div>
Who wi= ll accept
such an input and treat it as a payment if it can be reversed during the settlement layer?

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

It is OK if it takes longer, since security = is more important than convenience for coins in cold storage.
=C2=A0
The linked page describes that merchants will never accept payments from 'vaults', and it will take 24 hours for coins to be irreversible mo= ved
outside the 'vault'.

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.

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.

Set= ting up offline keys to act as firebreaks is part of good security practice= s.

_______________________________________________<= br> 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



--94eb2c0b046abf5f96053984c7c3--