Date: Mon, 05 Feb 2018 04:27:07 -0500
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Precedence: list

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
>