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
133
134
135
136
137
138
139
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1E755C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 02:11:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 05C1D6059C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 02:11:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.101
X-Spam-Level: *
X-Spam-Status: No, score=1.101 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Tqu8OLtOVG5O
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 02:11:27 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by smtp3.osuosl.org (Postfix) with ESMTPS id 380BF60599
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 02:11:26 +0000 (UTC)
Date: Tue, 16 Mar 2021 02:11:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1615860683;
bh=TdXOpUEqEfGuBdMpa4gcRpOQMZhj+60ncaaJN0y+kZQ=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=v65oIVrf9cpCb6dEU0OxP6l42iAQ7KHm3Rnv2Uo6Y9Pl8DPp6yG/8oul8nTwhdChA
IBRRDCTUQtzKYisuMWoD74srMToq2EIJpwOnXjFOnzbXMdud2CIdXqXWH/gUG7rkp6
VFFg3pM8+yFhJUpbp1WXK6CJmaepwTXmSwGOYyHs=
To: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Wz83obOLCjtbO-rIDw9mHM0ObBrE10y1rLg8vbEyp5BIxtfzlUJyLlnPZ-RWnvsKzJaKRe4bo7hnjlJnwL4-g7HyRNa6TvL_Y-gBQ12ifCg=@protonmail.com>
In-Reply-To: <SL2P216MB00896086AA80DE1A98293C469D989@SL2P216MB0089.KORP216.PROD.OUTLOOK.COM>
References: <SL2P216MB0089B70AEDD58F2EBC46B4309D9A9@SL2P216MB0089.KORP216.PROD.OUTLOOK.COM>
<A326C6D2-7C6E-42A2-93C9-DC7647BB09B6@voskuil.org>
<170b27c0-436f-c440-e3c3-f9577b764972@riseup.net>
<SL2P216MB00896086AA80DE1A98293C469D989@SL2P216MB0089.KORP216.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Taproot NACK
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 16 Mar 2021 02:11:29 -0000
Good morning JAMES,
> No-one has yet demonstrated that Conjoin or using Wasabi wallet is secure=
if it relies on third-parties. Are the transaction not forwarded partially=
signed as with an SPV wallet? So it is possible the SPV server cannot redi=
rect funds if dishonest? SPV wallets are secure producing fully signed tran=
sactions. A ConJoin transaction signs for the UTXO and forwards it to be in=
cluded signed for in another larger transaction with many inputs and output=
s
The above point was not answered, so let me answer this for elucidation of =
you and any readers.
A CoinJoin transaction is a single transaction with many inputs and many ou=
tputs.
Every input must be signed.
When used to obfuscate, each input has different actual entities owning the=
coin.
In order to prevent fraud, it is necessary that what total amount each enti=
ty puts into the transaction, that entity also gets out (in freshly-generat=
ed addresses, which I hope you do not object to) as an output.
When providing its signature, each entity verifies that its provided addres=
s exists in some output first before signing out its input.
The provided signature requires all the inputs and all the outputs to exist=
in the transaction.
Because of this, it is not possible to take a "partial" signature for this =
transaction, then change the transaction to redirect outputs elsewhere --- =
the signature of previous participants become invalid for the modified tran=
saction..
Thus, the security of the CoinJoin cannot be damaged by a third party.
Third parties involved in popular implementations of CoinJoin (such as the =
coordinator in Wasabi) are nothing more than clerical actuaries that take s=
ignatures of an immutable document, and any attempt by that clerical actuar=
y to change the document also destroys any signatures of that document, mak=
ing the modified document (the transaction) invalid.
> . Also, none of those you mention is inherently a Privacy Technology. Tra=
nsparency is one of the key articles of value in Bitcoin because it prevent=
s fraud.
The prevention of fraud simply requires that all addition is validatable.
It does not require that the actual values involved are visible in cleartex=
t.
Various cryptographic techniques already exist which allow the verifiable a=
ddition of encrypted values ("homomorphisms").
You can get 1 * G and 2 * G, add the resulting points, and compare it to 3 =
* G and see that you get the same point, yet if you did not know exactly wh=
at G was used, you would not know that you were checking the addition of 1 =
+ 2 =3D 3.
That is the basis of a large number of privacy coins.
At the same time, if I wanted to *voluntarily* reveal this 1 + 2 =3D 3, I c=
ould reveal the numbers involved and the point G I used, and any validator =
(including, say, a government taxing authority) can check that the points r=
ecorded on the blockchain match with what I claimed.
For the prevention of fraud, we should strive to be as transparent as *litt=
le* as possible, while allowing users to *voluntarily* reveal information.
Regards,
ZmnSCPxj
|
