Skip to content

Wallet CoinJoin Doc Review Comments #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Wallet CoinJoin Doc Review Comments #32

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 8 additions & 7 deletions doc/mwc-wallet_coinjoin.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,16 +1,17 @@
# MWC-wallet coinjoin pool
# MWC-wallet CoinJoin Pool

In a context of a low number of on chain transactions, Dandelion is not really effective. To improve privary, MWC-wallet will do a coinjoin at wallet level. MWC-wallet will talk with other participating mwc-wallets and built a 'multikernel' transaction.
In a context of a low number of on-chain transactions, Dandelion is not really effective on the Mimblewimble transaction merging/CoinJoin. To improve privacy, MWC-wallet will do a CoinJoin at wallet level, with this design. MWC-wallet will cooperate with other participating MWC-wallets and build a 'multikernel' transaction.

The mwc-wallet coinjoin will take some time to process in order to capture enough transactions from honest wallet participants.
The MWC-wallet CoinJoin need take more time than Dandelion to process, in order to capture enough transactions from honest wallet participants for this CoinJoin. The time taking of the MWC-wallet CoinJoin will be addressed later.

This method can allow to obfuscate regular transactions, but it's not the primary use case for multiple reasons. In case of Non interactive transactions (NIT) it will be used more easily for regular transactions.
This method will obfuscate transaction graph, <ins>but it's not the primary use case for multiple reasons</ins> (why? what reason?).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The workflow normally required output regeneration. If Coinjoin session failed, the outputs need to be regenerated. It is hard to do with Interactive transactions because slate will need to be send to receiver once more.
Because of that for Coinjon and IT regular transaction, wallet can't allow session to fail. It is possible if the wallet will be at the end on the join chain (chain is twice larger than required) and willing to pay the extra fees. In this case, if next participant failed to process, the wallet will add fees to balance the coinjoin and publish.
So in order to make that work, wallet need to control it's position in the chain and willing to pay extra fees if something will go wrong. Or willing wait for a relatively long time.

I should probably need to add a table that will demonstrate the fees and cost to publish (attack) the coinjoin transaction.


In case of Non-Interactive Transaction (NIT), this method is more easily, because ... (?)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above. "If Coinjoin session failed, the outputs need to be regenerated.". NIT transaction can regenerate outputs, so it is no problem to retry.


## Checking traceability of the outputs.

The mwc-wallet will inspect the blocks and indentify the outputs that are potentially traceable.
It will assume outputs are untraceable if the block contain multiple transactions (more then T kernels and T outputs)
## Checking Traceability of The Outputs.

The MWC-wallet will inspect the blocks and identify the outputs that are potentially traceable, simply by checking the transaction numbers in the block. It will assume outputs are untraceable if the block contain enough transactions (more than T kernels and T outputs)
Value of T need to be defined by user, more is better. Value of 5 should give good privacy assuming no observer was tracking transactions from mempool in the past.

Over a certain time period, because of the cut-though, the number of kernels and outputs will decline. Because of that
Expand Down