Re: [bitcoin-dev] Wasabi Wallet 2.0 Testnet Release

[nopara73 via bitcoin-dev]

>  There is no coin control in Wasabi Wallet 2.

This is correct, but in and of itself can be misleading for those who know
that privacy in Bitcoin is near impossible without coin control, because
the conclusion would be then that Wasabi 2.0 ruined privacy for no reason,
which is obviously not the case, in fact it improves it in many ways.

The idea is that you don't need coin control when you can make your
transaction with coinjoined coins. These coins are indistinguishable, so
you don't really have a use for coin control in that case. I think this is
non-controversial, but what about the case when you cannot make the tx from
coinjoined coins?

In that case there still is a mandatory privacy control, which is an
improved version of coin control. The insight here is that, in coin control
settings, users are differentiating between coins based on their labels.
Since Wasabi creates label clusters, it is ok to select the clusters the
user wants to make the transaction from instead of individual coins. I know
you liked the never released cluster selection page before it got further
improved to be a privacy control page, but note the privacy control still
uses the same insight, it just further removed unnecessary friction. That
being said, coins can also be seen with this super secret developer key
combination: CTRL + D + C

> User does not select coins because they are never shared with the user in
the first place.

As explained above it is selecting coins indirectly rather than directly.
It is selecting clusters of coins that are assumed to belong to the same
wallet from an outside observer's point of view instead of individually
selecting coins one by one.

>  There are no 'private' coins. Every coin is public in Bitcoin.

Not sure I'd like to engage in bikeshedding on terminology, but in my
opinion this terminology is not only true, but also good and useful:
Ownership of equalized coinjoin UTXOs is only known by the owner and not by
external observers. The owner has control over who it reveals the ownership
of these UTXOs. Privacy is your ability to selectively reveal yourself to
the world, therefore the terminology of "private coins" naturally makes
sense and it's a useful differentiator from non-coinjoined coins.

>  Since, the wallet assumes some coins as 'private' based on certain
things it can be misleading for the user. Privacy depends on the things
users want to share with others.

The wallet does not assume. The user assumes when selecting the anonymity
levels. The wallet works with the user's assumption of its threat model. If
a misleading claim can be made here then it's that the user misleads the
wallet (and her/himself) rather than the other way around.

>  Privacy involved in using a change or not using it is debatable. Not
using a change address makes it easier to understand who might be the
recipient in a transaction whereas using a change address same as other
outputs would be difficult to analyze for possible recipients.

Although I agree it's debatable, but for different reasons. I'd rather take
an issue of its usefulness instead. About the assumption that it's easier
to understand who might be the recipient, that's incorrect as the
transaction can easily be considered a self spend. In comparison to change
generating transactions, there the change and the recipient can most of the
times be established.

>  Wasabi wallet does not have different types of addresses to use for a
change however [Bitcoin Core][2] recently made some related improvement
which would improve privacy.

Yup. Unfortunately this is a hack to make the wallet feel like a light
wallet as it greatly reduces the size of the client side filters we have.
Although, as the blockchain grows further optimizations are needed. So it's
not very helpful if Bitcoin Core gives us 10 GB of filters so we can use
all the types of addresses. We had a pull request to Core about creating
custom filters, but it was NACK-ed. In order to do this correctly and get
merged into Core we'd have to have a more comprehensive modification than
our initial PR and that we have no resources to allocate to yet.

>  As far as issues are concerned, there are several things not fixed and
shared in different GitHub issues or discussions. These include privacy,
security and other things.

I greatly disagree with this assessment, in fact, quite the opposite. Take
for example the tremendous activity your pull request about an empty catch
block received: https://github.com/zkSNACKs/WalletWasabi/pull/6791
No sane project would allow their best developers to spend more than 5
minutes on this issue, yet 7 developers were discussing if leaving a single
empty catch block in the code could be a potential security risk in the
future and our resolution was actually contributing to NBitcoin to make
sure we aren't getting an exception for incorrect password, but rather a
boolean signal.

>  As WW2 is not developed for power users (mentioned by developers working
on Wasabi), 

Re: [bitcoin-dev] Wasabi Wallet 2.0 Testnet Release

[nopara73 via bitcoin-dev]

