lontivero
3w ago
I want to put a Wasabi coordinator in each Wasabi client and allow users to decide whether they want to act as coordinators or not.
Currently, a WabiSabi coordinator only requires:
* The gettxout RPC call to verify that inputs being registered are unspent and mature
* A mining fee rate provider to determine how much each input/output should pay to the network
These requirements can be satisfied even by a pruned Bitcoin node and don't present any obstacles.
In an ideal world, each coordinator would announce itself (for example, as an onion service), and then clients could agree on which coordinator to connect to for the next CoinJoin round. However, in the real world, malicious actors could create hundreds or thousands of onion services to maximize their chances of being selected.
Is there any way to solve this coordinator selection problem without creating a centralized directory of coordinators?
@waxwing any suggestion to read?
Currently, a WabiSabi coordinator only requires:
* The gettxout RPC call to verify that inputs being registered are unspent and mature
* A mining fee rate provider to determine how much each input/output should pay to the network
These requirements can be satisfied even by a pruned Bitcoin node and don't present any obstacles.
In an ideal world, each coordinator would announce itself (for example, as an onion service), and then clients could agree on which coordinator to connect to for the next CoinJoin round. However, in the real world, malicious actors could create hundreds or thousands of onion services to maximize their chances of being selected.
Is there any way to solve this coordinator selection problem without creating a centralized directory of coordinators?
@waxwing any suggestion to read?
See translation
15
16
3
0
105
Replies
Rizful.com (zap tester)
@Rizful.com (zap tester)
2w ago
Testing zap receipts for this note… we made six attempts to⚡zap this note, at lontivero@stacker.news, over a period of 28 minutes. Six of the zaps were successfully paid... Please check for 6 satoshis received. Problem: we found that your lightning address server **did not** produce any zap receipts. This means that nobody else could see see that you got zapped... no number appears next to the ⚡icon after zapping.... We recommend that you use a cloud-based Lightning node to get more reliable zaps.
See translation
0
0
0
0
0
waxwing
@waxwing
3w ago
My reading suggestion is, read this :)
The reason a fidelity bond is a reasonable suggestion is that we need to impose some cost or scarcity to prevent an attacker creating 100k Sybil agents as potential coordinators. I'm assuming you don't use any kind of trust or public identity behind the process of advertising yourself as a potential coordinator.
Why a fidelity bond vs some kind of more "high tech" thing like a podle commitment, a ring signature or an aut-ct token (think of it like a ring sig but you can get 1M anon set instead of 500-1k)? Because while privacy is important here, cost imposition should also be high. Something like aut-ct is good for rate limiting (I don't want a burst of 100k requests in 1 minute) with super-high privacy, but it doesn't impose any really significant cost on an individual user. A
The reason a fidelity bond is a reasonable suggestion is that we need to impose some cost or scarcity to prevent an attacker creating 100k Sybil agents as potential coordinators. I'm assuming you don't use any kind of trust or public identity behind the process of advertising yourself as a potential coordinator.
Why a fidelity bond vs some kind of more "high tech" thing like a podle commitment, a ring signature or an aut-ct token (think of it like a ring sig but you can get 1M anon set instead of 500-1k)? Because while privacy is important here, cost imposition should also be high. Something like aut-ct is good for rate limiting (I don't want a burst of 100k requests in 1 minute) with super-high privacy, but it doesn't impose any really significant cost on an individual user. A
... See more
See translation
0
0
0
0
0
lontivero
@lontivero
3w ago
I'm not sure is avoiding trust should be enforced because some cusers could prefer to configure the client to participate in round only with some very specific coordinators and avoid all others. The coordinator identity could be the onion address and if well a coordinator could have multiple addresses, one onion address identifies one and only one coordinator.
I started reading about fidelity bonds because I knew about them but never went deep in my understanding. I think I will have a better idea today, however the problem of calculating the cost of the bond is clear and there seems to be not easily solvable if it is.
I will search in the joinmarket repo for the "directory nodes" idea but yes, your concerns are valid. In the case of DoS attacks we already have the problem because we the same utxo you can already disrupt
I started reading about fidelity bonds because I knew about them but never went deep in my understanding. I think I will have a better idea today, however the problem of calculating the cost of the bond is clear and there seems to be not easily solvable if it is.
I will search in the joinmarket repo for the "directory nodes" idea but yes, your concerns are valid. In the case of DoS attacks we already have the problem because we the same utxo you can already disrupt
... See more
See translation
0
0
0
0
0
waxwing
@waxwing
3w ago
Yeah it's really complex isn't it. And for fidelity bonds read Chris' old gist on the mathematics of fidelity bonds.
See translation
0
0
0
0
0
Dan Gould
@bitgould
3w ago
Is the availability of coordinators a constraint on adoption? I can’t remember any extended time when no coordinators were online.
See translation
0
0
0
0
0
lontivero
@lontivero
3w ago
Availability is not a problem, until it is. Right now there are three public coordinators that could be compromised, attacked or shut down. Even when I am sure new coordinators would pop up in case of mayor disruptions, and I am also sure liquidity will eventually find its way to the next coordinator, the process is slow and painful because requires users to choose a new coordinator.
Running a coordinator in each Wasabi client would make the whole system more resistant and would remove the easy targets by distributing the load of coordinating transactions.
Running a coordinator in each Wasabi client would make the whole system more resistant and would remove the easy targets by distributing the load of coordinating transactions.
See translation
0
0
0
0
0
Dan Gould
@bitgould
3w ago
No doubt making clients potential coordinators is a step toward better decentralization. But that’s not my question, which is: is lack of coordinator decentralization preventing people from using wasabi who otherwise would?
See translation
0
0
0
0
0
lontivero
@lontivero
3w ago
I think so, yes. Because the lack of coordinator decentralization ruins the UX by forcing users to research how the whole thing works, find a coordinator and configure the client to use it. Having decentralized coordinators would allow us to select the coordinator for the next round automatically making the feature immediately available after Wasabi installation for everyone.
See translation
0
0
0
0
0
waxwing
@waxwing
3w ago
Why don't you select randomly already? If it's because you don't feel it's appropriate to give implicit trust to the coordinators, I understand that, but then surely that wouldn't change if it was decentralized?
See translation
0
0
0
0
0
01 more reply(ies)
joe
@joe
3w ago
The differences between wasabi and joinmarket are becoming more subtle.
See translation
0
0
0
0
0
ODELL
@ODELL
3w ago
fidelity bonds?
See translation
0
0
0
0
0
lontivero
@lontivero
3w ago
I need to read more about that. I understand the main idea but I'm not sure to understand how that can help to select the coordinator for the next round. Anyway, yes, this is a good starting point.
See translation
0
0
0
0
0
bootlace
@bootlace
3w ago
Out of band web of trust?
See translation
0
0
0
0
0
lontivero
@lontivero
3w ago
For those who want to use a model of trust like that we are already distributing the coordinator as part of the Debian package and it is installed and available when you install Wasabi so, the only thing you need to do is to execute the `wcoordinator` and that's it. Then your community can use your coordinator.
See translation
0
0
0
0
0