Date: Tue, 16 Mar 2021 02:11:15 +0000
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
Precedence: list

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