Pages:
Author

Topic: 2 New bug reports DELETED from Samourai Wallet's Gitlab Repo - page 2. (Read 571 times)

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Have you tried opening similar issues with a different account since it could be possible that Samourai team is removing anything you post specifically because you are a well known Wasabi shill. Tongue

Feel free to report the bug yourself if you think that my privacy expertise is the reason my peer review was targeted for deletion by Samourai.
legendary
Activity: 3472
Merit: 10611
Within hours, both bug reports were deleted without comment. Since Samourai does not want to comment on their existence
Have you tried opening similar issues with a different account since it could be possible that Samourai team is removing anything you post specifically because you are a well known Wasabi shill. Tongue

Feel free to report the bug yourself
I'm not a user of this tool nor am I familiar with the code and/or how it works to bother with it...
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
But what software did you use that produced this?  I have never created a dust output like that, but have used whirlpool from sparrow multiple times.

I just used the mempool.space block explorer to find it. Here is another Whirlpool tx0 that created negative value dust 2 days ago, an unmixable change output for 933 sats was created at a cost of 1233 sats - https://mempool.space/tx/caf8893b7d76027e9839d803197781505a4137020a55db742b87e86ccdb899df

As I understand it, participants pay during their entry.  They cannot pay all together, because each one enters in a different time.  It can happen in theory, but it would need to change their entire protocol.

Yes, they should change their entire protocol.  Tx0 is a massive waste of block space.
sr. member
Activity: 364
Merit: 298
Whirlpool coinjoins consist of two transactions.  The traceable change is created from the tx0 premix transaction.  While tx0 is already a huge waste of block space on its own, the change output created here is especially wasteful because it cost the user more in mining fees to create it than it is worth.

But what software did you use that produced this?  I have never created a dust output like that, but have used whirlpool from sparrow multiple times.

A coinjoin contains inputs from multiple users.  In Whirlpool, each user pays the coordinator fee in the tx0 transaction, then coinjoins with other peers in the following transaction.  Since all peers are paying their fees to the same coordinator, they would save block space by pooling their payments into the creation of one output for the entire group as opposed to each participant creating an individual output.

As I understand it, participants pay during their entry.  They cannot pay all together, because each one enters in a different time.  It can happen in theory, but it would need to change their entire protocol.
hero member
Activity: 862
Merit: 662
Thank you for report the bugs, i am going to try to check them.

Transaction fees are as high as 70 sats/vbyte, watch out for bug #1 today, don't lose your sats!

We can use Testnet to try to reproduce what you just said, with testnet we don't waste any real coin.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Transaction fees are as high as 70 sats/vbyte, watch out for bug #1 today, don't lose your sats!
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
This does not seem like a whirlpool transaction.  What software did you use to produce it?

Whirlpool coinjoins consist of two transactions.  The traceable change is created from the tx0 premix transaction.  While tx0 is already a huge waste of block space on its own, the change output created here is especially wasteful because it cost the user more in mining fees to create it than it is worth.

How can you pay their fee without creating a new UTXO?  I did not understand.

A coinjoin contains inputs from multiple users.  In Whirlpool, each user pays the coordinator fee in the tx0 transaction, then coinjoins with other peers in the following transaction.  Since all peers are paying their fees to the same coordinator, they would save block space by pooling their payments into the creation of one output for the entire group as opposed to each participant creating an individual output.
sr. member
Activity: 364
Merit: 298
Issue 461 is the most straightforward: You are spending 305 satoshis to yourself and paying 369 sats mining in fees to do it. There is no privacy benefit from creating this output since it is known to belong to the same owner as the inputs of the transaction.

This does not seem like a whirlpool transaction.  What software did you use to produce it?

Issue 462 appears even more straightforward at first but is actually more nuanced: The coinjoin coordinator is reusing addresses to collect its fees, with one receiving up to 36 incoming payments. While this might seem like an obvious privacy leak that can be fixed with a debug, it's not effective just to rotate the receive address. It would actually require an upgrade to the coinjoin protocol itself to hide the amount paid the coordinator (and save block space) with participant paying their fee directly in a coinjoin and the coordinator mimicking the participants' output size.

They use pools (pool size coinjoins).  How can you pay their fee without creating a new UTXO?  I did not understand.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
While doing research, I ran across two bugs taking place in Samourai's Whirlpool coinjoin protocol that could be spotted with the naked eye.  On October 25th, I opened two Gitlab issues describing the bug with links to the addresses and transactions the behavior occurred under. Within hours, both bug reports were deleted without comment. Since Samourai does not want to comment on their existence, I am publicly disclosing them:

https://web.archive.org/web/20231025112756/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/461
https://web.archive.org/web/20231025112815/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/462

Issue 461 is the most straightforward: You are spending 305 sats to yourself and paying 369 sats in mining fees to do it. There is no privacy benefit from creating this output since it is known to belong to the same owner as the inputs of the transaction.

Issue 462 appears even more straightforward at first but is actually more nuanced: The coinjoin coordinator is reusing addresses to collect its fees, with one receiving up to 36 incoming payments. While this might seem like an obvious privacy leak that can be fixed with a debug, it's not effective just to rotate the receive address. It would actually require an upgrade to the coinjoin protocol itself to hide the amount paid the coordinator (and save block space) with participant paying their fee directly in a coinjoin and the coordinator mimicking the participants' output size.
Pages:
Jump to: