From: DA Williamson <damian@willtech.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
Subject: Re: [bitcoin-dev] Taproot NACK
Date: Tue, 16 Mar 2021 22:39:47 +1100 [thread overview]
Message-ID: <932f2f2866cac087a207f8757c9df4b776ccdb04.camel@willtech.com.au> (raw)
In-Reply-To: <Wz83obOLCjtbO-rIDw9mHM0ObBrE10y1rLg8vbEyp5BIxtfzlUJyLlnPZ-RWnvsKzJaKRe4bo7hnjlJnwL4-g7HyRNa6TvL_Y-gBQ12ifCg=@protonmail.com>
Good Afternoon,
Verifiable and independantly verifiable are not the same. Independantly
scrutinable means any public can scrutinise blockchain to determine it
is honest. It does not rely on involved parties but insistently on the
data published in the blockchain. The accepted case of P2SH is also a
moot point since we are checking transactions and not where the balance
is but where it has come from. It is not further to P2SH which is not
obfuscation but is indeed publishing to then say that we only need
publicly disclose G3 which is a tangent obfuscation.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES
HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A.
James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m.
0487135719
f. +61261470192
This email does not constitute a general
advice. Please disregard this email if misdelivered.
On Tue, 2021-03-16 at 02:11 +0000, ZmnSCPxj via bitcoin-dev wrote:
> 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 redirect funds if dishonest? SPV wallets are
> > secure producing fully signed transactions. A ConJoin transaction
> > signs for the UTXO and forwards it to be included signed for in
> > another larger transaction with many inputs and outputs
>
> 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 outputs.
>
> 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 entity puts into the transaction, that entity also gets out (in
> freshly-generated addresses, which I hope you do not object to) as an
> output.
>
> When providing its signature, each entity verifies that its provided
> address 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 transaction..
>
> 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 signatures of an immutable document, and any
> attempt by that clerical actuary to change the document also destroys
> any signatures of that document, making the modified document (the
> transaction) invalid.
>
> > . Also, none of those you mention is inherently a Privacy
> > Technology. Transparency is one of the key articles of value in
> > Bitcoin because it prevents fraud.
>
> The prevention of fraud simply requires that all addition is
> validatable.
> It does not require that the actual values involved are visible in
> cleartext.
>
> Various cryptographic techniques already exist which allow the
> verifiable addition 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 what G was used, you would not know that you were checking
> the addition of 1 + 2 = 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 = 3,
> I could reveal the numbers involved and the point G I used, and any
> validator (including, say, a government taxing authority) can check
> that the points recorded on the blockchain match with what I claimed.
>
> For the prevention of fraud, we should strive to be as transparent as
> *little* as possible, while allowing users to *voluntarily* reveal
> information.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2021-03-16 11:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 3:23 [bitcoin-dev] Taproot NACK LORD HIS EXCELLENCY JAMES HRMH
2021-02-27 16:14 ` Jeremy
2021-02-28 11:36 ` LORD HIS EXCELLENCY JAMES HRMH
2021-02-28 13:07 ` Ariel Lorenzo-Luaces
2021-03-01 1:34 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-01 22:37 ` Eric Voskuil
2021-03-02 1:16 ` Daniel Edgecumbe
2021-03-03 3:06 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-03 11:58 ` eric
2021-03-03 16:30 ` micaroni
2021-03-03 14:49 ` Erik Aronesty
2021-03-04 5:06 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-05 14:04 ` Ryan Grant
2021-03-10 6:34 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-11 0:47 ` Keagan McClelland
2021-03-12 13:04 ` R E Broadley
2021-03-12 22:30 ` Eric Voskuil
2021-03-14 10:13 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-14 18:41 ` Aymeric Vitte
2021-03-17 4:19 ` ZmnSCPxj
2021-03-17 5:46 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-17 7:14 ` Eric Voskuil
2021-03-02 11:56 ` Chris Belcher
2021-03-03 11:22 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-16 2:11 ` ZmnSCPxj
2021-03-16 11:39 ` DA Williamson [this message]
2021-03-17 4:11 ` ZmnSCPxj
2021-03-17 8:13 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-17 9:32 ` ZmnSCPxj
2021-03-18 1:10 ` DA Williamson
2021-03-03 2:54 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-03 11:55 ` eric
2021-03-04 4:53 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-03 14:32 ` Thomas Hartman
2021-03-04 5:05 ` LORD HIS EXCELLENCY JAMES HRMH
[not found] <SL2P216MB008922741210CC853A51A5A19D979@SL2P216MB0089.KORP216.PROD.OUTLOOK.COM>
2021-03-04 7:46 ` Eric Voskuil
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=932f2f2866cac087a207f8757c9df4b776ccdb04.camel@willtech.com.au \
--to=damian@willtech.com.au \
--cc=ZmnSCPxj@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=willtech@live.com.au \
/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