Improve Liquid SDK privacy and enable use as a pure client library

[tanx]

I‘ve spoken with Roy on Wednesday and we had a productive conversation about Liquid SDK privacy, specifically in case developers want to use the SDK purely as a client side library. This is desirable for developers and end users for reasons that I will outline below. Roy asked me to create a GitHub issue to lay out my suggestions for a future PR. So here goes…

First of all thank you for your work on Breez Liquid SDK. It has dramatically improved the time-to-market for lightning self-custody products and I believe we have yet to see the potential that this library will have on the broader bitcoin ecosystem. Even if wallet developers decide to chose another UTXO sharing model like ECash or Ark, the bar has been set as to what the developer UX looks like: “npm install” then call send/receive apis for Lightning or Onchain.

However, due to Liquid low ball fees being only accessible to Liquid Federation members, Breez currently runs a managed electrum server for SDK users. This gives users lower fees and allows developers to quickly spin up a proof-of-concept for an app or business idea and get validation from the market quickly. These servers were instrumental in allowing me to build and ship StashPay in a matter of weeks. In order to mitigate DDoS attacks against the electrum server, Breez requires signing up for an api-key. The api-key was initially not required in the first release of the SDK and this was advertised as an advantage over the Greenlight/LSP version of the SDK. Of course the lack of low ball fees also meant paying higher fees for direct Liquid transactions for end users. But it was at least possible to use the SDK without an api-key. This has recently changed. The npm module now throws an error and does not allow initialization if no valid api-key is provided in the config.

I want to highlight how important the lack of an api-key was for me to choose Breez Liquid SDK for StashPay. Not only does the lack of an api-key prevent vendor lock-in, it is also crucial for end user privacy since their Liquid transactions could be correlated to a specific wallet vendor if Breez decided to log user transactions based on api-keys and match this data with other third party data like Boltz submarine swaps (which to my understanding Breez currently does not).

The question also presents itself what business incentives wallet developers have to share this data with Breez? Developers are incentivized to act in their users’ best interest and compete in terms of privacy (among other features). Furthermore, it’s unclear whether this link between wallet vendors and user transactions poses a potential legal risk to self-custody developers in the future, should the regulatory landscape change. And even if Breez does not log this data now, how do developers verify that Breez won’t log in the future?

Luckily, Liquid low ball fees will soon be replaced with Discount-CT which will be available to everyone running an electrum server, not just Liquid Federation members. It’s my understanding that Discount-CT will be released on the Liquid Network around the end of 2024 (realistically Q1 2025). Once it does, using Breez‘s electrum/esplora server is no longer required from a technical standpoint. Developers using Liquid SDK could choose to host their own electrum server or allow users to configure any electrum server that does not require an api-key (even user self-hosted ones). But since the Liquid SDK currently does client-side validation of the breez-api-key in the npm module, using the SDK purely as a client-side library would still require signing up with Breez. IMHO that engagement and sharing of user data should be optional for an open source bitcoin wallet library. So I propose the following changes:

1. Remove client-side validation of the breez-api-key
2. Allow configuration of all hard-coded Breez URLs in the config object. The current Breez URLs can be preset in the default config.
3. The Boltz api URL should be set directly in the config, not via the Breez proxy
4. Allow configuration of the esplora server that broadcasts liquid transactions
5. Allow configuration of this constant … not sure what it does?

These changes would be very minor in nature and still allow developers to use Breez Liquid SDK in „managed mode“ with preconfigured Breez servers and the api-key to get started quickly. But it would also allow developers to use the SDK purely as an open source library and choose any backend services on the open market.

If privacy focused use cases like these require ongoing maintenance, perhaps I can apply for grant funding. As I’m not as deep in the code base or Rust as you. So please let me know what you guys prefer.

And thank you again to Roy and the Breez team to listening to my concerns. I deeply appreciate our shared commitment to privacy and supporting external open source contributions.