On 2023-06-09 21:43, Joost Jager via bitcoin-dev wrote:
The most critical application in this category, for me, involves time-locked vaults. [...] Backing up the ephemeral signatures of the pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be 'opened'. However, without the annex, this is not as safe as it could be. Due to the described circular reference problem, the vault creation and signature backup can't be executed in one atomic operation.
Hi Joost, For the purpose of experimenting with vaults, I don't think you need the most efficient construction---instead, anything that works without too much overhead is probably ok. In that case, I don't think you need the annex at all: 1. Alice can receive new payments to tr(<key>, raw(OP_DROP <key> OP_CHECKSIG)) 2. Later, Alice creates tr(MuSig2(<key-from-HD-wallet>, <ephemeral-key>)) 3. When paying the script in #2, Alice chooses the scriptpath spend from #1 and pushes a serialized partial signature for the ephemeral key from #2 onto the stack, where it's immediately dropped by the interpreter (but is permanently stored on the block chain). She also attaches a regular signature for the OP_CHECKSIG opcode. Alternatively, if Alice decides she doesn't want to pay into a vault, she uses the keypath spend from #1 with no loss in efficiency. The scriptpath solution requires some extra preparation on Alice's part and costs about a dozen vbytes extra over using the annex, which feels acceptable to me to avoid the problems identified with using the annex. Even better, I think you can achieve nearly the same safety without putting any data on the chain. All you need is a widely used decentralized protocol that allows anyone who can prove ownership of a UTXO to store some data. You can think of LN gossip as being a version of this: anyone who proves ownership of a P2WSH 2-of-2 script is allowed to store data in a certain format on every LN routing node. Rusty Russell's v2 gossip proposal makes this a bit more generic, but I think you could make it even more generic by creating a simple server that stores and forwards a single BIP322 signed message up to size x for any entry in the current UTXO set, with periodic replacement of the signed message allowed. The signed data could be LN routing information or it could be arbitrary data like a signature from an ephemeral key (or it could even be a JPEG or other data irrelevant to processing payments). Any full node (including pruned and utreexo nodes) can trustlessly provide UTXO lookup for such a server and a decentralized network of such servers could be useful by a large number of protocols, encouraging hundreds or thousands of servers to be operated---providing similar data availability guarantees to committing data on the block chain, but without the permanent footprint (i.e., once a UTXO is spent, the associated data can be deleted). Many vault designs already effectively require watchtowers, so it'd be easy to make this simple server part of the watchtower.
Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witness would provide a viable solution? [...] [3] https://github.com/bitcoin/bitcoin/pull/24007
The two solutions identified above (OP_DROP and decentralized storage for UTXO owners) can be implemented immediately. By comparison, rolling out relay of the annex and witness replacement may take months of review and years for >90% deployment among nodes, would allow an attacker to lower the feerate of coinjoin-style transactions by up to 4.99%, would allow an attacker to waste 8 million bytes of bandwidth per relay node for the same cost they'd have to pay to today to waste 400 thousand bytes, and might limit the flexibility and efficiency of future consensus changes that want to use the annex. -Dave _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
