[bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[prayank]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

I have explained the whole idea with a proof of concept in this link: https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1

Does it make sense to add such options in bitcoin core wallet and how is the overall idea once we have taproot because for now people can check if the tx involves a multisig address?

Reading Peter Wuille's reply here it seems taproot will improve privacy for multisig: 
https://www.reddit.com/r/Bitcoin/comments/etagx4/please_explain_taproot_and_schnorr_signatures/fffljnl/

Looking for some feedback to work on this idea and don't want it to just remain an article on medium. 

Thanks

Prayank


[-- Attachment #2: Type: text/html, Size: 1296 bytes --]

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[ZmnSCPxj]

Good morning Prayank

> I have explained the whole idea with a proof of concept in this link: https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1

The article is not clear I think, so please confirm my understanding below.

Participants:

* "Peer 3" - Payee
* "Peer 2" - Payer
* "Peer 1" - Enabling tr\*sted third party

Goal: Payer wants to pay to the payee 0.006BTC

Current Conditions:

* Payer owns 0.01 BTC in a single UTXO
* Third Party owns 0.05 BTC in a single UTXO

Protocol:

1.  Payer and Third Party compute a 2-of-3 address with the public keys of Payer, Payee, and Third Party.
2.  Payer and Third Party individually pay their owned funds to the 2-of-3 address.
3.  After confirmation, they consume the new outputs into another transaction with equal-valued outputs, hiding who owns which coins.

Is my understanding correct?

If so, I believe JoinMarket has a superior technology, which does not require a tr\*sted third party; it simply requires one or more UNtrusted third parties to participate in signing a single transaction that does not require paying to an intermediate m-of-n address (thus all inputs are singlesig).

Basically JoinMarket allows the market taker to decide how much the equal-value outputs are, and to define the address it goes to.
The destination address need not be one the market taker controls, it can be to a payee.
This technique is the only out-of-the-box way that a JoinMarket wallet can spend funds from a JoinMarket wallet.

JoinMarket as well already includes how to get in touch with enabling third parties (called "market makers").


Regards,
ZmnSCPxj

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[prayank]

[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]

Hello ZmnSCPxj, 


Thanks for the feedback.


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.

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.

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. 


Prayank


May 25, 2020, 12:24 by ZmnSCPxj@protonmail.com:

> Good morning Prayank
>
>> I have explained the whole idea with a proof of concept in this link: https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1
>>
>
> The article is not clear I think, so please confirm my understanding below.
>
> Participants:
>
> * "Peer 3" - Payee
> * "Peer 2" - Payer
> * "Peer 1" - Enabling tr\*sted third party
>
> Goal: Payer wants to pay to the payee 0.006BTC
>
> Current Conditions:
>
> * Payer owns 0.01 BTC in a single UTXO
> * Third Party owns 0.05 BTC in a single UTXO
>
> Protocol:
>
> 1.  Payer and Third Party compute a 2-of-3 address with the public keys of Payer, Payee, and Third Party.
> 2.  Payer and Third Party individually pay their owned funds to the 2-of-3 address.
> 3.  After confirmation, they consume the new outputs into another transaction with equal-valued outputs, hiding who owns which coins.
>
> Is my understanding correct?
>
> If so, I believe JoinMarket has a superior technology, which does not require a tr\*sted third party; it simply requires one or more UNtrusted third parties to participate in signing a single transaction that does not require paying to an intermediate m-of-n address (thus all inputs are singlesig).
>
> Basically JoinMarket allows the market taker to decide how much the equal-value outputs are, and to define the address it goes to.
> The destination address need not be one the market taker controls, it can be to a payee.
> This technique is the only out-of-the-box way that a JoinMarket wallet can spend funds from a JoinMarket wallet.
>
> JoinMarket as well already includes how to get in touch with enabling third parties (called "market makers").
>
>
> Regards,
> ZmnSCPxj
>


[-- Attachment #2: Type: text/html, Size: 3774 bytes --]

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[ZmnSCPxj]

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

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 5093 bytes --]


Hello ZmnSCPxj,

Thanks for your response.

The spending tx of multisig can be decided earlier and all three can review the outputs involved in it. All 3 txs involved in the system if we consider only one mixer and not a chain will get confirmed in the same block as we are using CPFP so child pays for 2 parent txs. However, disputes are possible and to manage it we will have to make the system complex with things like Peer 1 locking some amount in a 2 of 2 multisig with Peer 2 or some other incentives structure. Initially we can try to keep it simple and a way to spend coins after coinjoin with the help of another person you trust.
Yes, you described coinjoin in joinmarket but the problem I am trying to solve is: spend coins after coinjoin because post-mix usage is as important as coinjoin. Some users dont follow the best practices after coinjoin and it makes coinjoin useless or less effective in that case and sometimes for others involved in the process as well.
Samourai has few options for users to do this and one of them is: Stonewallx2 which is a mini coinjoin and similar to what I was trying with this idea.
End goal is to create more options for users to spend UTXOs easily in different ways after coinjoin which makes it difficult for people trying to analyze transactions or algorithms monitoring, flagging, reporting txs 24/7
Its just an idea for now and maybe I might find better ways to solve this problem once I start working on it. For me it makes sense to experiment with things and provide more options for users but I wanted to see what others think about it who are more experienced and skilled to develop bitcoin related projects.
Thanks for this link: https://zmnscpxj.github.io/offchain/generalized.html 

Looks interesting.
Prayank

May 26, 2020, 08:16 by ZmnSCPxj@protonmail.com:

> 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
>


[-- Attachment #2: Type: text/html, Size: 6074 bytes --]

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

[ZmnSCPxj]

Good morning Prayank,


> 1.  The spending tx of multisig can be decided earlier and all three can review the outputs involved in it. All 3 txs involved in the system if we consider only one mixer and not a chain will get confirmed in the same block as we are using CPFP so child pays for 2 parent txs. However, disputes are possible and to manage it we will have to make the system complex with things like Peer 1 locking some amount in a 2 of 2 multisig with Peer 2 or some other incentives structure. Initially we can try to keep it simple and a way to spend coins after coinjoin with the help of another person you trust.

The payee is not necessary here and you can remove the intermediate transactions that pay to 2-of-3s.

> 2.  Yes, you described coinjoin in joinmarket but the problem I am trying to solve is: spend coins after coinjoin because post-mix usage is as important as coinjoin. Some users dont follow the best practices after coinjoin and it makes coinjoin useless or less effective in that case and sometimes for others involved in the process as well.

...

I already mentioned this, but what I am describing is *how JoinMarket spends coins from its wallet*.

That means that what I am describing is *how JoinMarket performs spends after mixing, i.e. post-mix*.

I was not describing how JoinMarket performs mixing.

Is that clearer now?




Regards,
ZmnSCPxj