Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 21AE4CC4 for ; 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 ; Thu, 8 Aug 2019 02:09:59 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id h10so15870940ljg.0 for ; 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: In-Reply-To: From: Sergio Demian Lerner Date: Wed, 7 Aug 2019 23:09:20 -0300 Message-ID: To: Dustin Dettmer , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Seems to be comparable to the proposed "Tick Method&q= uot; from 2013:

However I rememb= er that someone told me the tick method had a flaw..
=C2=A0


On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoi= n-dev <bitcoin-= dev@lists.linuxfoundation.org> wrote:
Does revaulting vault u= p with the same keys, or new ones?

<= div dir=3D"auto">Are they new derivation paths on the same key?

Would love some expanded explanatio= n on how you=E2=80=99re proposing this would work.
<= br>
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.linux= foundation.org/pipermail/bitcoin-dev/2018-February/015793.html
https://blog.oleganza.co= m/post/163955782228/how-segwit-makes-security-better
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/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e71f3f058f918d04--