path: root/38/e102880a03cef4c52471ee7d93b640ce5af0e1

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8FEDFEB5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Feb 2018 09:27:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D2971C0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Feb 2018 09:27:24 +0000 (UTC)
Date: Mon, 05 Feb 2018 04:27:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1517822840;
	bh=tpUx5nCPB7azknwZpTsJDeNR/YzCS5W/m3Lywb1EZko=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=cDQ8qgDPwoRqsMs7OAppcAVCLsjrNnkDt6MnLek7fiCFGctGRlVHh5x7T3MOjLm+G
	tyJ/+irsqNcLx0x9af+xOWPrPeaEEzWO32rFbjY1u65JrdkTWLXW3LGLVieAogB9RK
	UpWNj/JaRjS694fHlldb0ODi94XtW2fpDZRqK1xU=
To: Gregory Maxwell <greg@xiph.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <jKjJiEEqiQR5nbVIELmjrW61_8bXmGjMyHpHzB71aJbKdmuH8lShBiG4iTmQqVJA9jflYCNNt1Yj7HWQtgLMEed1dTWtojxm5BQG9qH2iQ4=@protonmail.com>
In-Reply-To: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 07 Feb 2018 04:46:27 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Mon, 05 Feb 2018 09:27:26 -0000

Good morning Greg,

I am probably being exceedingly naive, but I would like to compare Taproot =
to a generalization of funding transactions.

For instance, CoinSwapCS:

1.  It uses an HTLC in an off-chain transaction, and a funding transaction =
TX0 whose output is a "simple" 2-of-2.
2.  The HTLC tx spends this 2-of-2.
3.  If a branch of the HTLC succeeds, the parties contact each other and cr=
eate a replacement of the (unconfirmed and unbroadcasted but signed) HTLC t=
x that assigns the funds to the correct owners.
4.  If the above step fails, individual parties can in isolation publish th=
e HTLC tx and provide its requirements.

Both of #3 and #4 above, appear to me naively as similar to the two "top" c=
ases of Taproot, i.e. either C is signed by all parties, or S is revealed a=
nd fulfilled.

The important bits of this "generalized funding transaction" pattern is:

1. The contract that enforces correct behavior spends an unsigned and unbro=
adcasted funding transaction output (which requires N-of-N).
2. The enforcement contract is signed first by all parties before the fundi=
ng transaction is signed by anybody.  This is possible due to SegWit.
3.  Then, when all parties are sure they have the fully-signed smart contra=
ct, the initial funding transaction is signed and broadcast and confirmed.
4.  When the condition that the contract requires is achieved, then the par=
ties contact each other and try to jointly create a simpler transaction tha=
t spends the funding transaction directly to whoever gets the money in the =
correct proportion.  This avoids publishing the smart contract onchain, and=
 looks like an ordinary N-of-N spend.
5.  If they fail to get all required signatures for any reason, any party c=
an publish the enforcement contract transaction and subsequently fulfill it=
s conditions in another transaction.

Admittedly, Taproot if added to the consensus would reduce the number of tr=
ansactions by 1 in the "S is revealed" case.
But the "generalized funding transaction" pattern is already possible today=
, and MuSig (to my limited understanding) can be used to make it indistingu=
ishable from 1-of-1 (so, possibly, make it P2WPKH?).


(I am probably neglecting something very simple and direct, however...)

Regards,
ZmnSCPxj

-------- Original Message --------
 On January 23, 2018 8:30 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:

>Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
> areas: efficiency and privacy. Efficiency because unexecuted forks of
> a script can avoid ever hitting the chain, and privacy because hiding
> unexecuted code leaves scripts indistinguishable to the extent that
> their only differences are in the unexecuted parts.
>
> As Mark Friedenbach and others have pointed out before it is almost
> always the case that interesting scripts have a logical top level
> branch which allows satisfaction of the contract with nothing other
> than a signature by all parties.  Other branches would only be used
> where some participant is failing to cooperate. More strongly stated,
> I believe that any contract with a fixed finite participant set
> upfront can be and should be represented as an OR between an N-of-N
> and whatever more complex contract you might want to represent.
>
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments. Otherwise, if the
> anonymity set of fancy usage is only other fancy usage it may not be
> very large in practice. One suggestion has been that ordinary
> checksig-only scripts should include a dummy branch for the rest of
> the tree (e.g. a random value hash), making it look like there are
> potentially alternative rules when there aren't really.  The negative
> side of this is an additional 32-byte overhead for the overwhelmingly
> common case which doesn't need it.  I think the privacy gains are
> worth doing such a thing, but different people reason differently
> about these trade-offs.
>
> It turns out, however, that there is no need to make a trade-off.  The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.
>
> Let's say we want to create a coin that can be redeemed by either
> Alice && Bob   or by CSV-timelock && Bob.
>
> Alice has public A, Bob has pubkey B.
>
> We compute the 2-of-2 aggregate key C =3D A + B.  (Simplified; to
> protect against rogue key attacks you may want to use the MuSig key
> aggregation function [1])
>
> We form our timelock script S =3D  "<timeout> OP_CSV OP_DROP B OP_CHECKSI=
GVERIFY"
>
> Now we tweak C to produce P which is the key we'll publish: P =3D C + H(C=
||S)G.
>
> (This is the attack hardened pay-to-contract construction described in [2=
])
>
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P=
].
>
> Now Alice and Bob-- assuming they are both online and agree about the
> resolution of their contract-- can jointly form a 2 of 2 signature for
> P, and spend as if it were a payment to a single party (one of them
> just needs to add H(C||S) to their private key).
>
> Alternatively, the Taproot consensus rules would allow this script to
> be satisfied by someone who provides the network with C (the original
> combined pubkey), S, and does whatever S requires-- e.g. passes the
> CSV check and provides Bob's signature. With this information the
> network can verify that C + H(C||S) =3D=3D P.
>
> So in the all-sign case there is zero overhead; and no one can tell
> that the contract alternative exists. In the alternative redemption
> branch the only overhead is revealing the original combined pubkey
> and, of course, the existence of the contract is made public.
>
> This composes just fine with whatever other merkelized script system
> we might care to use, as the S can be whatever kind of data we want,
> including the root of some tree.
>
> My example shows 2-of-2 but it works the same for any number of
> participants (and with setup interaction any threshold of
> participants, so long as you don't mind an inability to tell which
> members signed off).
>
> The verification computational complexity of signature path is
> obviously the same as any other plain signature (since its
> indistinguishable). Verification of the branch redemption requires a
> hash and a multiplication with a constant point which is strictly more
> efficient than a signature verification and could be efficiently fused
> into batch signature validation.
>
> The nearest competitor to this idea that I can come up with would
> supporting a simple delegation where the output can be spent by the
> named key, or a spending transaction could provide a script along with
> a signature of that script by the named key, delegating control to the
> signed script. Before paying into that escrow Alice/Bob would
> construct this signature. This idea is equally efficient in the common
> case, but larger and slower to verify in the alternative spend case.
> Setting up the signature requires additional interaction between
> participants and the resulting signature must be durably stored and
> couldn't just be recomputed using single-party information.
>
> I believe this construction will allow the largest possible anonymity
> set for fixed party smart contracts by making them look like the
> simplest possible payments. It accomplishes this without any overhead
> in the common case, invoking any sketchy or impractical techniques,
> requiring extra rounds of interaction between contract participants,
> and without requiring the durable storage of other data.
>
>
> [1] https://eprint.iacr.org/2018/068
> [2] https://blockstream.com/sidechains.pdf Appendix A
>
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>