path: root/a7/2d81b27a623beae387834535722f7387e8de65

Return-Path: <antoine.riard@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D3599C0171
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 22:32:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id C7A70849DF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 22:32:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bvibwFjgBBJJ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 22:32:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com
 [209.85.215.181])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id EDF9284826
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 22:32:53 +0000 (UTC)
Received: by mail-pg1-f181.google.com with SMTP id u131so2842841pgc.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 09 Feb 2020 14:32:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=2vVhNFZ6fZoBDeONtRSp1YOau1qRRfHj++LbwrpUODU=;
 b=plAqEfJyQBEag71tyfPgVrpiAeUpZ4k4Z5/8J+pA5z3Vhpx/ycYpopUo+h2fSux3me
 ZXNgUxtbw8/94a8UwOF7AdAoYz4y3LMT0nk66VKpWdRy0Ubv2UzRPu+BD4YWOt0Ub7Pt
 dD1vpElhvw1D7mOkRcViCB8V5j2yhdhE668Ro1bL4z/mmAagNWpQfNHTzTHabXjgsXzo
 wPWirhzkpxbyXKsaQsO+B+4OxtmqGg/lP5bxQxQ+Dc+epbkMxLdL2T2tgMOcF7+p1NuE
 ed4HWsqP/iJFcgepZQvdXIl57fGySVIM/C0B8NkHTrqzrHYtRL3v/k2MGtIJyip0CXh7
 HZEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=2vVhNFZ6fZoBDeONtRSp1YOau1qRRfHj++LbwrpUODU=;
 b=DeAwDC9qtYMqwf1ljSc7qx2FqwOC/reuBsR69HYUDd+lpXArgGuJiC44TlWvi41uzt
 sRn149/ye5eyiQgz611H/fxKqlZQHl722TaY+M8hfGoCiIG+d/Ae0SI1Rj5aGlozar2t
 AjBv84u4F/IZ8hq2WJwEUn60Rntqo94Jj5dA5KU5OkyuKg2UHyby1JZLWwHr11qxx/Ma
 CQ8MiXlJN6jd68gdqyrUcfgWLjahHr9/osbgbP4nTmC3oOQ77NwrhkY3xZ0ACMxYfjNH
 28xZMbBo2WtCR/tTXQrXKJvzxc7v3afhLEWfhqPCHkVJOPpi13I3/GaAq51kqiOdg/Vp
 esyQ==
X-Gm-Message-State: APjAAAXYrJ9YoifegGfgKMdKpb/zqxNYfRhymhqGX+YVjOIhJVdqyzXk
 +2icXq5dyDT9QiBD5Bd3aaX/8ZtPONRiUYWO+rGDCPWJa0k=
X-Google-Smtp-Source: APXvYqxbdwBxZ7xDg42LLK85EqLWsfRO64NR4BioM/Z7E61RosOE/WHzpitOfnJMPs8QDQkI+/W/7llzNoNTIXUt744=
X-Received: by 2002:a63:ec0c:: with SMTP id j12mr3094328pgh.78.1581287573411; 
 Sun, 09 Feb 2020 14:32:53 -0800 (PST)
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"
X-Mailman-Approved-At: Sun, 09 Feb 2020 22:36:35 +0000
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Feb 2020 22:32:55 -0000

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