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