diff options
| author | Tier Nolan <tier.nolan@gmail.com> | 2016-08-06 12:13:52 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-06 11:13:55 +0000 |
| commit | 0bfc0ffca7078bbb19c1da673bdebcf767c00b88 (patch) | |
| tree | 81ec254146941ffc6e48b076d9deda41f0897d7e | |
| parent | 8db30ab9bb6f9e59a91aa19075981770b9bce576 (diff) | |
| download | pi-bitcoindev-0bfc0ffca7078bbb19c1da673bdebcf767c00b88.tar.gz pi-bitcoindev-0bfc0ffca7078bbb19c1da673bdebcf767c00b88.zip | |
Re: [bitcoin-dev] BIP clearing house addresses
| -rw-r--r-- | 14/3e7fc0339bb35f3d32ad2205b2ef03d27a67e2 | 203 |
1 files changed, 203 insertions, 0 deletions
diff --git a/14/3e7fc0339bb35f3d32ad2205b2ef03d27a67e2 b/14/3e7fc0339bb35f3d32ad2205b2ef03d27a67e2 new file mode 100644 index 000000000..a9c50fc96 --- /dev/null +++ b/14/3e7fc0339bb35f3d32ad2205b2ef03d27a67e2 @@ -0,0 +1,203 @@ +Return-Path: <tier.nolan@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6843A71 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Aug 2016 11:13:55 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qk0-f196.google.com (mail-qk0-f196.google.com + [209.85.220.196]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 70C9A16B + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Aug 2016 11:13:54 +0000 (UTC) +Received: by mail-qk0-f196.google.com with SMTP id q62so25391833qkf.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 06 Aug 2016 04:13:54 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to; + bh=gnBcCkLS3vyFkO3sjGGpf+Ba5C9RrV9sZ9VyYX4E7EU=; + b=vCGPnON3kuXbrUVeaCTK0o+OoxH7in/Tz909XyFzFNo2wupZKTtPR56IKzYq+kaan8 + j4ZR3oEX2R/N3/Snxtk6yxhPty9qKlkp06/XZxcfjGPVVZHIt5o4hpKARpPnqs9EWW5k + eVXPE0SRnu0rIzL+iNuHAs+MNWd45yzuAn8OZGpSPYM0RgGsWkW8tqhLi9CU6GSUXPQv + Km+5iSw70jyEdzKVRGTfKOWrOSqMlBGiCiBNFVQLP+2ysFCNBH3aaWG5+dq2+FjBBD+S + J/Q7srN0PbhpINfNsb4IJ7riha+XUC2pddT2Wo7gQbPdTONu7bcwy+4LDPyENy5NK4Ke + CwOg== +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=gnBcCkLS3vyFkO3sjGGpf+Ba5C9RrV9sZ9VyYX4E7EU=; + b=eE9Po8ANCXlYogVrC8nqTKO1KsU6GV8sflotP+wXHTiAaYKJZ7jLQmnraKcUN21Wax + D8Hd/hjxp9FqqxCg6q6pu0xVQcS0ZX6W06N16Tat684Lc/0cS/lCS5mbZ0ukEGMX0A5E + +AyDbUPyV/Y/y0TgQXhk3kJm7Op0ZyepkCdt3ZNeJDkGOx/8P83O2gtXgB3pFLnFz5qM + rylFJIFg2Zl/GRrx89zLJ//em5TOqMkAJQm3eN43mXJeSEy6oCmBUSafhtSH2hsmzzhd + IThuAdmAet2X3uHE0M5HCxX9b8m89YNNMiEGZCwArYOM/IB4ieYScdH3k4VtWuSkvr7x + xXSA== +X-Gm-Message-State: AEkoout5PmYXs+HPgrLskUAO+RszkVvEw7Lrl8UxBmQaUNAPVsr4RcAROcWX2kdRSlESQcgEkd+GiDQ6c96p1Q== +X-Received: by 10.55.1.202 with SMTP id u71mr16549623qkg.195.1470482033395; + Sat, 06 Aug 2016 04:13:53 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.200.46.193 with HTTP; Sat, 6 Aug 2016 04:13:52 -0700 (PDT) +In-Reply-To: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org> +References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com> + <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org> +From: Tier Nolan <tier.nolan@gmail.com> +Date: Sat, 6 Aug 2016 12:13:52 +0100 +Message-ID: <CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a114588d43fcc9f053965478f +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 +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: Sat, 06 Aug 2016 11:13:55 -0000 + +--001a114588d43fcc9f053965478f +Content-Type: text/plain; charset=UTF-8 + +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 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 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 Bitfinex +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 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 keys. 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. + +--001a114588d43fcc9f053965478f +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S= +at, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <span dir=3D"ltr"><<a h= +ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc= +oin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote clas= +s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= +ding-left:1ex"> +* reversal of transactions is impossible<br></blockquote><div><br></div><di= +v>I think it would be more accurate to say that the requirement is that rev= +ersal doesn't happen unexpectedly.=C2=A0 <br><br>If it is clear in the = +script that reversal is possible, then obviously the recipient can take tha= +t into consideration.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_= +quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= +ex"> +* keep private keys private and safe. Lose them, it's like losing cash,= +<br> +you can just forget about it.<br></blockquote><div><br></div><div>Key manag= +ement is a thing.=C2=A0 Managing risk by keeping some keys offline is an im= +portant part of that.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_= +quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= +ex"> +* while we try hard to make 0-conf as safe as possible (if there'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>BitGo has an "instant" system where they promise to only sign o= +ne transaction for a given output.=C2=A0 If you trust BitGo, then this is s= +afe from double spending, since a double spender can't sign two transac= +tions.<br><br></div><div class=3D"gmail_quote">If BitGo had actually implem= +ented a daily withdrawal limit, then their system ends up similar to cold s= +torage.=C2=A0 Only 10% of the funds at Bitfinex could have been withdrawn b= +efore manual intervention was required (with offline keys).<br><br></div><d= +iv class=3D"gmail_quote"><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><div>Obviously, if a payment = +is reversible, then you treat it as a reversible payment.=C2=A0 The protect= +ion 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><div>=C2=A0= +<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= +er-left:1px #ccc solid;padding-left:1ex"> +The linked page describes that merchants will never accept payments from<br= +> +'vaults', and it will take 24 hours for coins to be irreversible mo= +ved<br> +outside the 'vault'.</blockquote><div><br></div><div>This relates t= +o the reserves held by the exchange.=C2=A0 A portion of the funds are in ho= +t storage with live keys.=C2=A0 These funds can be stolen by anyone who get= +s 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 intervention.<br>= +<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= +er-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><div>Setting up= + offline keys to act as firebreaks is part of good security practices.<br><= +/div></div></div></div> + +--001a114588d43fcc9f053965478f-- + |