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 6C5FBCC6 for ; Wed, 8 May 2019 05:16:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7211C1FB for ; Wed, 8 May 2019 05:16:08 +0000 (UTC) Date: Wed, 08 May 2019 05:16:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1557292566; bh=nYZy1oS1htT1Ez21rkhdJmm9sAkRCCz8521HAdA/OYc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=n69PJaNsJGkaFYqT9/RSs5H9oltM/B4LhdvPSUxjwZnFCrLZr/Ga4jlVDyW6NxIGM gWqHqTizFav2JlU79l618ek6oBThiXWwo8cA9NB1roXQ3kzpmTcB4vkxA2SzWWd0ox ih/j0bABQ/+zJsurf3MNcTp9hwDWSFm/5EvGD4tY= To: Sjors Provoost , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.com> References: <201905062017.11396.luke@dashjr.org> <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl> <2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.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: Thu, 09 May 2019 14:49:20 +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 05:16:09 -0000 Good morning Sjors, sorry everyone for the double-posting... > I believe this is the "hash to a point" technique. > > The scalar behind the above point cannot be known, unless either the hash= function is broken, or ECDLP is broken. > (perhaps a better cryptographer can give the proper qualifications, any c= orrections, and etc etc) > > As the point is just an arbitrary point on the curve, it is unknown to th= e rest of the world whether somebody knows the scalar, or nobody knows. Now that I think further, everyone can use *the same* point generated from = an arbitrary "hash to a point". For example, we can define the "script-only point" as the point whose X coo= rdinate (or is it Y...) is equal to SHA256("Pieter Wuille is really great!"= ). Add more "really " until we get a point on the curve. Provided everyone knows what the exact data to hash is, and the exact hash = function, the above procedure is sufficient for everybody to verify that Pi= eter Wuille (and anyone else for that matter) cannot, in fact, spend the co= in unilaterally, and that nobody can actually spend the coin, except via a = script. Since the point on the output is tweaked by the script merkle tree root, va= rying your pubkey for each use will be enough to blind the use of the "scri= pt-only point" until you have to reveal it during spending anyway. If you *absolutely* insist on reusing your pubkeys, then adding a `OP_PUSH(= ) OP_DROP` to at least one script, with a random salt, should be enou= gh to blind the use of the script-only point until you have to reveal the s= cript you want to use. Or even just further tweak the point before using it as the taproot interna= l pubkey, so that not even a coin spend reveals that the "everyone agrees" = branch was never actually an option. > Or just use pubkeys given by both participants, that should be enough to = ensure the "everyone agrees" branch is never taken if we write our software= such that we never agree to sign with it (i.e. just get points from both s= ides and MuSig them; then each side can just erase the scalar generating it= from memory and whatever caches exist on the system; a node might even jus= t generate a single random point from a scalar it subsequently erases, and = just use some non-hardened derivation path from that for every HTLC it has = to make). > This technique is "sufficiently provably unknown" since each participant = knows that it deliberately erased the only means of knowing the complete di= screte 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. > The "taproot assumption" is that there exists some finite set of participan= ts that is interested in how the coin will be spent. Under the taproot assumption then, any "truster" that assigns time-limited = control of a coin to a "trustee" is part of that finite set interested in t= he coin spend conditions. So the truster should in fact be asked for a pubkey to be added in the tapr= oot internal pubkey that enables the "everyone agrees" branch. Then the truster can simply generate a point without knowing its private ke= y, or by forgetting this private key. If one is sufficiently schizophrenic, one can split oneself into a "truster= " and "trustee" as above and deliberately forget the truster private key. Then one is sufficiently unable to spend under duress by deleting the "trus= ter" sub-agent and providing real-world access to the "trustee" sub-agent t= hat can only spend under specific SCRIPT-defined conditions. (the above paragraph should not be taken to mean that I am an agent-based A= I) That is, it should be enough for everyone to agree to lock the "everyone ag= rees" branch and throw away their own key, to keep that branch locked. Regards, ZmnSCPxj