Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id DF5C2C002B for ; 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 ; 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 ; 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 ; Tue, 31 Jan 2023 15:03:14 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id v13so14637519eda.11 for ; 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: In-Reply-To: From: Billy Tetrud Date: Tue, 31 Jan 2023 09:02:51 -0600 Message-ID: To: darosior Content-Type: multipart/alternative; boundary="00000000000062db3405f390a110" X-Mailman-Approved-At: Tue, 31 Jan 2023 17:13:58 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > . > 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
Ah good to know someone's put work into this kind of i= dea. Thanks for the reference!

On Thu, Jan 26, 2023 at 8:31 AM darosior <= darosior@protonmail.com> = wrote:
Hello Billy,
<= div style=3D"font-family:arial;font-size:14px;color:rgb(0,0,0)">
<= div style=3D"font-family:arial;font-size:14px;color:rgb(0,0,0)">Yes it'= s basically a (simple) instantiation of Revault. You can find more at https://github.com/revault (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.

Such a design presents some advantages,= but it has two major issues:
  • 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?
  • You can only have policies = on the Unvault transaction (eg "You can only Unvault up to X BTC durin= g working hours"), not on the Spend transaction (eg "You can only= send coins to a Script with pubkey Y required in all spending paths")= . 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.
    <= /span>

Both issues are solvable with covenants.

Antoine Poinsot
------- Original Message -------
Le lundi 23 janvier 2023 =C3=A0 6:39 PM, Billy Tetrud via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
In the discussion around James' 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 Bryan Bishop's pr= oposal. Looking around, I haven't been able to find any wallet vaul= t proposal that doesn't require ephemeral keys, so at the risk of posti= ng 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 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'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's a 3-of-3 example:

Vaul= t Initialization:
1. Create 3 of 3 Vault Address
2. C= reate an Interim Address that can send with:
* 1 of 3 keys after a time= lock of 1 month
* 2 of 3 keys after a timelock of 1 week
* 3 of 3 k= eys with no timelock

Vaulting:
1. Create a transaction sending an output to the Vault = Address
2. Create a transaction spending that Vault Address o= utput to the Interim Address
3. Presign one copy of the step-2 transacti= on for each of the three combinations of two keys.
4. Store seeds separa= tely, store the wallet config as well as the three presigned transactions w= ith each seed.

Unvaulting:
1. Sign one of the pre-signed = transactions with the missing signature.
2. Broadcast
3. Wait the app= ropriate timelock for the number of keys you want to sign with.
4. Creat= e a transaction sending from the Interim Address.
5. Broadcast

= Recovering (after unvaulting step 2 after the broadcasted transactio= n to the Interim Address has been mined):
1. Sign the utxo with all thre= e keys to any destination. Alternatively sign with two keys, wait 1 week.2. Broadcast it

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

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' OP_VAULT opcode wouldn't have th= is 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--