Modular Wasabi

[MaxHillebrand]

Currently, the /WalletWasabi/ repo is a behemoth software that has all the different aspects of the projects mingled up together. It seems that a modular architecture is more suitable, both for CoinJoin liquidity, as well as a more stable software project.

I'm not a software architect, so my intuition might be very wrong, and for sure the details that I talk about will not be very accurate. Here I propose a rough division of parts of the software, but mainly to start a conversation if this is useful at all.

Consensus

This is how the software gets information about the timechain. For the Wasabi project and specifically the light client, this is the BIP158 block filters. It also includes P2P communication with other nodes to get blocks and mempool. But this can be replaced by bitcoind binaries directly [for the coordinator], or electum server [if this is already set up] etc.

Wallet

For generating private and public keys, building and signing transactions etc. This talks to Consensus to establish a wallet balance. It also talks to WabiSabi Client for the CoinJoins.

WabiSabi Client

This handles the communication with WabiSabi Coordinator for the CoinJoins. Notice that this works regardless which Consensus or Wallet is used.

WabiSabi Coordinator

The software to coordinate the rounds, it can be run by zkSNACKs or maybe others, and it can use whatever Consensus, but of course should be a fully verifying node.

GUI

The Avalonia stuff that puts Consensus, Wallet, and WabiSabi Client in a pretty UI with the Wasabi look. There could be different GUI versions for power users and a simple n00b version.

RPC

This is for developers who want to work with Consensus, Wallet, and WabiSabi Client, and this is not at all intermingled with the GUI, but totally separate.

Conclusion

I think this would be very useful, especially the WabiSabi Client library, as this allows other wallet developers to use the CoinJoin coordinator [which relies on the network effects] cleanly without inheriting any code debt from the rest of the Wasabi project.

[nopara73]

In my experience modularization/microservices/creating new projects/multiple repos is a terrible nightmare. It's a git hell times 1 million. VERY STRONG NACK. Look at the mess we already started creating with half baked and half abandoned repositories under the zkSNACKs org.

[dangershony]

I have to disagree with you @nopara73 I can't count how many projects I've worked on that make this mistake for lack of time, pressure to deliver, no modular design.

This is something that needs to get more attention from arch , often teams don't plan this and end with a monolithic solution, and before you know it it's almost impossible to break the solution down to more granular components because of too many inter-dependencies and production dependencies.

I agree using different repos is a nightmare (i.e git submodule hell) but you don't have to use different repos for a modular design.

[Kukks]

In my experience modularization/microservices/creating new projects/multiple repos is a terrible nightmare. It's a git hell times 1 million. VERY STRONG NACK. Look at the mess we already started creating with half baked and half abandoned repositories under the zkSNACKs org.

It doesn't have to be a fully blown "everything separated in a million repos with a million projects"

I particularly like the approach that the BitcoinJs payjoin client is shaping into from @junderw & @lukechilds and in your case would unlock greater liquidity and adoption if you provided a "ZeroLinkClient" that could be integrated in other wallets (BTCPay hint hint) without needing a dedicated daemon

[nopara73]

@dangershony When I said "In my experience" I actually meant "In my experience at Stratis." The modularization hell that was created there made the work exponentially more difficult. I can understand the justification of the complexity there though, because the stack was written for developers and not end users, but Wasabi is for end users. I think the most striking example of overengineering there was the plugin system of Breeze wallet. A developer dream feature delivered without any market demand.

@Kukks thanks for bringing this up. This is another argument for why it's a bad idea. If other people start to use our stuff, then we'll have to start providing support and make sure we don't break stuff, which limits future improvements greatly. Plus of course the obvious privacy loss due to having different mixing wallets behaving differently.

In privacy applications, superfluous options are even worse. When there are
many different possible configurations, eavesdroppers and insiders can often tell
users apart by which settings they choose. Anonymity Likes Company

[dangershony]

The complexity of Breeze really backfired no argument there 😃
(though market demand was a totally unrelated problem)

I do agree that wasabi is very purpose built and should stay slim and focused on anonymity only, still you should pay attention to this comment.