The first Wasabi Wallet 2.0 testnet coinjoin with real users:
https://blockstream.info/testnet/tx/68849dc71e6eb860b4b8aa3f57b9bc8178a002b54f85a46305bfaaad28b40444

On Tue, Mar 1, 2022 at 11:27 PM Max Hillebrand via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello list,
>
> tl;dr: we have been working on a little something, and Wasabi 2.0 is now
> ready for your review and feedback.
>
> Wasabi Wallet 2.0 is a Bitcoin wallet providing effortless privacy for
> its users. Just like Wasabi 1.0, this is achieved by default on the
> network layer with a deep Tor integration, and on the synchronization
> layer with BIP158 block filters or the packaged Bitcoin full node.
> However, 2.0 upgrades the privacy on the blockchain layer with a new
> Wabisabi coinjoin implementation, running by default in the background.
>
> Wabisabi is a drop-in replacement for the ZeroLink coinjoin coordination
> protocol. Instead of Chaumian [or Schnorr] blind signatures, it uses
> keyed verified anonymous credentials and Pedersen commitments. This
> enables anonymous DoS protection for centrally coordinated coinjoins
> without relying on equal amount outputs. This flexibility in the
> coordination enables a more sophisticated amount decomposition,
> specifically with standard denominations of low Hamming weight, in our
> case powers of two, powers of three, and the preferred value series [1,
> 2, 5]. In our simulations, this results often in "changeless" coinjoins
> [all outputs at least two anonymity set, aka count of equal value
> outputs] for transactions with more than 50 inputs. Whereas in Wasabi
> 1.0 each user had to participate in the smallest standard denomination
> of 0.1 btc, now there is no mandatory output decomposition, and the
> minimum amount is 5000 sats. This is **substantial** block space
> savings, reducing the amount of mining fees paid, and the time until the
> user's utxo set is private.
>
> Thanks to these efficiency improvements, we are now comformaking
> coinjoin transactions the default in Wasabi's UX. As soon as bitcoin is
> received in the wallet, the client will register the confirmed coin as
> input for the PSBT with the backend coordinator. Within a couple hours,
> the user has numerous utxos which can be spent privately without
> revealing their pre-mix transaction history. The resulting UX is simple:
> receive, wait, spend. Privately. Effortless. For everyone.
>
> Whenever the user wants to spend bitcoin to an address, the wallet
> automatically selects those private coins with sufficient sats, coin
> control is displayed to the user. However, when the private balance is
> insufficient to make the payment, the user has the option to adjust the
> coin selection with the help of the previously provided contact labels.
> Since labeling is mandatory in Wasabi, we can abstract away the utxo
> concept and display only the contact labels for the users to choose
> from. Wasabi also suggests the user to slightly adjust the payment
> amount so as to avoid the creation of a change utxo, decreasing fees and
> improving future privacy.
>
> Today, we are proud to finally reveal our work in progress in a public
> preview release with coinjoin on testnet. We kindly ask for your help
> testing the completely new UI/UX, reviewing the cryptography and
> coordination protocol, and especially coinjoining to analyze the
> resulting transaction graph in the wild.
>
> Thank you to all contributors past and present!
>
> Skol
> Max Hillebrand
>
> Download the testnet release:
> https://github.com/zkSNACKs/WalletWasabi/releases/tag/v1.98.0.0
>
> Website: https://wasabiwallet.io
> Onion:
> http://wasabiukrxmkdgve5kynjztuovbg43uxcbcxn6y2okcrsg7gb6jdmbad.onion
> Testnet coordinator:
> http://testwnp3fugjln6vh5vpj7mvq3lkqqwjj3c2aafyu7laxz42kgwh2rad.onion
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[nopara73 via bitcoin-dev]

ACK adding Kalle

