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 8CC6BC6D for ; Wed, 8 May 2019 04:37:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C4EB1FB for ; Wed, 8 May 2019 04:37:42 +0000 (UTC) Date: Wed, 08 May 2019 04:37:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1557290259; bh=WIb3iMAHnO3YQLT/XerHmBsuT+Efok/uT2B9b4xNJYE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=w1aFkfkvvMFE9QjptoJIcFGrLjxR/NBg+sjuBTOHHuX9noihnKxCq7+fWYZ+f9/uU xReyqPmlH/01yboQStn41R9UjJz1sTx8FFZsZKSS+Om+++8LF4lSY/I3WuSLNeIrmP YqYMXxPWUFwmLHSn2w2sKQzwpY5nqg3mFtrb+ebM= To: Sjors Provoost , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.com> In-Reply-To: <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl> References: <201905062017.11396.luke@dashjr.org> <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl> 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: Thu, 09 May 2019 14:49:07 +0000 Cc: Pieter Wuille Subject: Re: [bitcoin-dev] Taproot proposal 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: Wed, 08 May 2019 04:37:43 -0000 Good morning Sjors, Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, May 8, 2019 4:42 AM, Sjors Provoost via bitcoin-dev wrote: > Hey Pieter, > > I think this is a reasonable collection of changes that make sense in com= bination. Some initial feedback and questions. > > From the BIP: > > > If one or more of the spending conditions consist of just a single key = (after aggregation), > > he most likely one should be made the internal key. If no such conditio= n exists, it may > > be worthwhile adding one that consists of an aggregation of all keys pa= rticipating in all > > scripts combined; effectively adding an "everyone agrees" branch. If th= at is inacceptable, > > pick as internal key a point with unknown discrete logarithm (TODO). > > I assume Luke Dashjr referred to the above when saying: > > > Is there any way to use the Taproot construct here while retaining exte= rnal > > script limitations that the involved party(ies) cannot agree to overrid= e? > > For example, it is conceivable that one might wish to have an unconditi= onal > > CLTV enforced in all circumstances. > > One reason why someone would want to avoid a "everone agrees" branch, is = duress (or self-discipline, or limiting powers of a trustee). In particular= with respect to time-locks. > > Can this "unknown discrete logarithm" be made provably unknown, so all si= gners are assured of this property? Bonus points if the outside world can't= tell. The exact mechanism could be outside the scope of the BIP, but knowi= ng that it's possible is useful. As I understand it, it is possible to take some random data, hash it with S= HA256 and acquire a 256-bit number. Then treat that number as an X coordinate (or is it Y...), and see if there= exists a point on the secp256k1 curve at that coordinate. If not, try another random data, or just hash the same number again. As I understand it, about half the possible X coordinates will have a point= on the curve. I believe this is the "hash to a point" technique. The scalar behind the above point cannot be known, unless either the hash f= unction is broken, or ECDLP is broken. (perhaps a better cryptographer can give the proper qualifications, any cor= rections, and etc etc) As the point is just an arbitrary point on the curve, it is unknown to the = rest of the world whether somebody knows the scalar, or nobody knows. > > Perhaps Lightning devs have an opinion on "everyone agrees" with respect = to hash pre-images. I suspect there is no benefit in guaranteeing that a pr= e-image must be revealed or a timeout must be waited for and there's no way= around that condition. The "everyone agrees" branch in Lightning is basically the "cooperative clo= se" of the channel. So it is not likely we will need an "everyone agrees" branch in the actual = HTLCs we transfer *within* the channel. So if we need to use hashes still, we will likely use the "hash to a point"= technique above. Or just use pubkeys given by both participants, that should be enough to en= sure the "everyone agrees" branch is never taken if we write our software s= uch that we never agree to sign with it (i.e. just get points from both sid= es and MuSig them; then each side can just erase the scalar generating it f= rom memory and whatever caches exist on the system; a node might even just = generate a single random point from a scalar it subsequently erases, and ju= st use some non-hardened derivation path from that for every HTLC it has to= make). This technique is "sufficiently provably unknown" since each participant kn= ows that it deliberately erased the only means of knowing the complete disc= rete log by erasing its share. In short, "everyone agrees" is trivially easy to make "nobody can agree" by= a single participant never agreeing to let itself be ripped off. Do note that it is likely Lightning will eventually switch to using payment= points/scalars instead of hashes/preimages. This will allow us to have path decorrelation, both within a route, and in = multiple routes of the same payment. This is enabled by Schnorr, as this requires Scriptless Script. (granted 2p-ECDSA also enables Scriptless Script, but we decided to wait fo= r Schnorr to hit base layer instead) This means we would be using the "everyone agrees" path only, with everyone= agreeing to first create a `nLockTime` backout tx, then everyone agreeing = to create a transaction where one side has knowledge of a secret scalar tha= t is learned by the other side upon completion of the signature. Regards, ZmnSCPxj