48 lines
5.6 KiB
Markdown
48 lines
5.6 KiB
Markdown
|
---
|
||
|
|
lang: en
|
||
|
|
title: How to do lightning right
|
||
|
|
---
|
||
|
|
|
||
|
|
::: 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 increate 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. Go and typescript 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 sreceipt 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 leakes huge amounts of metatdata. 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.
|
||
|
|
|
||
|
|
# 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 has 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. For full interopability, all blockchains should support Schnor signatures on the Ristretto elliptic curve.
|
||
|
|
|
||
|
|
Until every lightning nework 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. This creates a big risk of inadvertently allowing dupe attacks, analogous to the Monero dupe attack. To avoid dupe attacks that take advantage of curve factors, the signatures have to be correctly clamped, and clamping difference signatures is a bitch, and easy to do wrong. Life is a whole lot simpler and safer with a prime curve, such as Ristretto.
|