public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Sjors Provoost <sjors@sprovoost.nl>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Wed, 08 May 2019 05:16:03 +0000	[thread overview]
Message-ID: <woFxDfVHc0Od_GjeuU7FXoYnIQLk-xBx3z68nryT6PQhBNKYRh3pdV3OEiw4vFKe2TGbbOmdDmxUAC4g80vfx3KRadk5_N0t3pSdS07cnPY=@protonmail.com> (raw)
In-Reply-To: <2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.com>

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.

Regards,
ZmnSCPxj


  reply	other threads:[~2019-05-08  5:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 17:57 [bitcoin-dev] Taproot proposal Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr
2019-05-07 20:42   ` Sjors Provoost
2019-05-08  4:37     ` ZmnSCPxj
2019-05-08  5:16       ` ZmnSCPxj [this message]
2019-05-08 23:06     ` Pieter Wuille
2019-05-18 17:51       ` ZmnSCPxj
2019-05-08  3:44   ` ZmnSCPxj
2019-05-09 16:56     ` Johnson Lau
2019-05-10  5:38       ` ZmnSCPxj
2019-05-08  4:49   ` Anthony Towns
2019-05-08 13:10   ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23  2:06   ` Pieter Wuille
2019-05-23  2:32     ` Russell O'Connor
2019-05-22 14:14 ` John Newbery
2019-09-16 16:18   ` Greg Sanders
2019-09-17  4:09     ` ZmnSCPxj
2019-09-18 21:21       ` Pieter Wuille
2019-06-27  0:08 ` Russell O'Connor
2019-06-28  9:49   ` Anthony Towns
2019-06-28 11:16     ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='woFxDfVHc0Od_GjeuU7FXoYnIQLk-xBx3z68nryT6PQhBNKYRh3pdV3OEiw4vFKe2TGbbOmdDmxUAC4g80vfx3KRadk5_N0t3pSdS07cnPY=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pieter.wuille@gmail.com \
    --cc=sjors@sprovoost.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox