8.1 KiB
| lang | title | sidebar | notmine |
|---|---|---|---|
| en | How to do lightning right | false | false |
::: myabstract [abstract:]{.bigbold} Lightning is about to replace SWIFT for international transactions, due to high SWIFT fees, slow transactions, and the disruptive weaponization of SWIFT in imperial wars. It is already taking a significant bite out of SWIFT, which is likely to very soon become an enormous bite. This will immensely increase the value of Bitcoin. But lightning is very hard to use. :::
Lightning software still sucks appallingly. Nice solutions are centralized and custodial. Mutiny wallet and electrum is non custodial, but their profit model that made it possible to pay people to produce nice software relies on rather more quiet centralization that is admitted.
Someone who owns a lot more bitcoin than I do should fund development of a lightning wallet done right in order to increase the value of Bitcoin.
The easiest and fastest way to bring up software that only runs on your computer and whose cpu and memory cost is insignificant compared to development cost is python. Unfortunately if you want thousands of people to run this software, you wind up using snap, docker, or appimage to run an emulation of your development system, and you don't get the benefits of open source because it is too hard for other people to bring up a development system that emulates your system exactly. Python software is just not suitable for a program that you expects thousands and eventually hundreds of millions of people to use. An open source program intended for deployment on an enormous scale has to be C, C++, or rust. Typescript and Go also works. We need rust lightning. And we need a profit model that pays people to write it.
Lightning transactions are hard on the end user
At present, making a lightning payment is just too hard for normies.
The gui should support true end to end encrypted human messages between lightning peers, which should be as easy as sending a text from a phone.
in person
The way an in person lightning payment should work is that you touch phones, and it sends a message by NFC, or you scan a QR code displayed on the other guys phone, and up comes a human readable bill on your phone that will typically look something like a supermarket receipt, you click OK, and after a second or two both phones show the bill paid. And both phones record the human readable receipt forever.
over distance
You click on a link, which can be a link in the browser, which brings up not a browser page, but your wallet gui, and which causes your lightning wallet to initiate end to end encrypted communications (using its own private key and the other wallet's public key, not certificate authority https keys, using lightning channels, not web channels) with the wallet that created that link, and human readable text should appear in your wallet from that other wallet, human readable text containing buttons, buttons that cause events in the wallet, not in the browser. And one the things that can come up in one of the wallets is a bill with an OK button.
And anyone you have a channel with, or have made a payment to, or received a payment from, should be automatically buddy listed in your wallet, so that he can send you wallet to wallet end-to-end encrypted messages. You will probably get wallet spam from people you have purchased stuff from, so you will need a spam button to unbuddy them.
The wallet should be a browser and chat app that can send and receive money -- a Nostr specialized for medium of exchange and two party private conversations.
Mutiny wallet and Alby are Nostr bitcoin lightning wallets, but they are not specialized for lightning end to end private two party chat and private human conversations about money. (Which will typically consist only of an RFP, a bill, and a receipt.) And they do their communications over https, which leaks huge amounts of metadata. Far too many people have an unhealthy interest in other people's metadata about money. Human communications about money should go over the lightning network to reduce loss of metadata about money.
backup
Backup of your lightning network is broken, unless you are merely the client of some big node. We need to be able to restore from the master secret, the seed phrase, alone.
The big point and big value proposition of cryptocurrency is that you don’t have to suffer client status, with all its grave costs, dangers, and inconveniences. It is client status that is the problem that bitcoin was originally created to fix.
To recover your lightning wallet you need both the master secret and the current state of your lightning wallet. Which you probably lost in the crash. Backups will not work, because the state of your lightning wallet, unless you are a mere client of a single important node, is likely to change frequently and unpredictably. The current backup solutions are a collection of complicated half assed workarounds which are likely to mostly work most of the time, provided you know who all your channel counterparties are, they are still around, and they are honest, well behaved, and well intentioned.
the solution to restore from seed
is watchtowers plus some new functionality.
A watchtower receives (almost) all the data you need to restore a channel. Why then, not all? The stuff that they do not need to know, send encrypted so that only the possessor of the master secret, the seed phrase, can read it. and have at least one watchtower for every channel, plus each watchtower gets, encrypted, a list of some of the other watchowers, so that if you can find one watchtower from seed phrase, you can find them all.
So, if Bob’s wallet goes up in flames, and he has to restore from seed, he has to find one of the watchtowers that was watching his channels. We store that data on a DHT, so that the wallet can find the DHT key to its lists of watchtowers from its seed phrase. It finds the watchtower whose key is closest to key derived from its seed phrase, and that watchtower keeps a collection of lists of watchtowers, encrypted so that it cannot read it. We implement DHT reciprocal storing incentives. If you want to be sure other people's watchtowers keep your list, better make sure your watchtowers keep other people's lists.
So the way it should work is that is that whenever Bob sets up a channel with Dave, they agree to set up a couple of watchtowers for a couple of other channels — Dave sets up a couple of watch towers to watch a couple of Bob’s other channels, and Bob sets up a couple of watchtowers to watch a couple of Dave’s other channels. And from time to time Bob sends to the watchtowers watching his channels a list of watchtowers watching his channels, in encrypted form so that the watchtower cannot read it, but Bob can.
And now you have a lightning wallet that can be restored from a paper wallet.
Then if your lightning wallet crashes, you could recreate it from your master secret, your seed phrase, by re-running all the state changes of each channel from the beginning.
end users want their local fiat
We want one person to be able to send dollars and the recipient receive pesos, and invisibly to either human user, the dollars turn into bitcoin, and the bitcoin turns into pesos.
atomic transactions between blockchains
such as between bitcoin, and stablecoins representing wrapped local fiat.
Any lightning network on one blockchain can in principle do atomic lightning exchanges with a lightning nework on another blockchain if both blockchains support Schnorr signatures, but this extremely difficult if they use different signature algorithms, because differences in signature algorithms obstruct scriptless scripts. and an advanced research topic in elliptic curve cryptography if they use non prime elliptic curves.
Until every lightning network supports Schnorr Ristretto, getting the cryptography to work between lightning networks on different blockchains is going to be hard. If you look at any explanation of how scriptless scripts and difference signatures work, the explanation implicitly presupposes a prime elliptic curve, but the actual implementation somehow has to be done on a nonprime curve.