It doesn't have to be a fully blown "everything separated in a million repos with a million projects"

[junderw]

I think modularization is one of those things you want to balance.

Too much is bad, too little is also bad.

Too little usually means you can't write any really good tests, since modularization really helps when creating mocks for unit testing.

iirc the reason why bitcoin created libconsensus was because they were trying to minimize people accidentally causing hard fork changes. (though tbh, the 2013 HF bug showed us that almost everything is consensus related... which in this Wasabi protocol a "HF bug" equivalent would be a fingerprint-able difference causing a privacy leak...)

So I agree that trying to modularize libconsensus in bitcoind and the privacy related portions of Wasabi would be a bit like running in place and is a bit of a waste of effort from the perspective of bitcoind / wasabi.

However, there are certain use cases for libconsensus and as long as it isn't "creating another full node implementation" it doesn't cause much harm.

Likewise, completely rejecting the idea of modularization of Wasabi just because you hate modules is not a good idea either.

Everything is balance.

I would NACK this provisionally, but might ACK a specific proposal with work done by some outside group. If it makes maintaining the code easier and testing easier that's a plus everyone.

[MaxHillebrand]

Thanks all for the sparked conversation!

I agree with @nopara73 that because Wasabi is end client software, there is less need for such a hyper modular architecture, and that it might cause more trouble than good.

I also agree with @dangershony that "it's just too much effort" is not really a good argument against the idea - if it's good, it might be worth the time invested.

@junderw, sure, all is trade-offs and balances, and my initial proposal of having Wasabi "fully modular" might be waaay too much.

But as @Kukks says, if at least WabiSabi Client is a modular library, this would be already a huge win, I think. Sure, as @nopara73 says there might be bad privacy wallets [leaking xpub or whatever] that implement WabiSabi Client, and this would ruin the anonset against some attackers. However, if "good privacy wallets" like BTCPay with full node implement it, the privacy loss might be negligible or even non-existent. Further, it would remove the heuristic that "all CoinJoin participants are Wasabi users", and this would add further ambiguity for wallet fingerprinting de-anonymization.

My very initial idea on this whole concept was, that we are already implementing a new CoinJoin protocol, so there is already a lot of effort, and we might as well make it a standalone library, that not just Wasabi but also other wallets can use to communicate with the coordinator. [The full project modularization is an after-thought of this.]

[Kukks]

@dangershony When I said "In my experience" I actually meant "In my experience at Stratis." The modularization hell that was created there made the work exponentially more difficult. I can understand the justification of the complexity there though, because the stack was written for developers and not end users, but Wasabi is for end users. I think the most striking example of overengineering there was the plugin system of Breeze wallet. A developer dream feature delivered without any market demand.

@Kukks thanks for bringing this up. This is another argument for why it's a bad idea. If other people start to use our stuff, then we'll have to start providing support and make sure we don't break stuff, which limits future improvements greatly. Plus of course the obvious privacy loss due to having different mixing wallets behaving differently.

In privacy applications, superfluous options are even worse. When there are
many different possible configurations, eavesdroppers and insiders can often tell
users apart by which settings they choose. Anonymity Likes Company

In terms of privacy loss, I would lean towards the side of caution and reject even the slightest deviation. You need this anyway in case someone modifies the official client and induces privacy losing consequences.

In terms of support, a simple disclaimer saying you do not provide support for anything but the official client is sufficient.

In terms of plugins, yes this is overkill and definitely not worth it here. Structuring the code in modules( even just separate, clean interfaces with implementations) is good in general though. I wish we had more separation in BTCPay, because it is harder to expand and cleanup without stepping on something else.

[nopara73]

IMO this conversation lacks substance and is only happening on the philosophical level which leads to misunderstanding. Based on @junderw's comment a more productive thing would be to discuss specific suggestions one by one instead of "modularization as a whole."

[junderw]

RPC seems like low hanging fruit and would be useful for reuse in external apps without messing with privacy aspects.

I would ACK a good proposal to tease that into a module.