summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSergio Demian Lerner <sergio.d.lerner@gmail.com>2019-08-07 23:09:20 -0300
committerbitcoindev <bitcoindev@gnusha.org>2019-08-08 02:10:00 +0000
commit033fd3a8716877d68653452797c9e7c02bf42bce (patch)
treeea93c54868fe6639fc550c279834d59db8aab871
parent6c9f68a1aa6e7098c2a9b3858ae0f27024d123c8 (diff)
downloadpi-bitcoindev-033fd3a8716877d68653452797c9e7c02bf42bce.tar.gz
pi-bitcoindev-033fd3a8716877d68653452797c9e7c02bf42bce.zip
Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
-rw-r--r--0e/1cf3ac0090585d3b6470cc06159e2cceb28a29255
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 &quot;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
+dev@lists.linuxfoundation.org</a>&gt; 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 &lt;<a href=3D"mailto=
+:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
+.linuxfoundation.org</a>&gt; 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&#39;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&#39;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&#39;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--
+