Closed my Revolut account earlier this year, seems like I was a bit too late.
Who am I kidding, they're all exactly the same.
i did this a few years ago, but i should update it: "What have you used Lightning to buy?". My answer is now: "drinks at bars/events, food (dinner) including sharing the bill with other people, hotel rooms, flights, cellphone bills (both the normal type and esims), electricity bills, water bills, internet bills, taxis, takeaways, groceries (last 3 via gift cards) VPS, VPN, charity donations, trades with friends (usually for USD cash), topping up a debit card, payment for nostr relays, zaps on nostr and LLM model tokens." Probably missed a good few miscellaneous 'buy a thing', but that covers a lot. I have to go via bitrefill for a couple of these, especially internet and electricity bills (in El Salvador; which is also where I got the debit card I can top up with Lightning).
I should also say that 'flights and hotels' being higher cost items, are almost always with btc mainchain or via some other method, but I think I used lightning once or twice here (and will always choose it if I can!). And lastly I should say that having done this for years, with a *self custodial wallet* (I used Electrum a bit but I mostly used Phoenix), I basically *never* have payment routing failures, that used to happen all the time pre-2023.
But apparently I'm all alone because nobody uses Lightning.
Reflections on the Liquid hack.
Take it at different layers:
1/ A central point of failure, even if distributed, holding everyone's funds makes it a brittle design. True. Obviously no nuance there, but it's the first guiding point. It's the reason it's always been way less interesting than a decentralized sidechain would be.
2/ Let's not forget that they *had a whitelist system for exits*. As in, you could not independently peg out, you had to go through a trusted intermediary. This is somehow a failure in 2 opposite directions: it removes reasonable claims of censorship resistance, but, when it came down to it, they also *completely failed to censor* a transaction that no reasonable human-in-the-loop would allow. It's practically a terrible failure, but the whole shape of this problem follows from 1/ so it can never be fully eradicated/corrected.
3/ The software bug was not actually about the cryptography/privacy feature (but wait for 4/ !). It was a logic error in the way that rangeproofs (you can think of them how you think of signatures in normal bitcoin: a little blob of data that proves the transaction is valid) were stored and accessed. it's normal to cache things in software like this that has a significant performance requirement: even simple things like hash functions that are fast. Normal, but of course, it has to be done super carefully (e.g. they have a signature cache in Bitcoin Core) to avoid accepting signatures, rangeproofs and similar, that aren't actually valid. It *was* "just" a software bug, a subtle and tricky one that was easy to miss.
4/ ... Whether 3/ is fair or not as a characterization, here's a surprising feature that *is* absolutely dependent on the cryptography/privacy feature: the *effect* of the bug. Now, it's true that there are non-crypto ways to have catastrophic balance errors, like the 2010 bug in bitcoin that allowed someone to print billions of btc. but not only are they easier if you put the balance arithmetic behind a cryptographic blinding, but they're also easier to be invisible (in Liquid's case, only until you peg out, of course). But it was the crypto structure that allowed this cache hit error to turn into a complete wipeout; if you had some egregious error in signature caching in vanilla bitcoin, I think the worst that can happen is you can steal someone else's money, *not* create bitcoin out of thin air, **because balance checking is not dependent on cryptography, only arithmetic**.
5/ This last one is more in the weeds: as per 3/ caching makes sense because the verifier's computation of the validity of a rangeproof is not free. In fact, this is something specific to bulletproofs as a ZKP: the efficiency of its 'bandwidth' (what has to be sent over the wire; which is also, for a blockchain application, what has to go onchain) comes from essentially folding up the proof's multiple layers into one. the downside is that the verifier has to 'unroll the loop': they have a computational cost linear in the size of the statement. All that's to say, rangeproof verifications are not too efficient. In a different type of ZKP, such as a Groth16 SNARK, the cost of verification is O(1), that is, constant. But that is just not possible on Bitcoin or on bitcoin's EC curve.
