David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-10 🗒️ Summary of this message: A proposal has ...

📅 Original date posted:2023-06-10
🗒️ Summary of this message: A proposal has been made to improve the safety of time-locked vaults by using a scriptpath solution that avoids the circular reference problem. Additionally, a decentralized protocol could be used to store data without putting it on the blockchain.
📝 Original message:
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