diff options
author | Sergio Demian Lerner <sergio.d.lerner@gmail.com> | 2019-08-07 23:09:20 -0300 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-08-08 02:10:00 +0000 |
commit | 033fd3a8716877d68653452797c9e7c02bf42bce (patch) | |
tree | ea93c54868fe6639fc550c279834d59db8aab871 | |
parent | 6c9f68a1aa6e7098c2a9b3858ae0f27024d123c8 (diff) | |
download | pi-bitcoindev-033fd3a8716877d68653452797c9e7c02bf42bce.tar.gz pi-bitcoindev-033fd3a8716877d68653452797c9e7c02bf42bce.zip |
Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
-rw-r--r-- | 0e/1cf3ac0090585d3b6470cc06159e2cceb28a29 | 255 |
1 files changed, 255 insertions, 0 deletions
diff --git a/0e/1cf3ac0090585d3b6470cc06159e2cceb28a29 b/0e/1cf3ac0090585d3b6470cc06159e2cceb28a29 new file mode 100644 index 000000000..01da23c6d --- /dev/null +++ b/0e/1cf3ac0090585d3b6470cc06159e2cceb28a29 @@ -0,0 +1,255 @@ +Return-Path: <sergio.d.lerner@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 21AE4CC4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 8 Aug 2019 02:10:00 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com + [209.85.208.172]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12544829 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 8 Aug 2019 02:09:59 +0000 (UTC) +Received: by mail-lj1-f172.google.com with SMTP id h10so15870940ljg.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 07 Aug 2019 19:09:58 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=fCpOxnUupu8GoN4sIxf9uutOAf7HgiYYOw5kk1Dwj3s=; + b=Gt8rOXfw5+lHKje77T1pvjyVnDmmuLroO3djOMj244pEW8IN9Nwezm09v+Xik2LElJ + 96FZtix73GR2syVi4wD5tXdbbQI2RyEYmI2R/TZksJrqfiREhx7LigAg34HneF4Syfvk + Q+Ty8kXHH5Ey9tx5sm1PE9JUFJjnmJctOXhuXrOnaHLwIdoMGlwG5KvzIKIMLZHH4tgg + E9Gg/6dkreG4KoY78kRwbIU/KlkV/kVGtF7KiPSNZu1uSsMHajyN3j6R3wfbLBe+fC4m + njCbi1Dcxz19L+dVP+adLgcFKrT7CDCYaFcal0tcCPHyi0rjeXLDcn72vD9DNHYMUn44 + 6mww== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=fCpOxnUupu8GoN4sIxf9uutOAf7HgiYYOw5kk1Dwj3s=; + b=LhEqpbZmQ7BsR64RyqIdBfIm4BeXxl1YD5FGc01uej4SNih3Pb+o01ZFWsNW1yHr+Y + Jr+uoav97ubzq/YWKJtye8lYuryEEiJzlJ4E62ROxitzpZTxc08ZzJCeKTLpU9zjoLtc + 0RHlhnKiqsHJsL3pSZ8Uuk9rpVVtIY7cdKePP+qd5paftdxCQCxdlvrEHh07matugmRt + UMnHukEApKkPp7W/XwTm1ZrvjjEwOX7bm0O3cqtkFFjALIMBh7EdrGt6t/35jyzfyo3C + 6fCuaSs3+lpA2/tyZ0J3XlXrA3xJPonC+XkQ5Bh9tI4z90LdqVxj4okNbxGMJrFHMkjU + v6Jw== +X-Gm-Message-State: APjAAAUo9SxXdgoW3eYY/4ZNNvcEXICbhORbHDu9lTZZLCNcBmY2PNkp + HmUQbgfoXpR8kJKVr12O+T/M7wqUVNCbVEMI9GA= +X-Google-Smtp-Source: APXvYqxwD0wlI5XzAZVAOOWeVEsG/IW5KNOk2d+M4xGqz5H+E12y40oFk5KMZL9jtZE920pQmaoSWTQcjZcT0DO5wp8= +X-Received: by 2002:a2e:9dca:: with SMTP id x10mr6408395ljj.17.1565230197316; + Wed, 07 Aug 2019 19:09:57 -0700 (PDT) +MIME-Version: 1.0 +References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com> + <CABaSBawQhC5EDbyc8c0rk1JxjF2NJBn+mb6tPgvTwkNXOPcSGg@mail.gmail.com> + <CABLeJxTE09d3ujndAhrxiVwBmXkdxyUM9QfKTE69QQcNDbr5Qg@mail.gmail.com> +In-Reply-To: <CABLeJxTE09d3ujndAhrxiVwBmXkdxyUM9QfKTE69QQcNDbr5Qg@mail.gmail.com> +From: Sergio Demian Lerner <sergio.d.lerner@gmail.com> +Date: Wed, 7 Aug 2019 23:09:20 -0300 +Message-ID: <CAKzdR-q3nnWggUz7aE0p1ts8KsWVigznjuJpR1SNzKNXs+GmiA@mail.gmail.com> +To: Dustin Dettmer <dustinpaystaxes@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000e71f3f058f918d04" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, 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 +X-Mailman-Approved-At: Thu, 08 Aug 2019 02:14:03 +0000 +Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback + mechanisms +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, 08 Aug 2019 02:10:00 -0000 + +--000000000000e71f3f058f918d04 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Seems to be comparable to the proposed "Tick Method" from 2013: +https://bitcointalk.org/index.php?topic=3D307211.msg3308565#msg3308565 + +However I remember that someone told me the tick method had a flaw.. + + + +On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Does revaulting vault up with the same keys, or new ones? +> +> Are they new derivation paths on the same key? +> +> Would love some expanded explanation on how you=E2=80=99re proposing this= + would +> work. +> +> Thanks, +> Dustin +> +> On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> Hi, +>> +>> One of the biggest problems with the vault scheme (besides all of the +>> setup data that has to be stored for a long time) is an attacker that +>> silently steals the hot wallet private key and waits for the vault's +>> owner to make a delayed-spend transaction to initiate a withdrawal +>> from the vault. If the user was unaware of the theft of the key, then +>> the attacker could steal the funds after the delay period. +>> +>> To mitigate this, it is important to choose a stipend or withdrawal +>> amount per withdrawal period like x% of the funds. This limits the +>> total stolen funds to x% because once the funds are stolen the user +>> would know their hot key is compromised, and the user would know to +>> instead use one of the other clawback paths during all of the future +>> withdrawal delay periods instead of letting the delay timeout all the +>> way to the (stolen) default/hot key. +>> +>> The reason why a loss limiter is the way to go is because there's +>> currently no way (that I am aware of, without an upgrade) to force an +>> attacker to reveal his key on the blockchain while also forcing the +>> attacker to use a timelock before the key can spend the coins. I am +>> curious about what the smallest least invasive soft-fork would be for +>> enabling this kind of timelock. There are so many covenant proposals +>> at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY, +>> ....). Or there's crazy things like a fork that enables a transaction +>> mode where the (timelock...) script of the first output is +>> automatically prefixed to any of the other scripts on any of the other +>> outputs when an input tries to spend in the future. A thief could add +>> his key to a new output on the transaction and try to spend (just like +>> a user would with a fresh/rotated key), but the OP_CSV would be +>> automatically added to his script to implement the public observation +>> delay window. +>> +>> Also, there was other previous work that I was only informed about +>> today after posting my proposal, so I should mention these as related +>> work: +>> +>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/01= +5793.html +>> +>> https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-be= +tter +>> https://www.youtube.com/watch?v=3DdiNxp3ZTquo +>> https://bitcointalk.org/index.php?topic=3D5111656 +>> +>> - Bryan +>> http://heybryan.org/ +>> _______________________________________________ +>> 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 +> + +--000000000000e71f3f058f918d04 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Seems to be comparable to the proposed "Tick Method&q= +uot; from 2013:<div><a href=3D"https://bitcointalk.org/index.php?topic=3D30= +7211.msg3308565#msg3308565">https://bitcointalk.org/index.php?topic=3D30721= +1.msg3308565#msg3308565</a>=C2=A0</div><div><br></div><div>However I rememb= +er that someone told me the tick method had a flaw..</div><div>=C2=A0<br></= +div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl= +ass=3D"gmail_attr">On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoi= +n-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-= +dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"= +gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= +4,204,204);padding-left:1ex"><div><div dir=3D"auto">Does revaulting vault u= +p with the same keys, or new ones?</div></div><div dir=3D"auto"><br></div><= +div dir=3D"auto">Are they new derivation paths on the same key?</div><div d= +ir=3D"auto"><br></div><div dir=3D"auto">Would love some expanded explanatio= +n on how you=E2=80=99re proposing this would work.</div><div dir=3D"auto"><= +br></div><div dir=3D"auto">Thanks,</div><div dir=3D"auto">Dustin</div><div>= +<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed= +, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <<a href=3D"mailto= +:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists= +.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quo= +te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= +);padding-left:1ex">Hi,<br> +<br> +One of the biggest problems with the vault scheme (besides all of the<br> +setup data that has to be stored for a long time) is an attacker that<br> +silently steals the hot wallet private key and waits for the vault's<br= +> +owner to make a delayed-spend transaction to initiate a withdrawal<br> +from the vault. If the user was unaware of the theft of the key, then<br> +the attacker could steal the funds after the delay period.<br> +<br> +To mitigate this, it is important to choose a stipend or withdrawal<br> +amount per withdrawal period like x% of the funds. This limits the<br> +total stolen funds to x% because once the funds are stolen the user<br> +would know their hot key is compromised, and the user would know to<br> +instead use one of the other clawback paths during all of the future<br> +withdrawal delay periods instead of letting the delay timeout all the<br> +way to the (stolen) default/hot key.<br> +<br> +The reason why a loss limiter is the way to go is because there's<br> +currently no way (that I am aware of, without an upgrade) to force an<br> +attacker to reveal his key on the blockchain while also forcing the<br> +attacker to use a timelock before the key can spend the coins. I am<br> +curious about what the smallest least invasive soft-fork would be for<br> +enabling this kind of timelock. There are so many covenant proposals<br> +at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,<br> +....). Or there's crazy things like a fork that enables a transaction<b= +r> +mode where the (timelock...) script of the first output is<br> +automatically prefixed to any of the other scripts on any of the other<br> +outputs when an input tries to spend in the future. A thief could add<br> +his key to a new output on the transaction and try to spend (just like<br> +a user would with a fresh/rotated key), but the OP_CSV would be<br> +automatically added to his script to implement the public observation<br> +delay window.<br> +<br> +Also, there was other previous work that I was only informed about<br> +today after posting my proposal, so I should mention these as related<br> +work:<br> +<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Feb= +ruary/015793.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux= +foundation.org/pipermail/bitcoin-dev/2018-February/015793.html</a><br> +<a href=3D"https://blog.oleganza.com/post/163955782228/how-segwit-makes-sec= +urity-better" rel=3D"noreferrer" target=3D"_blank">https://blog.oleganza.co= +m/post/163955782228/how-segwit-makes-security-better</a><br> +<a href=3D"https://www.youtube.com/watch?v=3DdiNxp3ZTquo" rel=3D"noreferrer= +" target=3D"_blank">https://www.youtube.com/watch?v=3DdiNxp3ZTquo</a><br> +<a href=3D"https://bitcointalk.org/index.php?topic=3D5111656" rel=3D"norefe= +rrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D5111656</= +a><br> +<br> +- Bryan<br> +<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:= +//heybryan.org/</a><br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--000000000000e71f3f058f918d04-- + |