From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8FEDFEB5 for ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 " 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 >