cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

modified: docs/manifesto/lightning.md

Browse Source
This commit is contained in:
reaction.la 2024-05-07 09:20:10 +00:00
parent a37e40ab7a
commit a10790026a
No known key found for this signature in database
1 changed files with 66 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
docs/manifesto/lightning.md
View File

@ -1,18 +1,21 @@
---
lang: en
title: How to do lightning right
title: >-
How to do lightning right
sidebar: false
notmine: 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 increate the value of Bitcoin. But lightning is very hard to use.
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.
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.
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
@ -22,7 +25,7 @@ The gui should support true end to end encrypted human messages between lightnin
## 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.
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
@ -32,16 +35,68 @@ And anyone you have a channel with, or have made a payment to, or received a pay
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.
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.
# end users want their local fiat.
# 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.
## atomic transactions between blockchains
such has between bitcoin, and stablecoins representing wrapped local fiat.
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. For full interopability, all blockchains should support Schnor signatures on the Ristretto elliptic curve.
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 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.
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.