On Fri, Apr 23, 2021 at 5:51 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Luke,
>
> For the records and the subscribers of this list not following
> #bitcoin-core-dev, this mail follows a discussion which did happen during
> yesterday irc meetings.
> Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log
>
> I'll reiterate my opinion expressed during the meeting. If this proposal
> to extend the bip editorship membership doesn't satisfy parties involved or
> anyone in the community, I'm strongly opposed to have the matter sliced by
> admins of the Bitcoin github org. I believe that defect or uncertainty in
> the BIP Process shouldn't be solved by GH janitorial roles and I think
> their roles don't bestow to intervene in case of loopholes. Further, you
> have far more contributors involved in the BIP Process rather than only
> Bitcoin Core ones. FWIW, such precedent merits would be quite similar to
> lobby directly GH staff...
>
> Unless we harm Bitcoin users by not acting, I think we should always be
> respectful of procedural forms. And in the lack of such forms, stay patient
> until a solution satisfy everyone.
>
> I would recommend the BIP editorship, once extended or not, to move in its
> own repository in the future.
>
> Cheers,
> Antoine
>
>
>
>
> Le jeu. 22 avr. 2021 à 22:09, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
>> assist in merging PRs into the bips git repo.
>>
>> Since there is no explicit process to adding BIP editors, IMO it should
>> be
>> fine to use BIP 2's Process BIP progression:
>>
>> > A process BIP may change status from Draft to Active when it achieves
>> > rough consensus on the mailing list. Such a proposal is said to have
>> > rough consensus if it has been open to discussion on the development
>> > mailing list for at least one month, and no person maintains any
>> > unaddressed substantiated objections to it.
>>
>> A Process BIP could be opened for each new editor, but IMO that is
>> unnecessary. If anyone feels there is a need for a new Process BIP, we
>> can go
>> that route, but there is prior precedent for BIP editors appointing new
>> BIP
>> editors, so I think this should be fine.
>>
>> Please speak up soon if you disagree.
>>
>> Luke
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

[nopara73 via bitcoin-dev]

Wouldn't this enable a passive adversary listening the mempool to associate
unrelated TXO clusters to the same user?

On Sat, Sep 19, 2020, 15:38 David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> > I'd like to share with you a draft proposal for a mechanism to replace
> > CPFP and RBF for increasing fees on transactions in the mempool that
> > should be more robust against attacks.
>
> Interesting idea!  This is going to take a while to think about, but I
> have one immediate question:
>
> > To prevent garbage sponsors, we also require that:
> >
> > 1. The Sponsor's feerate must be greater than the Sponsored's ancestor
> fee rate
> >
> > We allow one Sponsor to replace another subject to normal replacement
> > policies, they are treated as conflicts.
>
> Is this in the reference implementation?  I don't see it and I'm
> confused by this text.  I think it could mean either:
>
> 1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least
>one input in common (which is part of the "normal replacement policies")
>
> 2. A can be replaced by B even if they don't have any inputs in common
>as long as they do have a Sponsor Vector in common (while otherwise
>using the "normal replacement policies").
>
> In the first case, I think Mallory can prevent Bob from
> sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a
> sponsor before he does; since Bob has no control over Mallory's inputs,
> he can't replace Mallory's sponsor tx.
>
> In the second case, I think Mallory can use an existing pinning
> technique to make it expensive for Bob to fee bump.  The normal
> replacement policies require a replacement to pay an absolute higher fee
> than the original transaction, so Mallory can create a 100,000 vbyte
> transaction with a single-vector sponsor at the end pointing to Bob's
> transaction.  This sponsor transaction pays the same feerate as Bob's
> transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee.  In order
> for Bob to replace Mallory's sponsor transaction with his own sponsor
> transaction, Bob needs to pay the incremental relay feerate (10
> nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).
>
> Thanks,
>
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

[nopara73 via bitcoin-dev]

Thank you all for your replies, I think everyone agrees here how it "should
be" and indeed I risked my post and my used terminology to further
legitimize the thinking of adversaries.
I'd have one clarification to my original post. It may not be clear why I
put PJ/CS to the same box. One way of thinking of CoinSwap is to swap coin
histories and PayJoin is to share coin histories. For the purposes of this
attack the consequences are roughly the same so that's why I think it's ok
to put them under the same umbrella in this discussion, but I wouldn't die
for it :)

And indeed I perhaps wrongly called this the "Taint Issue", maybe it should
be called "Coin Discrimination Issue" or something like that, not sure if
we have a term for this, but I'm sure we should have a term for this as
unlike some other, so far theoretical attacks on Bitcoin's fungibility, it
is currently being applied in practice.


