From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D3599C0171 for ; 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 ; 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 ; 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 ; Sun, 9 Feb 2020 22:32:53 +0000 (UTC) Received: by mail-pg1-f181.google.com with SMTP id u131so2842841pgc.10 for ; 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: <2d9970d8-209d-7223-6564-ad858dce5981@mattcorallo.com> In-Reply-To: <2d9970d8-209d-7223-6564-ad858dce5981@mattcorallo.com> From: Antoine Riard Date: Sun, 9 Feb 2020 17:32:41 -0500 Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> In particular, you care more about pr= ivacy 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 transactio= n is
> larger than usual).

Not sure this point holds, in= dependently of which Taproot/MASTmechanism deployed,
any time-sens= itive transaction will likely leak its "contestness" by the setti= ng of its
nSequence/nLocktime fields. E.g, for LN, justice t= x are not encumbered by a CSV
delay which distinguish them fr= om a non-revoked spend. And when you're relaying
htlcs an= d need to close unilaterally channel to prevent different settlement on
incoming/outgoing links the HTLC-timeout tx broadcast have a nL= ocktime set.

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

Antoine








Le=C2=A0dim. 9 f=C3=A9vr. 2020 =C3=A0=C2=A015:40, Matt Cora= llo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
=
Responding purely t= o 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?=C2= =A0 The BIP
> only goes as far as to claim that the advantage is apparent if the out= puts
> *could be spent* as an N of N, but doesn't make representations ab= out
> how likely
> that N of N case would be in practice compared to the script paths. Pe= rhaps
> among use cases, more than half of the ones we expect people to be doi= ng
> 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 maki= ng
> 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/mail= man/listinfo/bitcoin-dev
--00000000000019dd2a059e2c3494--