fred/wallet
1
0
Fork 0
forked from cheng/wallet
Code Pull Requests Activity

modified: docs/manifesto/bitcoin.md

Browse Source 
modified:   docs/manifesto/lightning.md
modified:   docs/manifesto/scalability.md
modified:   docs/manifesto/white_paper.md

new file:   docs/manifesto/consensus.md
new file:   docs/manifesto/sharding.md
This commit is contained in:
reaction.la 2024-05-26 02:22:30 +00:00
parent 459b044046
commit 5f47c5b35a
No known key found for this signature in database
6 changed files with 304 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/manifesto/bitcoin.md
View File

@ -28,9 +28,9 @@ The wrapped bitcoin is still insecure, since the voters could vote wrongfully, b
The Bitcoin blockchain is modified to pay attention to the snark, and not propagate or accept the transaction if the vote is not in accordance with the snark.
# Step four
# Step four: The Hogex
Drop the voting, and just rely on the snark. The bitcoin blockchain is modified to accept the snark in place of the signature. The snark wrapped bitcoin is now as secure as bitcoin on the Bitcoin blockchain.
Drop the voting, and just rely on the snark, so that the pegin pegout transactions becomes the equivalent to Litecoin's Hogex. The bitcoin blockchain is modified to accept the snark in place of the signature. The snark wrapped bitcoin is now as secure as bitcoin on the Bitcoin blockchain.
# Step five

9
docs/manifesto/consensus.md Normal file
View File

@ -0,0 +1,9 @@
---
# katex
title: >-
consensus
sidebar: true
notmine: false
abstract: >-
Consensus is a hard problem, and gets harder when you have shards
---

156
docs/manifesto/lightning.md
View File

@ -12,31 +12,106 @@ abstract: >-
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.
Bitcoin's initial rise was meteroric. As the scaling limit bites, that rise is topping out.
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.
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.
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.
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 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 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 works.
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.
# 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.
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.
## 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.
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.
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,
nd 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 human readable 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.
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.
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.
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
@ -90,14 +165,71 @@ 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.
# channel creation
## The incoming liquidity problem
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 uniltarally 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 noging to unilaterally initiate a channel to you.
## Polygon channels.
A channeel 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 Satoship hoped for, and failed to provide.
# 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.
[point locked]:https://voltage.cloud/blog/lightning-network-faq/point-time-locked-contracts/{target="_blank"}
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.
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.
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.
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 and both lightning networks employ [point locked] contracts, 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.
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 sotware 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.
s

73
docs/manifesto/scalability.md
View File

@ -106,12 +106,13 @@ necessarily part of an SQL table, though obviously you can put a
bunch of structs of the same type in an SQL table, and represent an SQL
table as a bunch of structs, plus at least one primary index.
An SQL table is equivalent to a pile of structs,
plus at least one primary index of those structs.
plus one primary index of those structs.
## merkle graphs and merkle trees
A merkle graph is a directed acyclic graph whose vertices are
structs containing hashes
structs containing hashes. It corresponds to a key value store,
whose keys are random two fifty six bit numbers.
A merkle vertex is a struct containing hashes.
The hashes, merkle edges, are the edges of the graph.
@ -223,6 +224,63 @@ blogs, except that comments in those blogs can pay money or
receive money, as in Nostr, and at first the only use of shards
will be to publish the equivalent of blogs or social media feeds.
### Outline of scalable, shardable, algorithm
To create a transaction in a blockchain based on recursive snarks,
the peer injecting the transaction creates a patricia merkle tree
of inputs and outputs, with a proof that inputs equal the outputs,
and the outputs were valid as of block N.
This gets merged with the Patricia merkle tree of another transaction,
and another, and another, generating one big transaction of a whole pile of transactions,
which giant merged transaction becomes block N+1 of the blockchain.
To prevent double spending, each input is associated with hash of itself and its original transaction,
So that different inputs of the same transaction are associated with different hashes,
and the same input to two different transactions (double spend) is associated with different hashes.
When merging transactions, each input can only be associated with one such hash.
If there are some inputs around that are associated with more than one such hash,
they get blacklisted and no one merges with a tree containing them,
so that that proposal for block N+1 is ignored and forgotten.
Before we generate a merkle patricial tree of one giant merged transaction, we
generate a total order over all transaction inputs and a patricia merkle tree of
that ensures that the hash of each input is associated with only one hash of
input plus transaction, so that we can spot double spends before doing
too much work merging. collisons get added to a double spend blacklist,
and do not get merged.
If there are several incompatible proposed versions of block N+1,
Nakomoto consensus wins.
The true block N+1 of several alternatives is whichever
alternative block N+2 gets built on.
For sharding to work, it must be possible to merge in parallel,
generate a proof for a shard of the tree that only includes the
preimage of the hash for a certain address range of inputs and outputs,
while only having the hashes for outside of that address range.
For greater privacy, one can merge the inputs first, and add the outputs later,
but then one has to handle the case that the inputs get merged, the outputs fail
to get merged, and one has to add them in a later block, thus the simplest possible
algorithm leaks some data associating inputs and outputs to some people, while the
most private, and most efficient, algorithm has to handle more cases.
The more private algorithm is more efficient, because the consensus process has
less to consense about, albeit it is less efficient for the peer injecting his
transaction, but more efficent for the peer trying to get agreement between
all peers, on the total state of the blockchain,
which is apt to be the slow and expensive part.
Which sharding requires the prover to have a proof of the properties of the preimage of a hash,
without needing the keep the preimage around outside of the address range he is working on.
Which is to say the recursive snark algorithm has to be able to efficiently handle hashes inside
the proof, which is a hard problem at which most recurive snark algorithms fail. Plonky2 is acceptbly
efficient, but has other problems in that though it is theoretically open sources, last time I ckecked, there
were caveats both practical and legal.
## merkle patricia tree
A merkle patricia tree is a representation of an SQL index as a
@ -240,6 +298,17 @@ you found something in an index of the blockchain, or proves that
something, such as a previous spend of the output you want to spend,
does not exist in that index.
This is equivalent to implementing an SQL style index inside a key
value store database whose keys are random twofiftysix bit integers.
Which people tend to wind up doing when working with a no-sql key value store databases.
You tend to wind up doing your own custom implementation of SQL inside the no-sql.
Which we will have to ensure that a transaction output can only be
committed to an unspent transaction once, equivalent to a UNIQUE SQL index, so will
need an SQL like index of transaction outputs.
A hash value store is a no-SQL key value store, which has no concept of a UNIQUE
index.
# Blockchain
Each block in the chain is an set of SQL tables, represented as merkle dags.

