path: root/ca/87766458f036756450b70fee24c3de2ff9aad9

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DF5C2C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 15:03:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B1C1141748
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 15:03:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B1C1141748
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=qDqLv6hR
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id dwTMDdgBV_a0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 15:03:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3B44941723
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 3B44941723
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 15:03:14 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id v13so14637519eda.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 07:03:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=iWvqpf4LOkXYdIG02QQAFOD00ly2xgpNgvhG5B7iojw=;
 b=qDqLv6hRuvU/5gM5zvpxk2KusRcnFJuLl3vyz8ee6mIsLVoOx+5Y9KDuVFYmfTWd8O
 dLapU8UQlsepb8PlSK/n7SYDCFlfCBfM+jvrwV9UI6OI1kBdehNnUPrZyNzWAY75f2es
 etK/KA0Iam3d9Klkws+1g4IIx7jQqMt4S0t7oGXZqGMZVykNk5LvX/Xca80XbvYz1Pr5
 Sg7qiL5WDqcLxcQtetZPNBBIL56DCRlzYBTPvGzIfVvxM15aT8vpCdIQ5hhWZUUB1Rds
 HFZ5x0iQuLlau+J1lTyds/NF+XTWRCVnm0lN6V37QX8JotaftuzcfkfwBKIMcXhfI5nm
 mCHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=iWvqpf4LOkXYdIG02QQAFOD00ly2xgpNgvhG5B7iojw=;
 b=JJyVTWhcrSCCOMwjJ26MU4VdzJRBujOPD7dD2QA4cvB78fYTIAflLliTn5Q5tyciaO
 ZOmsb9KJ9CG2D8ci+WE2jjUm0QuuEdsJ1rR8AR1np4935S9smgAs7ZO2GgRB7vvcMcun
 /VrrhA7d05cHBjPddmI3+iqqhFDtnjuIqw62IUo6IeHmJZPLt5JPfU3LNkP9bzCgDXv9
 vcLkxkbc4vapBwKXhIHuNc2huuzWq3Kqk0aMwBZ4+aVdUieF/kL6Zg8mxzDi5dAiUnIw
 OkQ1c1KqHfPhtVeJze+5YsXDOO8GpxDJP/bLY8pee4+slLXCZVcAcV8pG+gFgLlHdbRG
 WCzw==
X-Gm-Message-State: AFqh2koHyFQHs8o18B00kb3/C+Y23PRHDWbokKaDbQStjGJuW8MiBAdP
 aY2LzkwiMhsqnggHznuXDctzageGhJ12uH1dMcI=
X-Google-Smtp-Source: AMrXdXuRXRKdsQ2p/HGxTGZvVJI59qS5Fa3LfgBLOf7/DVTvPvfiJt6zf411Mlki8clbcu/tBmbF8npGsEmi9WJfcS8=
X-Received: by 2002:a05:6402:5207:b0:46c:43ff:6961 with SMTP id
 s7-20020a056402520700b0046c43ff6961mr11282595edd.14.1675177392002; Tue, 31
 Jan 2023 07:03:12 -0800 (PST)
MIME-Version: 1.0
References: <CAGpPWDY+4G1Lb3J5XU_vHVgsOtbwhM=_WCt4-sbk17T3SoxaNw@mail.gmail.com>
 <rs4K-Lg4t58J2gfeXUPHK0CuctCn_sq6IlyZ7wobDR_cCCAkd_3JrRM4LVCrhxhd3PE4fnVveTEc0sYDmS9fqpIEUPFikC5PDUOlC9D_mhU=@protonmail.com>
In-Reply-To: <rs4K-Lg4t58J2gfeXUPHK0CuctCn_sq6IlyZ7wobDR_cCCAkd_3JrRM4LVCrhxhd3PE4fnVveTEc0sYDmS9fqpIEUPFikC5PDUOlC9D_mhU=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 31 Jan 2023 09:02:51 -0600
Message-ID: <CAGpPWDaaBKbc_evP94xHS9h_pJogPre0YiE1+Pe27WV4dn6MHA@mail.gmail.com>
To: darosior <darosior@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000062db3405f390a110"
X-Mailman-Approved-At: Tue, 31 Jan 2023 17:13:58 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wallet vaults with pre-signed transactions but no
 ephemeral keys
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 31 Jan 2023 15:03:17 -0000

--00000000000062db3405f390a110
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ah good to know someone's put work into this kind of idea. Thanks for the
reference!

On Thu, Jan 26, 2023 at 8:31 AM darosior <darosior@protonmail.com> wrote:

> Hello Billy,
>
> Yes it's basically a (simple) instantiation of Revault. You can find more
> at https://github.com/revault (you most likely want the
> `practical-revault` repo). There is a description of the concept, the
> specification of a communication protocol between the participants as wel=
l
> as the implementation of the whole.
>
> Such a design presents some advantages, but it has two major issues:
>
>    - You need to make sure all your watchtowers received the Cancel
>    signature before you sign the Unvault transaction. But how can you get=
 this
