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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wallet vaults with pre-signed transactions but no
 ephemeral keys
Precedence: list

--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--