MIME-Version: 1.0
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
 <2d9970d8-209d-7223-6564-ad858dce5981@mattcorallo.com>
In-Reply-To: <2d9970d8-209d-7223-6564-ad858dce5981@mattcorallo.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 9 Feb 2020 17:32:41 -0500
Message-ID: <CALZpt+HRuxNxKsdwtyMD=+hE-Tq+8Wt9mLVP0vj9Z+yENg_UJg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000019dd2a059e2c3494"
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity
Precedence: list

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

 > In particular, you care more about privacy when you are contesting a
> close of a channel or other script path because then the miners could be
more
> likely to extract a rent from you as "ransom" for properly closing your
channel
> (or in other words, in a contested close the value of the closing
transaction is
> larger than usual).

Not sure this point holds, independently of which Taproot/MASTmechanism
deployed,
any time-sensitive transaction will likely leak its "contestness" by the
setting of its
nSequence/nLocktime fields. E.g, for LN, justice tx are not encumbered by a
CSV
delay which distinguish them from a non-revoked spend. And when you're
relaying
htlcs and need to close unilaterally channel to prevent different
settlement on
incoming/outgoing links the HTLC-timeout tx broadcast have a nLocktime set.

Beyond LN, timelocks are a privacy leak and miner-withholding vector for an=
y
offchain protocols but this problem is not tied to Taproot design.
Confidential
enforcement of them would be great but that's another debate..

Antoine








Le dim. 9 f=C3=A9vr. 2020 =C3=A0 15:40, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Responding purely to one point as this may be sufficient to clear up
> lots of discussion:
>
> On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote:
> > Is Taproot just a probability assumption about the frequency and
> > likelihood of
> > the signature case over the script case? Is this a good assumption?  Th=
e
> BIP
> > only goes as far as to claim that the advantage is apparent if the
> outputs
> > *could be spent* as an N of N, but doesn't make representations about
> > how likely
> > that N of N case would be in practice compared to the script paths.
> Perhaps
> > among use cases, more than half of the ones we expect people to be doin=
g
> > could be
> > spent as an N of N. But how frequently would that path get used?
> > Further, while
> > the *use cases* might skew toward things with N of N opt-out, we might
> > end up in
> > a power law case where it's the one case that doesn't use an N of N opt
> > out at
> > all (or at a de minimis level) that becomes very popular, thereby makin=
g
> > Taproot
> > more costly then beneficial.
> Its not just about the frequency and likelihood, no. If there is a
> clearly-provided optimization for this common case in the protocol, then
> it becomes further more likely that developers put in the additional
> effort required to make this possibility a reality. This has a very
> significant positive impact on user privacy, especially those who wish
> to utilize more advanced functionality in Bitcoin. Further, yes, it is
> anticipated that the N of N case is possible to take in the vast
> majority of deployed use-cases for advanced scripting systems, ensuring
> that it is maximally efficient to do so (and thereby encouraging
> developers to do so) is a key goal in this work.
>
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div><div><div> &gt; In particular, you care more about pr=
ivacy when you are contesting a<br>&gt; close of a channel or other script =
path because then the miners could be more<br>&gt; likely to extract a rent=
 from you as &quot;ransom&quot; for properly closing your channel<br>&gt; (=
or in other words, in a contested close the value of the closing transactio=
n is<br>&gt; larger than usual).<br><br></div>Not sure this point holds, in=
dependently of which Taproot/MASTmechanism deployed,<br></div>any time-sens=
itive transaction will likely leak its &quot;contestness&quot; by the setti=
ng of its <br></div><div>nSequence/nLocktime fields. E.g, for LN, justice t=
x are not encumbered by a CSV<br></div><div>delay which distinguish them fr=
om a non-revoked spend. And when you&#39;re relaying<br></div><div>htlcs an=
d need to close unilaterally channel to prevent different settlement on <br=
></div><div>incoming/outgoing links the HTLC-timeout tx broadcast have a nL=
ocktime set.<br><br></div><div>Beyond LN, timelocks are a privacy leak and =
miner-withholding vector for any<br></div><div>offchain protocols but this =
problem is not tied to Taproot design. Confidential<br></div><div>enforceme=
nt of them would be great but that&#39;s another debate..<br><br></div><div=
>Antoine<br></div><div><br><br></div><div><br><br></div><div><br></div><div=
><br><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">Le=C2=A0dim. 9 f=C3=A9vr. 2020 =C3=A0=C2=A015:40, Matt Cora=
llo via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">Responding purely t=
o one point as this may be sufficient to clear up<br>
lots of discussion:<br>
<br>
On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote:<br>
&gt; Is Taproot just a probability assumption about the frequency and<br>
&gt; likelihood of<br>
&gt; the signature case over the script case? Is this a good assumption?=C2=
=A0 The BIP<br>
&gt; only goes as far as to claim that the advantage is apparent if the out=
puts<br>
&gt; *could be spent* as an N of N, but doesn&#39;t make representations ab=
out<br>
&gt; how likely<br>
&gt; that N of N case would be in practice compared to the script paths. Pe=
rhaps<br>
&gt; among use cases, more than half of the ones we expect people to be doi=
ng<br>
&gt; could be<br>
&gt; spent as an N of N. But how frequently would that path get used?<br>
&gt; Further, while<br>
&gt; the *use cases* might skew toward things with N of N opt-out, we might=
<br>
&gt; end up in<br>
&gt; a power law case where it&#39;s the one case that doesn&#39;t use an N=
 of N opt<br>
&gt; out at<br>
&gt; all (or at a de minimis level) that becomes very popular, thereby maki=
ng<br>
&gt; Taproot<br>
&gt; more costly then beneficial.<br>
Its not just about the frequency and likelihood, no. If there is a<br>
clearly-provided optimization for this common case in the protocol, then<br=
>
it becomes further more likely that developers put in the additional<br>
effort required to make this possibility a reality. This has a very<br>
significant positive impact on user privacy, especially those who wish<br>
to utilize more advanced functionality in Bitcoin. Further, yes, it is<br>
anticipated that the N of N case is possible to take in the vast<br>
majority of deployed use-cases for advanced scripting systems, ensuring<br>
that it is maximally efficient to do so (and thereby encouraging<br>
developers to do so) is a key goal in this work.<br>
<br>
Matt<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000019dd2a059e2c3494--