>    guarantee in the usual (and reasonable) model of an untrusted laptop?
>    - You can only have policies on the Unvault transaction (eg "You can
>    only Unvault up to X BTC during working hours"), not on the Spend
>    transaction (eg "You can only send coins to a Script with pubkey Y req=
uired
>    in all spending paths"). Revault allows to use cosigning servers that =
act
>    as anti-replay oracles to have policies on the spend, but this is obvi=
ously
>    *very* suboptimal.
>
>
> Both issues are solvable with covenants.
>
> Antoine Poinsot
> ------- Original Message -------
> Le lundi 23 janvier 2023 =C3=A0 6:39 PM, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
> In the discussion around James' OP_VAULT proposal, it was implied that
> precomputed vaults must use ephemeral keys that must be deleted as part o=
f
> the vaulting protocol, like Bryan Bishop's proposal
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/0172=
29.html>.
> Looking around, I haven't been able to find any wallet vault proposal tha=
t
> doesn't require ephemeral keys, so at the risk of posting something that'=
s
> obvious to everyone, I wanted to share a simple way to do a wallet vault
> without requiring any key deletion.
>
> The basic idea is to create an N-of-N multisig address, and pre-sign some
> transactions from it with N-1 keys to an address with several timelocked
> spend paths. This has the fallback that funds can always be spent
> immediately if you use all the keys, just like a normal N-of-N multisig
> address (since that's what it is at its core), but the usage of any of th=
e
> pre-signed transactions leads to an address that guarantees a clawback
> within a time window. Here's a 3-of-3 example:
>
> *Vault Initialization*:
> 1. Create 3 of 3 Vault Address
> 2. Create an Interim Address that can send with:
> * 1 of 3 keys after a timelock of 1 month
> * 2 of 3 keys after a timelock of 1 week
> * 3 of 3 keys with no timelock
>
> *Vaulting*:
> 1. Create a transaction sending an output to the Vault Address
> 2. Create a transaction spending that Vault Address output to the Interim
> Address
> 3. Presign one copy of the step-2 transaction for each of the three
> combinations of two keys.
> 4. Store seeds separately, store the wallet config as well as the three
> presigned transactions with each seed.
>
> *Unvaulting*:
> 1. Sign one of the pre-signed transactions with the missing signature.
> 2. Broadcast
> 3. Wait the appropriate timelock for the number of keys you want to sign
> with.
> 4. Create a transaction sending from the Interim Address.
> 5. Broadcast
>
> *Recovering *(after unvaulting step 2 after the broadcasted transaction
> to the Interim Address has been mined):
> 1. Sign the utxo with all three keys to any destination. Alternatively
> sign with two keys, wait 1 week.
> 2. Broadcast it
>
> This has the usual downsides of pre-signed vaults that you need to backup
> these transactions for each vaulting, complications involving the
> flexibility (or lack thereof) of fees, and inflexibility in how much to
> unvault (must be the whole utxo, no change). This could of course be
> augmented with various techniques to make fee handling more flexible
> (anchor outputs, multiple versions of the presigned transactions with
> different fees, etc). More complicated presigning schemes could allow for
> some flexibility in unvaulting amount (eg by sending change back into the
> vault, and creating additional pre-signed transactions for that new outpu=
t).
>
> It also has the same downside that OP_CTV vaults have, where a stolen key
> can steal funds from the interim address by racing the owner with their o=
wn
> transaction once the necessary delay has passed. Note that James' OP_VAUL=
T
> opcode wouldn't have this problem.
>
> But not requiring any toxic waste keys seems like a pretty good benefit
> over Bryan Bishop's original proposal.
>
> Anyways sorry if this was already on people's radar and just too obvious
> to post about.
>
>
>
>

--00000000000062db3405f390a110
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ah good to know someone&#39;s put work into this kind of i=
dea. Thanks for the reference!</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Jan 26, 2023 at 8:31 AM darosior &lt;=
<a href=3D"mailto:darosior@protonmail.com">darosior@protonmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div styl=
e=3D"font-family:arial;font-size:14px;color:rgb(0,0,0)">Hello Billy,</div><=
div style=3D"font-family:arial;font-size:14px;color:rgb(0,0,0)"><br></div><=
div style=3D"font-family:arial;font-size:14px;color:rgb(0,0,0)">Yes it&#39;=
s basically a (simple) instantiation of Revault. You can find more at <span=
><a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/revault=
/" target=3D"_blank">https://github.com/revault</a> (you most likely want t=
he `practical-revault` repo). There is a description of the concept, the sp=
ecification of a communication protocol between the participants as well as=
 the implementation of the whole.</span></div><div style=3D"font-family:ari=
al;font-size:14px;color:rgb(0,0,0)"><br></div><div style=3D"font-family:ari=
al;font-size:14px;color:rgb(0,0,0)">Such a design presents some advantages,=
 but it has two major issues:</div><div style=3D"font-family:arial;font-siz=
e:14px;color:rgb(0,0,0)"><ul><li><span>You need to make sure all your watch=
towers received the Cancel signature before you sign the Unvault transactio=
n. But how can you get this guarantee in the usual (and reasonable) model o=
f an untrusted laptop?<br></span></li><li><span>You can only have policies =
on the Unvault transaction (eg &quot;You can only Unvault up to X BTC durin=
g working hours&quot;), not on the Spend transaction (eg &quot;You can only=
 send coins to a Script with pubkey Y required in all spending paths&quot;)=
. Revault allows to use cosigning servers that act as anti-replay oracles t=
o have policies on the spend, but this is obviously *very* suboptimal.<br><=
/span></li></ul></div><div style=3D"font-family:arial;font-size:14px;color:=
rgb(0,0,0)"><br></div><div style=3D"font-family:arial;font-size:14px;color:=
rgb(0,0,0)">Both issues are solvable with covenants.</div><div style=3D"fon=
t-family:arial;font-size:14px;color:rgb(0,0,0)"><br></div><div style=3D"fon=
t-family:arial;font-size:14px;color:rgb(0,0,0)">Antoine Poinsot<br></div><d=
iv>
        ------- Original Message -------<br>
        Le lundi 23 janvier 2023 =C3=A0 6:39 PM, Billy Tetrud via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br=
><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr">In the discussion around James&#39; OP_VAULT p=
roposal, it was implied that precomputed vaults must use ephemeral keys tha=
t must be deleted as part of the vaulting protocol, like <a href=3D"https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html" r=
el=3D"noreferrer nofollow noopener" target=3D"_blank">Bryan Bishop&#39;s pr=
oposal</a>. Looking around, I haven&#39;t been able to find any wallet vaul=
t proposal that doesn&#39;t require ephemeral keys, so at the risk of posti=
ng something that&#39;s obvious to everyone, I wanted to share a simple way=
 to do a wallet vault without requiring any key deletion.<div><br></div><di=
v>The basic idea is to create an N-of-N multisig address, and pre-sign some=
 transactions from it with N-1 keys to an address with several timelocked s=
pend paths. This has the fallback that funds can always be spent immediatel=
y if you use all the keys, just like a normal N-of-N multisig address (sinc=
e that&#39;s what it is at its core), but the usage of any of the pre-signe=
d transactions leads to an address that guarantees a clawback within a time=
 window. Here&#39;s a 3-of-3 example:</div><div><div><br></div><div><b>Vaul=
t Initialization</b>:</div><div><div>1. Create 3 of 3 Vault Address<br>2. C=
reate an Interim Address that can send with:<br> * 1 of 3 keys after a time=
lock of 1 month<br> * 2 of 3 keys after a timelock of 1 week<br> * 3 of 3 k=
eys with no timelock</div><div><br></div><div><div><div><b>Vaulting</b>:</d=
iv></div></div><div>1. Create a transaction sending an output to the Vault =
Address<br></div><div>2. Create a transaction spending that Vault Address o=
utput to the Interim Address<br>3. Presign one copy of the step-2 transacti=
on for each of the three combinations of two keys.<br>4. Store seeds separa=
tely, store the wallet config as well as the three presigned transactions w=
ith each seed. <br><br><b>Unvaulting</b>:<br>1. Sign one of the pre-signed =
transactions with the missing signature.<br>2. Broadcast<br>3. Wait the app=
ropriate timelock for the number of keys you want to sign with.<br>4. Creat=
e a transaction sending from the Interim Address.<br>5. Broadcast</div><br>=
<b>Recovering </b>(after unvaulting step 2 after the broadcasted transactio=
n to the Interim Address has been mined):<br>1. Sign the utxo with all thre=
e keys to any destination. Alternatively sign with two keys, wait 1 week.<b=
r>2. Broadcast it<div><br></div></div></div><div>This has the usual downsid=
es of pre-signed vaults that you need to backup these transactions for each=
 vaulting, complications involving the flexibility (or lack thereof) of fee=
s, and inflexibility in how much to unvault (must be the whole utxo, no cha=
nge). This could of course be augmented with various techniques to make fee=
 handling more flexible (anchor outputs, multiple versions of the presigned=
 transactions with different fees, etc). More complicated presigning scheme=
s could allow for some flexibility in unvaulting amount (eg by sending chan=
ge back into the vault, and creating additional pre-signed transactions for=
 that new output).</div><div><br></div><div>It also has the same downside t=
hat OP_CTV vaults have, where a stolen key can steal funds from the interim=
 address by racing the owner with their own transaction once the necessary =
delay has passed. Note that James&#39; OP_VAULT opcode wouldn&#39;t have th=
is problem.</div><div><br></div><div>But not requiring any toxic waste keys=
 seems like a pretty good benefit over Bryan Bishop&#39;s original proposal=
. </div><div><br></div><div>Anyways sorry if this was already on people&#39=
;s radar and just too obvious to post about. </div><div><br></div><div><br>=
</div></div>

        </blockquote><br>
    </div></blockquote></div>

--00000000000062db3405f390a110--