Please don't reuse addresses. Ever. Reply above: #926959

We are on Stacker ;)

Reply above: #926959

Hi there,

for full transparency: Yes, we do.

For those who want some more detail: We block swaps originating from OFAC blacklisted addresses since quite some time already (see #340280), see also 4.17 in https://boltz.exchange/terms. The goal is simple: avoid our users having their swap funds frozen by entities like European or U.S. exchanges.

But precisely this happened over the past couple of days. Turns out ByBit Hack related funds are moving through different Bitcoin rails and caused funds to be flagged and frozen by different regulated exchanges. To counter this, we added the ByBit blacklist (https://dt074px2e9qbh.cloudfront.net/exploit-api.json) in addition to the OFAC blacklist. Goes without saying, that checks against these lists run locally on our server.

So... we are not blocking Bitcoin originating from coinjoins, but if you are participating in a coinjoin round with blacklisted ByBit Hack addresses, then we do. If you intend to use Boltz with coinjoined funds, it's a good idea to investigate about your coordinator a bit beforehand (see e.g. https://x.com/Ziya_Sadr/status/1904683659686215806).

We'd love to see dramatically improved fungibility on Bitcoin and are looking to implement Payjoins to do our (little) part. Particularly excited about the upcoming v3 multiparty version: https://payjoindevkit.org/2025/03/18/the-evolution-of-payjoin/#looking-to-the-future-payjoin-v3

True that

Thx! Stacker should change x.com links automatically ;)

Most common for end users definitely Phoenix wallet, which supports Bolt12 since summer: https://x.com/PhoenixWallet/status/1808547081214439494

It's a good meme!!

Probably more because inbound liquidity is the scarce resource.

Use Bolt12 with blinded paths!

Nice write-up and thanks for the kind words! We are on Stacker too, so just @boltz for questions ✌️

As send to and receive from Lightning within Aqua is powered by Boltz, we are present in their Telegram group and are taking support requests there. But we are not admins.

Thanksss

We had one significant vulnerability pretty early on: https://blog.boltz.exchange/p/the-problem-with-free-options-69f9f59a2d48. But it was never user funds at risk. Just ours :/ Nothing in recent years.

Downtimes: many. Scroll through our twitter and you'll see the pain we went through. Mostly caused by either crashes of our LND e.g. https://nitter.net/Boltzhq/status/1666434127321522185 or planned restarts of our LND node to do the necessary db compaction. Most significant down time in recent history was back in May because we were unprepared for the fee hike see https://nitter.net/Boltzhq/status/1656013583124242437.

We have learned from this a ton, worked a lot to prevent both from causing significant down time again in the future (second CLN node as failover see #339248, also huge work went into automating our liquidity management) and things look a lot better now.

Good question, incredibly difficult topic. We spent many hours debating this in the last months as we grew. Let me try to be very transparent about the outcome:

What? We will "not facilitate swaps involving any of these bitcoin addresses: https://github.com/0xB10C/ofac-sanctioned-digital-currency-addresses/blob/lists/sanctioned_addresses_XBT.txt", 376 as of today. Not more, but also not less.

Why (Short version)? : Because we can't become a tool that is used for serious crime. If we do, we won't make it. And we really want to make it.

Why (Long version)?: Many of our users use Boltz Swaps to increase privacy for very legit use cases, e.g. when depositing or withdrawing from KYCed services like CEXes or as precaution when e.g. moving to cold storage. We will be blocked by these services, the same way many of these services freeze your account if you deposit from addresses that were involved in a mixer/coinjoin. It would render Boltz useless for many of users, while it would help exactly none because we didn't have a single swap involving an OFAC listed address in the past. And anyways most addresses on this list are emptied or otherwise dormant. Also, as we are driving integrations of our API forward, some partners simply require us to be "OFAC compliant" otherwise they can't integrate. Because they are based in the U.S. or otherwise. So far the rational arguments.

I chose to do the risky thing and be blunt. Would love to hear your point of view!

As in Front End? Too many acronyms here on SN ;)

This. It's the only thing we have that is stable and battle-tested. Explorers, wallets (many more to come), dev tooling, even some exchange integrations. It's all there and ready, one just needs to use it. Goes without saying that many things can be improved and goes without saying we'll closely watch Fedi.

It's hard because we want to make these swaps taproot-native right from the beginning to avoid adding a swap type that will be obsolete just a month or two later. So taproot/musig2 is the big thing @michael1011 is currently working on. Liquid<>mainchain swaps itself are very similar to our submarine swaps.

PS: we'll move our existing submarine swaps to native taproot too ✌️

🙏

🙏

Write a song about it :D

Become an LSP (https://github.com/BitcoinAndLightningLayerSpecs/lsp)? Potentially. We have it in our backlog but not a prio rn.

Love it, wen github gist?