On Thu, Jun 11, 2020 at 7:24 AM Mr. Lee Chiffre via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thought provoking. In my opinion bitcoin should be designed in a way to
> where there is no distinction between "clean" bitcoins and "dirty"
> bitcoins. If one bitcoin is considered dirty then all bitcoins should be
> considered dirty. Fungibility is important. And bitcoin or its users
> should not be concerned with pleasing governments. Bitcoin should be or
> remain neutral. The term "clean" or "dirty" is defined by whatever
> government is in power. Bitcoin is not to please government but to be
> independent of government control and reliance on government or any other
> centralized systems. To act as censorship resistant money to give people
> freedom from tyranny. I'm just saying that if anyone can determine if a
> bitcoin is clean or dirty then I think we are doing something wrong. What
> is great with certain protocols like coinjoin coinswap and payjoin there
> is that plausible deniability that hopefully would spread the entire
> "taint" of bitcoin collectively either for real or just as a possibility
> to any blockchain analysis entities (with no real way to tell or interpret
> with accuracy).
>
> Bitcoin should be designed in a way where the only way to stop "dirty"
> bitcoins is to reject all bitcoins.
>
> If "dirty" bitcoins is actually a real thing then I guess I could have fun
> by polluting random peoples bitcoin addresses with "dirty" coins right? No
> way to prove if it is a self transfer or an unsolicited "donation".  I
> just do not see how any bitcoin UTXO censorship could work because of
> plausible deniability.
>
> If any company actually used UTXO censorship then customers can just use
> services that are respecting of freedom and do not use censorship.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

[nopara73 via bitcoin-dev]

The problem with CoinJoins is that desire for privacy is explicitly
signalled by them, so adversaries can consider them "suspicious." PayJoin
and CoinSwap solve this problem, because they are unnoticeable. I think
this logic doesn't stand for scrutiny.

>From here on let's use the terminology of a typical adversary: there are 3
kinds of coin histories: "clean", "dirty" and "suspicious".
The aftermath of you using a "dirty" coin is knocks on your door. You using
a "suspicious" coin is uncomfortable questions and you using a "clean" coin
is seamless transfer.

In scenario 1, you start out with a "clean" history. By using CoinJoins you
make your new coin's history "suspicious" so you have no incentive to
CoinJoin. By using CoinSwap/PayJoin your new coin can be either "clean" or
"dirty". What would a "clean" coin owner prefer more? Take the risk of
knocking on the door or answering uncomfortable questions?

In scenario 2, you start out with a "dirty" history. By using CoinJoins you
make your new coin's history "suspicious" so you have an incentive to
CoinJoin. By using CoinSwap/PayJoin your new coin can either be "clean" or
"dirty". What would a "dirty" coin owner prefer more? And here's an
insight: you may get knocks on your door for a dirty coin that you have
nothing to do with. And you can prove this fact to the adversary, but by
doing so, you'll also expose that you started out with a "dirty" coin to
begin with and now the adversary becomes interested in you for a different
reason.

You can also examine things assuming full adoption of PJ/CS vs full
adoption of CJ, but you'll see that full adoption of any of these solves
the tainting issue.

So my current conclusion is that PJ/CS does not only not solve the taint
problem, it just alters it and ultimately very similar problems arise for
the users. Maybe the goal of unobservable privacy is a fallacy in this
context as it is based on the assumption that desiring privacy is
suspicious, so you want to hide the fact that you desire privacy. And the
solution to the taint issue is either protocol change or social change
(decent adoption.)

PS.: Please try to keep the conversation to the Taint Issue as this email
of mine isn't supposed to be discussing general pros and cons of various
privacy techniques.

Any thoughts?

-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Academic research regarding BIP0002

[nopara73 via bitcoin-dev]

Just a tip: if you'd like to get feedback on your work, then share your
work as well, since not many people are willing to commit to helping unless
they know how large the work is.

On Tue, Apr 21, 2020 at 10:51 PM Shiva Jairam via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
>
>
> I am doing a project trying to map out BIP002 (
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) into a
> bussiness process model using BPMN2.0.
>
> This is a project regarding an academic research for my studies.
>
> I am by no means an expert in Blockchain nor Bitcoin and have just
> recently began looking into the technologies.
>
>
>
> Is someone willing to review or discuss my model?
>
> If this is not the right place to discuss such a topic, pointing in the
> right direction is much appreciated.
>
>
>
>
>
> Kind regards,
>
> Shiva Jairam
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [bitcin-dev] BIP157 Filter Type Extensibility Proposal for Combinations

