[bitcoin-dev] Taproot proposal

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed May 8 05:16:03 UTC 2019

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 corrections, 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.

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 coordinate (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 Pieter Wuille (and anyone else for that matter) cannot, in fact, spend the coin 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, varying your pubkey for each use will be enough to blind the use of the "script-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 enough to blind the use of the script-only point until you have to reveal the script you want to use.
Or even just further tweak the point before using it as the taproot internal 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 sides 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 just 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 discrete 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 participants 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 the coin spend conditions.
So the truster should in fact be asked for a pubkey to be added in the taproot internal pubkey that enables the "everyone agrees" branch.
Then the truster can simply generate a point without knowing its private key, 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 "truster" sub-agent and providing real-world access to the "trustee" sub-agent that can only spend under specific SCRIPT-defined conditions.

(the above paragraph should not be taken to mean that I am an agent-based AI)

That is, it should be enough for everyone to agree to lock the "everyone agrees" branch and throw away their own key, to keep that branch locked.


More information about the bitcoin-dev mailing list