{"type":"rich","version":"1.0","title":"Billy Tetrud [ARCHIVE] wrote","author_name":"Billy Tetrud [ARCHIVE] (npub1xq…tcnns)","author_url":"https://yabu.me/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-01-23\n🗒️ Summary of this message: A simple way to create a wallet vault without requiring key deletion is to create an N-of-N multisig address and pre-sign transactions from it with N-1 keys.\n📝 Original message:In the discussion around James' OP_VAULT proposal, it was implied that\nprecomputed vaults must use ephemeral keys that must be deleted as part of\nthe vaulting protocol, like Bryan Bishop's proposal\n\u003chttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html\u003e.\nLooking around, I haven't been able to find any wallet vault proposal that\ndoesn't require ephemeral keys, so at the risk of posting something that's\nobvious to everyone, I wanted to share a simple way to do a wallet vault\nwithout requiring any key deletion.\n\nThe basic idea is to create an N-of-N multisig address, and pre-sign some\ntransactions from it with N-1 keys to an address with several timelocked\nspend paths. This has the fallback that funds can always be spent\nimmediately if you use all the keys, just like a normal N-of-N multisig\naddress (since that's what it is at its core), but the usage of any of the\npre-signed transactions leads to an address that guarantees a clawback\nwithin a time window. Here's a 3-of-3 example:\n\n*Vault Initialization*:\n1. Create 3 of 3 Vault Address\n2. Create an Interim Address that can send with:\n * 1 of 3 keys after a timelock of 1 month\n * 2 of 3 keys after a timelock of 1 week\n * 3 of 3 keys with no timelock\n\n*Vaulting*:\n1. Create a transaction sending an output to the Vault Address\n2. Create a transaction spending that Vault Address output to the Interim\nAddress\n3. Presign one copy of the step-2 transaction for each of the three\ncombinations of two keys.\n4. Store seeds separately, store the wallet config as well as the three\npresigned transactions with each seed.\n\n*Unvaulting*:\n1. Sign one of the pre-signed transactions with the missing signature.\n2. Broadcast\n3. Wait the appropriate timelock for the number of keys you want to sign\nwith.\n4. Create a transaction sending from the Interim Address.\n5. Broadcast\n\n*Recovering *(after unvaulting step 2 after the broadcasted transaction to\nthe Interim Address has been mined):\n1. Sign the utxo with all three keys to any destination. Alternatively sign\nwith two keys, wait 1 week.\n2. Broadcast it\n\nThis has the usual downsides of pre-signed vaults that you need to backup\nthese transactions for each vaulting, complications involving the\nflexibility (or lack thereof) of fees, and inflexibility in how much to\nunvault (must be the whole utxo, no change). This could of course be\naugmented with various techniques to make fee handling more flexible\n(anchor outputs, multiple versions of the presigned transactions with\ndifferent fees, etc). More complicated presigning schemes could allow for\nsome flexibility in unvaulting amount (eg by sending change back into the\nvault, and creating additional pre-signed transactions for that new output).\n\nIt also has the same downside that OP_CTV vaults have, where a stolen key\ncan steal funds from the interim address by racing the owner with their own\ntransaction once the necessary delay has passed. Note that James' OP_VAULT\nopcode wouldn't have this problem.\n\nBut not requiring any toxic waste keys seems like a pretty good benefit\nover Bryan Bishop's original proposal.\n\nAnyways sorry if this was already on people's radar and just too obvious to\npost about.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230123/eb519e3d/attachment.html\u003e"}