9
docs/manifesto/sharding.md Normal file
View File

@ -0,0 +1,9 @@
---
# katex
title: >-
sharding
sidebar: true
notmine: false
abstract: >-
Consensus is a hard problem, and gets harder when you have shards
---

63
docs/manifesto/white_paper.md
View File

@ -308,6 +308,69 @@ mathematical facts about the nature of collective action.
## Sovereign Corporation
My writings on Sovereign corporations are inconsistent and incoherent,
because I have continually changed the definition over time.
Also they are dispersed all over the place, and should be in one place
to make it easier to keep the meaning consistent.
### New definition incoming, edit in progress
It is fairly obvious that any Dao that is reasonably functional fails the Howey test,
and is therefore an unregistered security.
A sovereighn corporation is a Dao that does not pretend it is not a corporation
A successful DAO usually has someone who does the kind of stuff a CEO does,
a group of people who do the kind of stuff a board does,
and people keeping track of money in and money out,
but its all informal, vague, and vulnerable to scamming,
which makes it difficult and dangerous for outside investors to invest in the DAO coin.
The reason they do it this way is to evade the UDS Government Howey Test. If the government could
*find* the CEO, the board, and the accountant, the DAO coin would constitute an
"investment contract" and they would be guilty of selling an unregistered security
When you buy a DAO coin, you are investing in something like the shares of something like a corporation.
Or maybe you are not. It is hard to tell. And to avoid getting nailed by the Howey test, the officers
of that corporation like to keep it that way.
Any good DAO is centered around a secure communications platform. If we have a good communications
platform conceals a nym's IP, can carry money in human readable messages, which get integrated
into the immutable append only journal that is the basis of the corporation's books, if the DAO
explicitly has books, a CEO, and a board, it is going to be completely obvious that the DAO fails the Howey test.
It is also going to be very difficult to shut it down.
DAO stands for "Distributed Autonomous Organization".
But "distributed" is apt to conflict with "organization"
Daos that actually make a profit (and all the others are just scams)
continually have to make decisions that require immediate human judgement,
case by case.
A Sovereign Corporations is a Dao with a pseudonymous CEO, a
pseudonymous board, and book keeping based on an
immutable append only journal whose immutability is enforced
on each Sovereign corporation by the blockchain
on which their DAO coins(shares) are recorded and traded,
and that the books are validly derived from that journal is enforced
by the mechanisms that the blockchain uses to ensure validity of transactions.
Which does not stop people from adding lies into the journal,
but does force them to keep their lies consistent in relation to their other lies.
Triple entry accounting ensures that they have to tell the truth about liabilities
and assets which are obligations reslting from transactions between between such entities
and about assets on the blockchain.
The way that the corporations of modernity handled this,
the corporations of the Dutch Republic and Charles the Second of England,
was that the shareholders choose the board,
and can dismiss and replace the board at any time,
but should not and do not do so except under extraordinary circumstances,
the board chooses the CEO, and can dismiss and replace the CEO at any time,
but should not and do not do so except under extraordinary circumstances,
and the CEO decides.
This system worked remarkably well, outperforming all previous systems.
### old definition, rewrite of all old material needed.
[a sovereign corporation]:social_networking.html#many-sovereign-corporations-on-the-blockchain
[that sovereign corporation]:social_networking.html#many-sovereign-corporations-on-the-blockchain