Wasabist.IO - Wasabi Wallet Coordinator & Explorer

[hugeblack]

Can you add any features to ensure that it is difficult to repeat what happened with WasabiCoordinator.IO, such as placing a warning label on any Coordinator that has Minimum Inputs less than 10 or a short Round Time, or tracking whether the fees are real or may be tampered with?

Thanks for the continued development, the project is good, I will put a super bump on it.

[examplens]

Can you add any features to ensure that it is difficult to repeat what happened with WasabiCoordinator.IO, such as placing a warning label on any Coordinator that has Minimum Inputs less than 10 or a short Round Time, or tracking whether the fees are real or may be tampered with?

Thanks for the continued development, the project is good, I will put a super bump on it.

The Wasabi Wallet team took care of it, they reacted very quickly with the new update.

Yesterday, we were informed that the "wasabicoordinator.io" coordinator was using suspicious parameters, including requiring only 2 inputs, creating rounds as quickly as possible, and charging the maximum allowable coordination fee. This also involved changing the fee after a round failure. We confirmed that the wasabicoordinator.io coordinator was indeed exploiting the vulnerability our team had been addressing.

Exploiting this vulnerability requires not just configuration or DevOps knowledge, but a deep understanding of the coinjoin protocol. We aim to release an update within hours to address this issue.

Thanks to community-developed monitoring systems, this exploit was detected relatively quickly. We communicated about it to minimize impact and advise users to pause coinjoining. Subsequently, we swiftly released version 2.1.0, which prevents similar attacks.

https://github.com/WalletWasabi/WalletWasabi/discussions/13249

[Wasabist.IO]

Can you add any features to ensure that it is difficult to repeat what happened with WasabiCoordinator.IO, such as placing a warning label on any Coordinator that has Minimum Inputs less than 10 or a short Round Time, or tracking whether the fees are real or may be tampered with?

Thanks for the continued development, the project is good, I will put a super bump on it.

AFAIK problem is fixed by WW team, short round time is not a malicious behavior if inputs count is enough and now minimal inputs count can be set in wallet. There is nothing to do, everything done by WW team.

[JeromeTash]

Can you add any features to ensure that it is difficult to repeat what happened with WasabiCoordinator.IO, such as placing a warning label on any Coordinator that has Minimum Inputs less than 10 or a short Round Time, or tracking whether the fees are real or may be tampered with?

Thanks for the continued development, the project is good, I will put a super bump on it.

AFAIK problem is fixed by WW team, short round time is not a malicious behavior if inputs count is enough and now minimal inputs count can be set in wallet. There is nothing to do, everything done by WW team.

How about this suggestion.

You add a section for those coordinators that have gone rogue and maybe their current status (active or inactive) just to keep track of them and also help warn other new users about the coordinator that can not be trusted.

[Wasabist.IO]

Can you add any features to ensure that it is difficult to repeat what happened with WasabiCoordinator.IO, such as placing a warning label on any Coordinator that has Minimum Inputs less than 10 or a short Round Time, or tracking whether the fees are real or may be tampered with?

Thanks for the continued development, the project is good, I will put a super bump on it.

AFAIK problem is fixed by WW team, short round time is not a malicious behavior if inputs count is enough and now minimal inputs count can be set in wallet. There is nothing to do, everything done by WW team.

How about this suggestion.

You add a section for those coordinators that have gone rogue and maybe their current status (active or inactive) just to keep track of them and also help warn other new users about the coordinator that can not be trusted.

Lets give a chain analysis companies a chance to do their work , i'm listing only good coordinators. And as exploit fixed by ww team there is no rogues anymore.
BTW i've published a new update, now you can see remixed/new coins on the coordinator page.

[Wasabist.IO]

Finally launched my own coordinator!
It's a bit different from other ones. Fees are completely random, from 0.01% up to 0.1%. Round time is also random.
After each round winner is calculated and half of round fee going to him. You can coinjoin and even earn during this process.
Connect by copying URI:

name=WASABIST.IO+%7C+UNIQUE+COORDINATOR+%7C+COINJOIN+AND+EARN+%7C+READ+MORE+ON+OUR+SITE&network=main&coordinatorUri=https%3A%2F%2Fwasabist.io%2F&coordinationFeeRate=0.001&readMore=https%3A%2F%2Fwasabist.io%2F15&absoluteMinInputCount=25

Read more: https://wasabist.io/15

[Wasabist.IO]

I have updated the Coordinator to now provide a "Proof of Honesty" for our gambling option.

Link to coordinator page: https://wasabist.io/15
URI for connection:

name=WASABIST.IO+%7C+UNIQUE+COORDINATOR+%7C+COINJOIN+AND+EARN+%7C+READ+MORE+ON+OUR+SITE&network=main&coordinatorUri=https%3A%2F%2Fwasabist.io%2F&coordinationFeeRate=0.001&readMore=https%3A%2F%2Fwasabist.io%2F15&absoluteMinInputCount=25

or simply visit https://wasabist.io and press on "Connect" button for more information.

How it works now:

• Each round generates a SHA-256 hash and publishes it after the round starts.
• After the round ends, Coordinator publishes the winning number, winner’s address, and winner’s salt. (https://i.imgur.com/qO9a01e.png)
• You can verify the hash using this pseudocode: base64_decode(winner_hash) === sha256(winner_number . winner_salt)
• The winner is determined using confidence intervals after sorting the address list alphabetically (A-Z), after this i use winner_number to determine the winner and provide.
• The winner will receive the reward in the next successful round! This change is necessary because if the winner received the reward in the current round, it would be shown during the Signing phase, allowing someone to track this data and sabotage the round if he is not the winner. (https://i.imgur.com/RLoNfDI.png)

To make this process clearer, the wasabist.io explorer now provides all this information for our Coordinator.
For example: https://wasabist.io/15/9f6cb303df8fca33aa099b3b6155d452f878fabdd89213cb1a7e83c11bed4b9c

Also some UI improvements have been made and light theme has been added.

[Kruw]

How it works now:

• Each round generates a SHA-256 hash and publishes it after the round starts.
• After the round ends, Coordinator publishes the winning number, winner’s address, and winner’s salt. (https://i.imgur.com/qO9a01e.png)
• You can verify the hash using this pseudocode: base64_decode(winner_hash) === sha256(winner_number . winner_salt)
• The winner is determined using confidence intervals after sorting the address list alphabetically (A-Z), after this i use winner_number to determine the winner and provide.
• The winner will receive the reward in the next successful round! This change is necessary because if the winner received the reward in the current round, it would be shown during the Signing phase, allowing someone to track this data and sabotage the round if he is not the winner. (https://i.imgur.com/RLoNfDI.png)

Cool! I don't quite understand sorting the address list alphabetically, shouldn't the sorting be based on value of the output created by each address?

Sending the reward in the next successful round is a nice solution to the problem of players cheating. But if 50% of fees are sent to the winner, then Round B always needs to collect at least half of the fee that round A collected.

[Wasabist.IO]

How it works now:

• Each round generates a SHA-256 hash and publishes it after the round starts.
• After the round ends, Coordinator publishes the winning number, winner’s address, and winner’s salt. (https://i.imgur.com/qO9a01e.png)
• You can verify the hash using this pseudocode: base64_decode(winner_hash) === sha256(winner_number . winner_salt)
• The winner is determined using confidence intervals after sorting the address list alphabetically (A-Z), after this i use winner_number to determine the winner and provide.
• The winner will receive the reward in the next successful round! This change is necessary because if the winner received the reward in the current round, it would be shown during the Signing phase, allowing someone to track this data and sabotage the round if he is not the winner. (https://i.imgur.com/RLoNfDI.png)

Cool! I don't quite understand sorting the address list alphabetically, shouldn't the sorting be based on value of the output created by each address?

Sending the reward in the next successful round is a nice solution to the problem of players cheating. But if 50% of fees are sent to the winner, then Round B always needs to collect at least half of the fee that round A collected.

I can't sort by amount because the amounts are often the same. If you're viewing any other coordinator the sorting is by amount. In my case, sorting is by A-Z because this is the only way to achieve a verifiable result for an external observer using the hash that I publish. This has no impact on the result because the method of confidence intervals relies solely on the amounts.

Regarding fees - the winner receives the reward for the next round, meaning it can even be higher in fees than the round in which they won. There are no guarantees that they will receive a specific amount; it works as I intended.

[molnardavid84]

Wasabi has silently broken compatibility with non-free coordinators since the last release v2.0.9 by removing the free remix and friends don't pay feature. If you see "IncorrectRequestedAmountCredentials" exceptions on the client side, it is because of this. The coordinator fee will be completely removed with the next release - https://github.com/WalletWasabi/WalletWasabi/pull/13297#issuecomment-2283555140. The last Wasabi version that is working properly with non-free coordinators was v2.8.0.1.

[dkbit98]

Wasabi has silently broken compatibility with non-free coordinators since the last release v2.0.9 by removing the free remix and friends don't pay feature. If you see "IncorrectRequestedAmountCredentials" exceptions on the client side, it is because of this. The coordinator fee will be completely removed with the next release

Get ready for much more drastic updates soon that will kill most active coordinators and force everyone to switch to ginger fork that works only with ''approved'' pro-censorship fed coordinators.
It looks like last days for scammers who are lying everyone that they are magically making bitcoin anonymous  

[molnardavid84]

Wasabi has silently broken compatibility with non-free coordinators since the last release v2.0.9 by removing the free remix and friends don't pay feature. If you see "IncorrectRequestedAmountCredentials" exceptions on the client side, it is because of this. The coordinator fee will be completely removed with the next release

Get ready for much more drastic updates soon that will kill most active coordinators and force everyone to switch to ginger fork that works only with ''approved'' pro-censorship fed coordinators.
It looks like last days for scammers who are lying everyone that they are magically making bitcoin anonymous  

You're mistaken. The effect is the opposite. The most active free coordinators will get most of the users. The coordinator market will shrink. There is no such thing as a "fed coordinator" - it would not make any sense. If you know anything about Wasabi (Zero-Link, WabiSabi), you would know that the coordinator is not able to extract any information even if they wanted to. If you want a real discussion, be concrete and avoid talking in riddles, what updates? which scammers? who is everyone? where is the lie and who lied?