MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
 <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
 <fe630ee713829e1ce2df33a8438cbcf5@dtrt.org>
In-Reply-To: <fe630ee713829e1ce2df33a8438cbcf5@dtrt.org>
From: Joost Jager <joost.jager@gmail.com>
Date: Sun, 11 Jun 2023 21:25:42 +0200
Message-ID: <CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000008c84c205fddf9319"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

--0000000000008c84c205fddf9319
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dave,

On Sun, Jun 11, 2023 at 12:10=E2=80=AFAM David A. Harding <dave@dtrt.org> w=
rote:

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

Isn't it the case that that op-dropped partial signature for the ephemeral
key isn't committed to and thus can be modified by anyone before it is
mined, effectively deleting the keys to the vault? If not, this would be a
great alternative!

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

I appreciate the suggestion, but I am really looking for a bitcoin-native
solution to leverage bitcoin's robustness and security properties.

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.


That years-long timeline that you sketch for witness replacement (or any
other policy change I presume?) to become effective is perhaps indicative
of the need to have an alternative way to relay transactions to miners
besides the p2p network?

I agree though that it would be ideal if there is a good solution that
doesn't require any protocol changes or upgrade path.

Joost

--0000000000008c84c205fddf9319
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Dave,</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, Jun 11, 2023 at 12:10=E2=80=AFAM Davi=
d A. Harding &lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; wro=
te:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">3. When paying t=
he script in #2, Alice chooses the scriptpath spend from<br>
=C2=A0 =C2=A0 #1 and pushes a serialized partial signature for the ephemera=
l key<br>
=C2=A0 =C2=A0 from #2 onto the stack, where it&#39;s immediately dropped by=
 the<br>
=C2=A0 =C2=A0 interpreter (but is permanently stored on the block chain).=
=C2=A0 She also<br>
=C2=A0 =C2=A0 attaches a regular signature for the OP_CHECKSIG opcode.<br><=
/blockquote><div><br></div><div>Isn&#39;t it the case that that op-dropped =
partial signature for the ephemeral key isn&#39;t committed to and thus can=
 be modified by anyone before it is mined, effectively deleting the keys to=
 the vault? If not, this would be a great alternative!</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Even better, I think you can achieve nearly the same safety without<br>
putting any data on the chain.=C2=A0 All you need is a widely used<br>
decentralized protocol that allows anyone who can prove ownership of a<br>
UTXO to store some data.=C2=A0=C2=A0<br></blockquote><div><br></div><div>I =
appreciate the suggestion, but I am really looking for a bitcoin-native sol=
ution to leverage bitcoin&#39;s robustness and security properties.</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">By compariso=
n, rolling<br>
out relay of the annex and witness replacement may take months of review<br=
>
and years for &gt;90% deployment among nodes, would allow an attacker to<br=
>
lower the feerate of coinjoin-style transactions by up to 4.99%, would<br>
allow an attacker to waste 8 million bytes of bandwidth per relay node<br>
for the same cost they&#39;d have to pay to today to waste 400 thousand<br>
bytes, and might limit the flexibility and efficiency of future<br>
consensus changes that want to use the annex.</blockquote><div><br></div><d=
iv>That years-long timeline that you sketch for witness replacement (or any=
 other policy change I presume?) to become effective is perhaps indicative =
of the need to have an alternative way to relay transactions to miners besi=
des the p2p network?</div><div><br></div><div>I agree though that it would =
be ideal if there is a good solution that doesn&#39;t require any protocol =
changes or upgrade path.</div><div><br></div><div>Joost</div></div></div>

--0000000000008c84c205fddf9319--