From: Billy Tetrud <billy.tetrud@gmail•com>
To: darosior <darosior@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys
Date: Tue, 31 Jan 2023 09:02:51 -0600 [thread overview]
Message-ID: <CAGpPWDaaBKbc_evP94xHS9h_pJogPre0YiE1+Pe27WV4dn6MHA@mail.gmail.com> (raw)
In-Reply-To: <rs4K-Lg4t58J2gfeXUPHK0CuctCn_sq6IlyZ7wobDR_cCCAkd_3JrRM4LVCrhxhd3PE4fnVveTEc0sYDmS9fqpIEUPFikC5PDUOlC9D_mhU=@protonmail.com>
[-- 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 --]
prev parent reply other threads:[~2023-01-31 15:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 17:39 Billy Tetrud
2023-01-26 14:30 ` darosior
2023-01-31 15:02 ` Billy Tetrud [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGpPWDaaBKbc_evP94xHS9h_pJogPre0YiE1+Pe27WV4dn6MHA@mail.gmail.com \
--to=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox