From: "David A. Harding" <dave@dtrt•org>
To: Joost Jager <joost.jager@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Date: Sat, 10 Jun 2023 12:09:57 -1000 [thread overview]
Message-ID: <fe630ee713829e1ce2df33a8438cbcf5@dtrt.org> (raw)
In-Reply-To: <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
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
next prev parent reply other threads:[~2023-06-10 22:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 15:00 Joost Jager
2023-06-03 1:08 ` David A. Harding
2023-06-03 1:14 ` Greg Sanders
2023-06-03 9:14 ` Joost Jager
2023-06-03 15:50 ` Peter Todd
2023-06-15 9:36 ` Joost Jager
2023-06-15 10:39 ` Greg Sanders
2023-06-16 11:26 ` Joost Jager
2023-06-16 13:30 ` Greg Sanders
2023-06-18 20:32 ` Antoine Riard
2023-06-18 20:40 ` Greg Sanders
2023-06-19 1:14 ` Antoine Riard
2023-06-20 12:50 ` Joost Jager
2023-06-03 7:49 ` Joost Jager
2023-06-03 8:06 ` Joost Jager
2023-06-03 12:05 ` Greg Sanders
2023-06-03 12:35 ` Joost Jager
2023-06-03 12:43 ` Greg Sanders
2023-06-03 12:55 ` Joost Jager
2023-06-08 9:16 ` Joost Jager
2023-06-10 0:23 ` Antoine Riard
2023-06-10 7:43 ` Joost Jager
2023-06-10 22:09 ` David A. Harding [this message]
2023-06-11 19:25 ` Joost Jager
2023-06-12 3:16 ` Antoine Riard
2023-06-13 8:51 ` David A. Harding
2023-06-13 10:38 ` Joost Jager
2023-06-12 13:03 ` Greg Sanders
2023-06-20 12:30 ` Joost Jager
2023-07-04 20:18 ` Antoine Riard
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=fe630ee713829e1ce2df33a8438cbcf5@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=joost.jager@gmail$(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