From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "prayank@tutanota•de" <prayank@tutanota•de>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet
Date: Tue, 26 May 2020 02:46:07 +0000 [thread overview]
Message-ID: <jrsxyefXxsLMundu38HnLPf8f_SnedDldcopEiFUZj0A4rsdm6NtdkNQsI3fvUd34Nf2LcLt1vnv5aAJR2bmY4keM69Xsu0uoIng2ILh9t4=@protonmail.com> (raw)
In-Reply-To: <M8AkjX3--3-2@tutanota.de>
Good morning Prayank,
> 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in a way that some peers involved in this system can provide liquidity for others and incentives can be a small fee.
It is not clear in the article, but you mention using a 2-of-3, and show 3 participants.
It seems to me that Peer 1 and Peer 3 (2-of-3) can simply sign to spend the funds coming from Peer 2, and split the funds of Peer 2 among them, without getting input from Peer 2.
That is the reason why I consider this tr\*sted --- Peer 2 has to trust Peer 1 does not collude with Peer 3 to steal the funds of Peer 2.
Unless I have misunderstood your article, which is why I asked for clarification.
> 2. Yes joinmarket is awesome and its payjoin will be better to achieve the same but I was trying to contribute and add more options for people to improve privacy on Bitcoin. If we have different ways to mix it will be harder for spy companies to analyze of some of the transactions.
* While JoinMarket has *a* PayJoin implementation, what I described in the previous email was not a PayJoin, it is standard CoinJoin where one of the equal-valued outputs is to the payee.
* In particular, PayJoin requires the cooperation of the payee, what I described does *not* require anything from the payee other than a destination address and an amount to pay.
* Your described technique (as I understand it) is not too different from what JoinMarket already does for normal sends, with the JoinMarket technique having the advantage that it works with the current paradigm of "send payment to this address" without reconnecting to the payee.
The advantage you describe is largely had only if the technique is significantly different.
For instance, CoinSwap and CoinJoinXT are different enough from CoinJoin to be valuable in this respect.
> 3. Also one such setup might not make a huge difference but a chain of such mixers will surely work better if everything done correctly.
>
> 4. Maybe multisig usage is not ideal for such things right now and I am not the best person when it comes to coding but think that better privacy for multisig will make it possible for lot of ideas to be implemented on Bitcoin using different multisig setups and combination of other things that we already have.
Schnorr (which is introduced as a package deal with Taproot) already makes all n-of-n look the same as 1-of-1 without tr\*sted setup, and makes hidden m-of-n possible with some kind of setup (possibly untrusted I think, but I am not enough of a mathist to describe this, in any case my base understanding is that the setup for m-of-n Schnorr requires a complex ritual involving a number of communication rounds).
Taproot allows to hide explicit m-of-n in a script behind some kind of n-of-n or m-of-m.
So multisignature usage would automatically gain such advantage once Taproot gets deployed.
In any case, if you are still interested in protocol design with some amount of focus on privacy, please consider reading this article as well: https://zmnscpxj.github.io/offchain/generalized.html
What exactly is your goal here.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-05-26 2:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-24 21:44 prayank
2020-05-25 6:54 ` ZmnSCPxj
2020-05-25 12:16 ` prayank
2020-05-26 2:46 ` ZmnSCPxj [this message]
2020-05-26 12:50 ` Prayank
2020-05-27 4:11 ` ZmnSCPxj
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='jrsxyefXxsLMundu38HnLPf8f_SnedDldcopEiFUZj0A4rsdm6NtdkNQsI3fvUd34Nf2LcLt1vnv5aAJR2bmY4keM69Xsu0uoIng2ILh9t4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=prayank@tutanota$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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