abstract: 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.
Bitcoin’s initial rise was meteroric. As the scaling limit bites, that rise is topping out.
To get continued substantial rises in the value of bitcoin, we have to replace SWIFT and the petrodollar. For future growth, it is medium of exchange time. Without medium of exchange, store of value is running out of puff. China is hoarding gold and the fiat of its major international trading partners. If we can get SWIFT or the petrobitcoin or both, they will hoard bitcoin instead. If we don’t, they won’t.
Obviously seven transactions per second does not cut it. And the lightning network is suffering in the high fee regime. The number of channels is shrinking, not growing. The lightning network is not going to do it unless something is fixed.
The obvious fix is for the lightning channel problem is liquid lighting, because channel establishment fees on liquid lightning are low, and channel establishment and teardown is fast. But the genuinely self custodial liquid lightning wallet, on which all the semi custodial and central custody liquid lightning wallets depend, has almost unusable software which only runs natively on one particular version of linux. No one is using liquid lightning, in part because the software is unusable, in part because of Metcalfe’s law and the cold start problem, because no one else is using liquid lightning.
Liquid lightning in theory has the capability to atomically exchange between liquid lightning, regular bitcoin lightning, and tether lightning. But tether lightning does not seem to actually exist, and the theoretical atomic interchange capability is useless without a dex to do it, not to mention an actually useful liquid lightning wallet.
We need a lightning wallet where a normie will find himself safely running a full routing lightning node, without needing to invest any significant thought, effort or care, without needing to know anything about running a full routing lightning node, and without needing to make any decisions other than clicking OK when his wallet asks for permission to set up or tear down channels.
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 of bitcoin 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 expect 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 work.
The trouble with the existing non custodial liquid lightning wallet is that it is substantially written in python, and therefore the install is appallingly difficult, an arcane emulation of the development environment under which it was written, and portability to slightly different versions of linux, let alone windows, ios, and android, nonexistent. We need rust lightning. And we need a profit model that pays people to write it.
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 – a text that can contain money.
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 guy’s 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.
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 of the things that can come up in one of the wallets is a human readable bill, similar to a supermarket receipt or an Ebay shopping cart 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 chat app and a browser 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 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 someone else has power over your money and transactions, 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.
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 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 watchtowers 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.
Everyone is using custodial lightning, in part because it is very hard to get incoming liquidty if you create a self custodial wallet. Not to mention that everything about a self custodial lightning wallet is very hard.
At present the only way to create channels is to create a unilateral single channel with zero incoming liquidity. Creating incoming liquidity is very hard, almost impossible. You have to hope that someone else will unilterally initiate a channel to you, in which case you have all incoming liquidity in that channel and no outgoing liquidity, and he has all outcoing liquidity in the channel and zero incoming liquidity. And unless you are already a major routing node with lots of incoming and outgoing liquidity no one is going to unilaterally initiate a channel to you.
A channel is a shared utxo on the basechain. It needs to be possible to create a polygon channel.
For example six self custodial wallets create a transaction on the base chain that creates six channel outputs and six change outputs – the wallets are the vertices (corners) of a six sided polygon, a hexagon, and the channels are the edges (sides) of a six sided polygon, the sides of the hexagon. Each channel has half incoming liquidity, and half outgoing liquidity.
The transaction either succeeds completely for everyone, or if one of the participants fails or backs out for some reason, fails for everyone, costing no one any money, because the base layer enforces atomicity.
Everyone gets two new channels, and each channel is initially half full and half empty, with equal outgoing and incoming liquidity.
As well as making liquidty easy and automatic, no longer requiring thought, effort, knowledge strategy, and tactics, it also is a massive inprovement in privacy, since blockchain analysis can no longer reveal the connection between a KYC input and a channel. The larger the number of participants, the greater the privacy, though with fifty or so participants, the likelihood that the transaction will fail becomes inconveniently large.
The more the particpants, the more the privacy, also the more useful the liquidity provided by half empty and half full channels. Big many sided polygons are more useful than small polygons unless they are so big the transaction is likely to fail to complete. Also big taproot transactions are cheaper per participant, because they store less information per participant on the blockchain. So channel creation is cheaper, though channel teardown will cost the same. (Except that taproot channels are considerably cheaper to tear down than the older P2SH channels that lightning is still using.)
If we implement PTLC lightning transactions, these are fully onion wrapped, so no one can tell who you are transacting with, nor what you are communicating with them about. We will have the privacy Satoshi hoped for, and failed to provide.
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.
such as between bitcoin, and stablecoins representing wrapped local fiat, are possible if the lightning network uses point locked contracts, as some lightning developers have been advocating for many years. Point locked contracts were impossible when lightning was written, but taproot has made them possible. Lightning – and indeed everything – should use taproot. Taproot has obsoleted existing lightning contracts and it is well past time for an update.
Any lightning network on one blockchain can in principle do atomic lightning exchanges with a lightning network on another blockchain if both blockchains support Schnorr signatures and both lightning networks employ point locked contracts, but this is 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.
At present, lightning transactions are hash locked, which makes contracts over lightning difficult, and thus conversions difficult without a trusted third party. For four years some developers have been advocating point locks, which would make enable many lightning applications – dollar lightning to bitcoin lightning to peso lightning among them.
The liquid lightning network already supports atomic swaps between tether, a US dollar stablecoin, liquid lightning, and bitcoin lightning, but the software is such that this is not likely many people are going to use it. One can, with some effort and linux administration skills, atomically swap bitcoin lightning for liquid lightning, then liquid lightning for tether, today. These capabilities need to have go on the bitcoin lightning blockchain, and be given an interface more suitable for normies.
reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.