From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A82C1C0171 for ; Mon, 10 Feb 2020 06:27:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id A21EF20104 for ; Mon, 10 Feb 2020 06:27:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obMYzjZlj5eO for ; Mon, 10 Feb 2020 06:27:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by silver.osuosl.org (Postfix) with ESMTPS id 5DAD32001A for ; Mon, 10 Feb 2020 06:27:33 +0000 (UTC) Date: Mon, 10 Feb 2020 06:27:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1581316050; bh=t8khOVJ6mqPpXFbpSF5UyuJp7XkICQiauuwKc2Hid28=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=x8NW8pXFHqYECq0DOnC0ohpn3BCdBpyAkFGklUhgjQFYoMuGPMl5OTPQXa62pWGhb xmyDq/60Odf/2XqYUDiC41kaDQVz2uWibnCZPiswActiVxx5EoqnTuarLVelG4rUli V4+QAa5XaIt++gOxzr7ptq9O2CN+45N14m8VQ+r4= To: Bryan Bishop , Bitcoin Protocol Discussion 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 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: Mon, 10 Feb 2020 06:27:35 -0000 Good morning The Group, There are already many excellent arguments presented for Taproot, let me pr= esent a related one. Notice your example MAST: > > =C2=A0 =C2=A0 =C2=A0 /\ > =C2=A0 =C2=A0 =C2=A0/=C2=A0 \ > =C2=A0 =C2=A0 /=C2=A0 =C2=A0 \ > =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 \ > =C2=A0 /\=C2=A0 =C2=A0 =C2=A0 /\ > =C2=A0/=C2=A0 \=C2=A0 =C2=A0 /=C2=A0 \ > /\=C2=A0 /\=C2=A0 /\=C2=A0 /\ > a b c d e f g h Of particular note is that the MAST has a predetermined set of scripts, `a`= to `h`. Now, practically speaking, each of these scripts `a`..`h` will be claimable= by one or a number of known, pre-determined participants as well. Scripts that do not have a pre-determined set of participants exist (e.g. a= simple `OP_HASH160 OP_EQUAL` without any `OP_CHECKSIG` operations) = but are generally not expected to actually be *useful* for a majority of us= e-cases (the above hash-only example could be double-spent by a majority mi= ner, for example). We expect a vast majority of scripts that will be in use will have a pre-de= termined fixed finitely-enumerable set of participants (so that miners cann= ot steal coins once the "solution" to the script puzzle is published in mem= pools), represented by pubkeys that are fed into `OP_CHECKSIG` operations i= n the script. Since each script has (with high probability approaching 1.0) a pre-determi= ned fixed finitely-enumerable set of participants within that script, and t= he entire MAST itself has a pre-determined fixed finitely-enumerable set of= scripts, we can take the union of all sets of participants of all the scri= pts in the MAST. Then we put the union of those sets as the signatories of a single Schnorr = n-of-n multisignature, to be used as the Taproot keypath branch. The advantage now is that with Taproot: * If you can induce all participants to sign a transaction using the keypat= h spend, then you gain privacy (no part of the MAST is ever published, not = even its root or the presence of the MAST!) *and* reduced onchain fees (bec= ause the MAST is not published and does not take up space on the blockchain= ). * You can incentivize cooperation (beyond just the incentive of improved = privacy) by letting participants recover some of the saved onchain fees. Lightning does this, for example: the funder of the channel is the one = paying for the closing fees, and the closing fee of the mutual close is alm= ost always lower than the unilateral close case (or else is equal: the clos= ing ritual has the unilateral close fee as the upper bound on whatever fee = can be proposed at the mutual close ritual). * Even if a participant does not cooperate (for example, it might have been= hit by a rogue asteroid in the meantime) we still have the fallback of rev= ealing the entire MAST. (Just to be clear: I do not *currently* own any datacenters at locations th= at are likely to be hit by rogue asteroids.) >From this, we can generally conclude that the Taproot assumption --- that t= here exists some finitely enumerable set of participants we can derive from= the scripts needed to enforce a contract --- holds, at a probability near = ~1.0, for almost all complicated contracts and protocols we would find usef= ul. Such contracts and protocols can then be Taproot-ized in order to gain some= privacy and transaction size benefits. Other optimizations, such as selecting k of the n participants as "key part= icipants" who are the most likely to be online and interested in the conclu= sion of the contract, can then be used to reduce the n-of-n to k-of-n, but = the basic Taproot "there exists some n-of-n" assumption still holds and thi= s is just an optimization on top of that. Regards, ZmnSCPxj