[nopara73 via bitcoin-dev]

BIP157 defines a section called "Filter Types" (
https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki#filter-types
 )

>  For the sake of future extensibility and reducing filter sizes, there
are multiple *filter types* that determine which data is included in a
block filter as well as the method of filter construction/querying. In this
model, full nodes generate one filter per block per filter type supported.

>  Each type is identified by a one byte code, and specifies the contents
and serialization format of the filter. A full node MAY signal support for
particular filter types using service bits. The initial filter types are
defined separately in BIP 158
, and one
service bit is allocated to signal support for them.

While it provides a way to extend to multiple filter types, it does not
provide a way to extend to filter type combinations. Such combinations are
possible if the filter types would have to be defined with the power of
two: 1, 2, 4, 8, 16..., so every octet of a byte array could denote a
specific filter type, this way we could be able to signal for any number of
combinations of those filter types.

Originally this idea is described in more details and with code here:
https://github.com/bitcoin/bitcoin/issues/18221

MarcoFalke suggested for me to submit it to the mailing list instead of a
GitHub issue then propose an update to the BIP if consensus is reached.

-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Non-equal value CoinJoins. Opinions.

[nopara73 via bitcoin-dev]

>  It seems to me that most users will not have nearly the same output of
"around 1 BTC"

While that would be true out of context, it depends on how you interpret it
and they interpret it really broadly: " One input might be 0.03771049 BCH;
the next might be 0.24881232 BCH, etc. "

> anyway if you deploy this on a real live mainnet, and if your math
requires that you have "around 1 BTC" outputs per user. you might as well
just use equal-valued CoinJoins, where the equal-valued outputs at least
are completely unlinked from the inputs.
>  e.g. if you have a CashFusion transaction with outputs 1.0, 1.1, 0.99,
you could transform that to a CoinJoin with 0.99, 0.99, 0.99, 0.01, 0.11
outputs.

Equal valued coinjoins (1) waste more blockspace as your example
illustrates and (2) prevent arbitrary amounts, so you cannot send in
coinjoins.

> Indeed, the change outputs of an equal-valued CoinJoin would have similar
analyses to CashFusion, since the same analysis "around 1 BTC" can be
performed with the CoinJoin change outputs "around 0 BTC".

