path: root/1a/cc27828abf6bbc2bdc426e2dc89ae64fcb624e

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 359C7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Jan 2023 17:40:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 102BF60F4A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Jan 2023 17:40:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 102BF60F4A
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=p2UxwviX
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id gLo3g4EuMd64
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Jan 2023 17:40:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A1E8260B94
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [IPv6:2a00:1450:4864:20::532])
 by smtp3.osuosl.org (Postfix) with ESMTPS id A1E8260B94
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Jan 2023 17:40:03 +0000 (UTC)
Received: by mail-ed1-x532.google.com with SMTP id s3so15508044edd.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Jan 2023 09:40:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=UwrFIk+oi5V3b0No/VZrIhZyUe8FimTmN8Pcmsg5/Kg=;
 b=p2UxwviXSXExPja5C9NLtYQnDtidNk3yQT6I0SzkftgJkR5k0bOESJADOcRIxn685a
 F9NPQaf4kZcI59AIpypiyJGWJ2Jj2m7ZA5v4rqTjZYMcCYCVlMV/umNF41veJCtGcuYd
 yAJGVeIsUgXdA7oXYjS5KUmphZqdOmuQzBhCmWjwqgATZ4uSBIJNkLqo8t2cfj+CO/o8
 VB3E4k17IPEmZGo8XQrZhnjejZl7+551+4D+omW72QSDZ9kE80Msf5Iun3k40EBQNtD5
 N21yz+a938GdjzwLXOv4tqemAMQAUmnTnjI9Tt5niYHjFSweDDaQ5D2w3Eod1aRkS/ky
 0mSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=UwrFIk+oi5V3b0No/VZrIhZyUe8FimTmN8Pcmsg5/Kg=;
 b=kiPiYq2ZEmpVeDf0okOtTIy8L6b961hgBZkZuKr3F2RWz5jn2paCsGPixCw3UMDQAT
 rJEnkJvm+gt6E41bnbS6HxRDOduWPggvHWKXmFzr6FRaZe6XbUjImA4K0MQF/3ZO5cpw
 fEIXNUqLsVKeHPh4ET+SqxPiJ3SR/K5I/8wQB0ar50ctZweedOeVPGTrRygNJj+RZ++h
 1E1AW5qSq1Z4eAW8VQZ9M45YpCqe2lSyH5QcYD+pODyAVNCqphWIk6CVBG/khbfOg/As
 ARa9m5NHVhZJAY/5eTXj+VMeneGgy2XtgS2Zbtb28GXsVyJEHOGk96n9Sx1RW55Q7Ric
 r+Dg==
X-Gm-Message-State: AFqh2kr2l+sRRasWi59kAzfvyu0FZDBQAxH3U1qmsoj4yv+zUhvKQp0H
 EeDk26KvM3RuT49V6+DvmIZPCWYVCM64+aGN1twquk13bP8=
X-Google-Smtp-Source: AMrXdXuQYCcyTBSRXz8jud9h3g1wxjw0g0UvDd7R8eSv2yGle73UPVJ0MItW0yqYfJucyo8hiqWI8Thlq5FGNxQJ/xo=
X-Received: by 2002:a05:6402:18d:b0:48e:c98a:579d with SMTP id
 r13-20020a056402018d00b0048ec98a579dmr2821365edv.147.1674495601266; Mon, 23
 Jan 2023 09:40:01 -0800 (PST)
MIME-Version: 1.0
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 23 Jan 2023 11:39:41 -0600
Message-ID: <CAGpPWDY+4G1Lb3J5XU_vHVgsOtbwhM=_WCt4-sbk17T3SoxaNw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007dd28905f2f1e3c6"
X-Mailman-Approved-At: Mon, 23 Jan 2023 17:44:54 +0000
Subject: [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: Mon, 23 Jan 2023 17:40:05 -0000

--0000000000007dd28905f2f1e3c6
Content-Type: text/plain; charset="UTF-8"

In the discussion around James' OP_VAULT proposal, it was implied that
precomputed vaults must use ephemeral keys that must be deleted as part of
the vaulting protocol, like Bryan Bishop's proposal
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html>.
Looking around, I haven't been able to find any wallet vault proposal that
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 the
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 output).

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 own
transaction once the necessary delay has passed. Note that James' OP_VAULT
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.

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

<div dir=3D"ltr">In the discussion around James&#39; OP_VAULT proposal, it =
was implied that precomputed vaults must use ephemeral keys that must be de=
leted as part of the vaulting protocol,=C2=A0like <a href=3D"https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html">Bryan Bi=
shop&#39;s proposal</a>. Looking around, I haven&#39;t been able to find an=
y wallet vault proposal that doesn&#39;t require ephemeral keys, so at the =
risk of posting 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><div>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 spe=
nt immediately if you use all the keys, just like a normal N-of-N multisig =
address (since that&#39;s what it is at its core), but the usage of any of =
the pre-signed transactions=C2=A0leads to an address that guarantees a claw=
back within a time window. Here&#39;s a 3-of-3 example:</div><div><div><br>=
</div><div><b>Vault Initialization</b>:</div><div><div>1. Create 3 of 3 Vau=
lt Address<br>2. Create an Interim Address that can send with:<br>=C2=A0* 1=
 of 3 keys after a timelock of 1 month<br>=C2=A0* 2 of 3 keys after a timel=
ock of 1 week<br>=C2=A0* 3 of 3 keys with no timelock</div><div><br></div><=
div><div><div><b>Vaulting</b>:</div></div></div><div>1. Create a transactio=
n sending an output to the Vault Address<br></div><div>2. Create a=C2=A0tra=
nsaction spending that Vault=C2=A0Address output to the Interim Address<br>=
3. Presign=C2=A0one copy of the step-2 transaction for each of the three co=
mbinations of two keys.<br>4. Store seeds separately, store the wallet conf=
ig as well as the three presigned transactions with each seed.=C2=A0<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 appropriate timelock for =
the number of keys you want to sign with.<br>4. Create a transaction sendin=
g from the Interim Address.<br>5. Broadcast</div><br><b>Recovering </b>(aft=
er unvaulting step 2 after the broadcasted transaction to the Interim Addre=
ss has been mined):<br>1. Sign the utxo with all three keys to any destinat=
ion. Alternatively sign with two keys, wait 1 week.<br>2. Broadcast it<div>=
<br></div></div></div><div>This has the usual downsides of pre-signed vault=
s that you need to backup these transactions for each vaulting, complicatio=
ns involving the flexibility (or lack thereof) of fees,=C2=A0and inflexibil=
ity 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 fl=
exible (anchor outputs, multiple versions of the presigned transactions wit=
h different fees, etc). More complicated presigning schemes could allow for=
 some flexibility in unvaulting amount=C2=A0(eg by sending change back into=
 the vault, and creating additional pre-signed transactions for that new ou=
tput).</div><div><br></div><div>It also has the same downside that OP_CTV v=
aults 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 pa=
ssed. Note that James&#39; OP_VAULT opcode wouldn&#39;t have this 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.=C2=A0</div=
><div><br></div><div>Anyways sorry if this was already on people&#39;s rada=
r and just too obvious to post about.=C2=A0</div><div><br></div><div><br></=
div></div>

--0000000000007dd28905f2f1e3c6--