1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C5FBCC6
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
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 <pieter.wuille@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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(=
<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
|
