> 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
Hi,
On Sun, 29 Dec 2019 at 10:23, ZmnSCPxj wrote:
>
> Indeed, this is a problem still of equal-valued CoinJoin.
> In theory the ZeroLink protocol fixes this by strongly constraining user
> behavior, but ZeroLink is not "purely" implemented in e.g. Wasabi: Wasabi
> still allows spending pre- and
This idea is not similar to the one in the knapsack paper because this one
is based only in the computational complexity of finding partitions that
match the outputs. However, and except in rare cases, there is only one
valid partition (solution) for each output, it doesn't introduce any
On Sun, 29 Dec 2019, 05:31 Yuval Kogman, wrote:
> n = # inputs + # indistinguishable outputs
>
sorry, this is really wrong (although of no consequence to my arguments) -
n is the smaller of these two numbers, not their sum.
___
bitcoin-dev mailing
Good morning Yuval,
> Additionally (though is a broader criticism of CoinJoin based privacy and not
> specific to unequal amounts, and in particular refers to ZmnSCPxj's assertion
> of 0 linkability) I am very worried that perspectives that focus on
> linkability information revealed by a
Hi,
On Sat, 28 Dec 2019 at 01:29, nopara73 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
I haven't read the whole thing in detail (and fwiw, I don't think I will by
this point), but I do want to respond to section about the combinatorics as
well as the proof, since both the
I'm only going to talk about cashfusion and not the knapsack paper.
The language they use to describe the cashfusion protocol is very
broad and could describe many things. Because it is hard so vague I
don't want to dismiss the cashfusion approach out of hand. For
instance they say: "inputs of
