* [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys
@ 2023-01-23 17:39 Billy Tetrud
2023-01-26 14:30 ` darosior
0 siblings, 1 reply; 3+ messages in thread
From: Billy Tetrud @ 2023-01-23 17:39 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3631 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys
2023-01-23 17:39 [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys Billy Tetrud
@ 2023-01-26 14:30 ` darosior
2023-01-31 15:02 ` Billy Tetrud
0 siblings, 1 reply; 3+ messages in thread
From: darosior @ 2023-01-26 14:30 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4470 bytes --]
Hello Billy,
Yes it's basically a (simple) instantiation of Revault. You can find more at [https://github.com/revault](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 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 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 required 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 obviously *very* suboptimal.
Both issues are solvable with covenants.
Antoine Poinsot
------- Original Message -------
Le lundi 23 janvier 2023 à 6:39 PM, Billy Tetrud via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> a écrit :
> 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.
[-- Attachment #2: Type: text/html, Size: 5945 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys
2023-01-26 14:30 ` darosior
@ 2023-01-31 15:02 ` Billy Tetrud
0 siblings, 0 replies; 3+ messages in thread
From: Billy Tetrud @ 2023-01-31 15:02 UTC (permalink / raw)
To: darosior; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4864 bytes --]
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 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 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 required
> 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 obviously
> *very* suboptimal.
>
>
> Both issues are solvable with covenants.
>
> Antoine Poinsot
> ------- Original Message -------
> Le lundi 23 janvier 2023 à 6:39 PM, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> a écrit :
>
> 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.
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 6402 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-01-31 15:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-23 17:39 [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys Billy Tetrud
2023-01-26 14:30 ` darosior
2023-01-31 15:02 ` Billy Tetrud
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox