Date: Wed, 08 May 2019 05:16:03 +0000
To: Sjors Provoost <sjors@sprovoost.nl>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <woFxDfVHc0Od_GjeuU7FXoYnIQLk-xBx3z68nryT6PQhBNKYRh3pdV3OEiw4vFKe2TGbbOmdDmxUAC4g80vfx3KRadk5_N0t3pSdS07cnPY=@protonmail.com>
In-Reply-To: <2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.com>
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
	<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
Cc: Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Taproot proposal
Precedence: list

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(=
<salt>) 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