Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-31 🗒️ Summary of this message: A proposal for ...
📅 Original date posted:2023-01-31
🗒️ Summary of this message: A proposal for a wallet vault without requiring key deletion involves creating an N-of-N multisig address and pre-signing transactions with N-1 keys to an address with timelocked spend paths.
📝 Original message: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 at 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 at 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/3f850526/attachment.html>;
🗒️ Summary of this message: A proposal for a wallet vault without requiring key deletion involves creating an N-of-N multisig address and pre-signing transactions with N-1 keys to an address with timelocked spend paths.
📝 Original message: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 at 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 at 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/3f850526/attachment.html>;