I've been wondering about this too. I think it cannot be applied to
existing CoinJoin schemes, as coin selection heuristics are quite a help
and that could be a reason why the changes can be deanonymized (I assume.)
For example if I want to analyze a Wasabi CJ, then I assume every input
that have > 0.1 BTC value to be THE valid input partition and I will only
look for the valid matching partition on the output side. I won't try to
find all the partitions and look at all the possible subset sums. (
https://github.com/nopara73/Notes/blob/master/BellNumber.md,
https://github.com/nopara73/Notes/blob/master/SubSetSum.md)

At the very least coin selection for equal value coinjoins can be relaxed
to remove such assumptions and make the above math applicable for the
change. (If works.)



On Sun, Dec 29, 2019 at 12:25 AM ZmnSCPxj  wrote:

> Good morning Adam,
>
> > The CashFusion research came out of the Bitcoin Cash camp, thus this
> probably went under the radar of many of you. I would like to ask your
> opinions on the research's claim that, if non-equal value coinjoins can be
> really relied on for privacy or not.
> >
> > (Btw, there were also similar ideas in the Knapsack paper in 2017:
> https://www.comsys.rwth-aachen.de/fileadmin/papers/2017/2017-maurer-trustcom-coinjoin.pdf
>  )
> >
> >
> https://github.com/cashshuffle/spec/blob/master/CASHFUSION.md#avoiding-amount-linkages-through-combinatorics
>
> >
> > I copy the most relevant paragraphs here:
> >
> >   -BEGIN QUOTE -
> >
> >
> > Consider a transaction where 10 people have each brought 10 inputs of
> arbitary amounts in the neighborhood of ~0.1 BCH. One input might be
> 0.03771049 BCH; the next might be 0.24881232 BCH, etc. All parties have
> chosen to consolidate their coins, so the transaction has 10 outputs of
> around 1 BCH. So the transaction has 100 inputs, and 10 outputs. The first
> output might be 0.91128495, the next could be 1.79783710, etc.
> >
> > Now, there are 100!/(10!)^10 ~= 10^92 ways to partition the inputs into
> a list of 10 sets of 10 inputs, but only a tiny fraction of these
> partitions will produce the precise output list. So, how many ways produce
> this exact output list? We can estimate with some napkin math. First,
> recognize that for each partitioning, each output will typically land in a
> range of ~10^8 discrete possibilities (around 1 BCH wide, with a 0.0001
> BCH resolution). The first 9 outputs all have this range of possibilities,
> and the last will be constrained by the others. So, the 10^92 possibilies
> will land somewhere within a 9-dimensional grid that cointains
> (10^8)^9=10^72 possible distinct sites, one site which is our actual output
> list. Since we are stuffing 10^92 possibilties into a grid that contains
> only 10^72 sites, then this means on average, each site will have 10^20
> possibilities.
> >
> > Based on the example above, we can see that not only are there a huge
> number of partitions, but that even with a fast algorithm that could find
> matching partitions, it would produce around 10^20 possible valid
> configurations. With 10^20 possibilities, there is essentially no linkage.
> The Cash Fusion scheme actually extends this obfuscation even further. Not
> only can players bring many inputs, they can also have multiple outputs.
> >
> > -END QUOTE -
> > --
>
>
> It seems to me that most users will not have nearly the same output of
> "around 1 BTC" anyway if you deploy this on a real live mainnet, and if
> your math requires that you have "around 1 BTC" outputs per user. you might
> as well just use equal-valued CoinJoins, where the equal-valued outputs at
> least are completely unlinked from the inputs.
>
> Indeed, the change outputs of an equal-valued CoinJoin would have similar
> analyses to CashFusion, since the same analysis "around 1 BTC" can be
> performed with the CoinJoin change outputs "around 0 BTC".
>
> * You can 

[bitcoin-dev] Non-equal value CoinJoins. Opinions.

[nopara73 via bitcoin-dev]

The CashFusion research came out of the Bitcoin Cash camp, thus this
probably went under the radar of many of you. I would like to ask your
opinions on the research's claim that, if non-equal value coinjoins can be
really relied on for privacy or not.

(Btw, there were also similar ideas in the Knapsack paper in 2017:
https://www.comsys.rwth-aachen.de/fileadmin/papers/2017/2017-maurer-trustcom-coinjoin.pdf
 )

https://github.com/cashshuffle/spec/blob/master/CASHFUSION.md#avoiding-amount-linkages-through-combinatorics


I copy the most relevant paragraphs here:

  -BEGIN QUOTE -


Consider a transaction where 10 people have each brought 10 inputs of
arbitary amounts in the neighborhood of ~0.1 BCH. One input might be
0.03771049 BCH; the next might be 0.24881232 BCH, etc. All parties have
chosen to consolidate their coins, so the transaction has 10 outputs of
around 1 BCH. So the transaction has 100 inputs, and 10 outputs. The first
output might be 0.91128495, the next could be 1.79783710, etc.

Now, there are 100!/(10!)^10 ~= 10^92 ways to partition the inputs into a
list of 10 sets of 10 inputs, but only a tiny fraction of these partitions
will produce the precise output list. So, how many ways produce this exact
output list? We can estimate with some napkin math. First, recognize that
for each partitioning, each output will typically land in a range of ~10^8
discrete possibilities (around 1 BCH wide, with a 0.0001 BCH
resolution). The first 9 outputs all have this range of possibilities, and
the last will be constrained by the others. So, the 10^92 possibilies will
land somewhere within a 9-dimensional grid that cointains (10^8)^9=10^72
possible distinct sites, one site which is our actual output list. Since we
are stuffing 10^92 possibilties into a grid that contains only 10^72 sites,
then this means on average, each site will have 10^20 possibilities.

Based on the example above, we can see that not only are there a huge
number of partitions, but that even with a fast algorithm that could find
matching partitions, it would produce around 10^20 possible valid
configurations. With 10^20 possibilities, there is essentially no linkage.
The Cash Fusion scheme actually extends this obfuscation even further. Not
only can players bring many inputs, they can also have multiple outputs.
-END QUOTE -
-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev