Great to see an implementation of the idea.
Maybe I misunderstand, but isn't there a vulnerability of denial of service
here?
A user who registers one input will receive the round secret identifier, and
this is all the information required for output registration. However, that
malicious user
asabi/blob/8016404503bdffa475d8b219a6fe019a1d5775aa/WalletWasabi/WabiSabi/Client/CoinJoinClient.cs#L366-L433
WIP max suggested input value:
https://github.com/zkSNACKs/WalletWasabi/pull/7748
On 4/6/22 18:05, Max Hillebrand via bitcoin-dev wrote:
Hello list,
tl;dr: client side coinjoin amount organization
Hello list,
tl;dr: client side coinjoin amount organization is bloody difficult. Our
current approach: pick random number of inputs based on wallet utxo
count; pick that group of inputs which result in the lowest anonscore
consolidation penalty; generate deterministic frequency table as
Schel
Hello List,
tl;dr, users of WabiSabi coinjoin can pay arbitrary amounts of bitcoin,
so that the sender does not learn the address/output of the receiver,
and the receiver does not learn the input of the sender. This improves
the previously proposed 'Wormhole' for Chaumian blind signature
coin
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 in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello all!
May I propose you this protocol which seemingly provides a great level
of privacy for both the sender and receiver of bitcoin. This was
initially posted to the [Wasabi Wallet
GitHub](https://github.com/zkSNACKs/Meta/issues/64), and afte
