diff --git a/docs/manifesto/bitcoin.md b/docs/manifesto/bitcoin.md index 0d5a0a8..035fac1 100644 --- a/docs/manifesto/bitcoin.md +++ b/docs/manifesto/bitcoin.md @@ -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 diff --git a/docs/manifesto/consensus.md b/docs/manifesto/consensus.md new file mode 100644 index 0000000..bfd45a6 --- /dev/null +++ b/docs/manifesto/consensus.md @@ -0,0 +1,9 @@ +--- +# katex +title: >- + consensus +sidebar: true +notmine: false +abstract: >- + Consensus is a hard problem, and gets harder when you have shards +--- diff --git a/docs/manifesto/lightning.md b/docs/manifesto/lightning.md index 8a71757..f982c01 100644 --- a/docs/manifesto/lightning.md +++ b/docs/manifesto/lightning.md @@ -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 \ No newline at end of file diff --git a/docs/manifesto/scalability.md b/docs/manifesto/scalability.md index b647f7b..041e322 100644 --- a/docs/manifesto/scalability.md +++ b/docs/manifesto/scalability.md @@ -71,7 +71,7 @@ a proof that this output was committed on the public broadcast channel of the blockchain to this transaction and no other, and a proof that this output was itself an output from a transaction whose inputs were committed to that transaction and no other, and that the inputs and outputs of that -transaction balanced. +transaction balanced. So the proof has to recursively prove that all the transactions that are ancestors of this transaction output were valid all the @@ -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. @@ -414,7 +483,7 @@ inputs, nor what the transaction is about. It will only know the hashes of the inputs, and does not even need to know the hashes of the outputs, though if the client wallet uses the same peer to register the change output, the peer will -probably be able to reliably guess that that output hash +probably be able to reliably guess that that output hash comes from that transaction, and therefore from those inputs. If Bob is paying Ann, neither Bob's peer nor Ann's peer knows that Bob is paying Ann. If Bob is paying Ann, and gets a proof @@ -497,7 +566,7 @@ channel a snark for the verification of authority, which other people might not be able to check, the party committing a transaction shows it a recursive snark that shows that he verified the verification of authority using the verification method -specified by the output, +specified by the output, without bloating the public broadcast channel by revealing what method the output specified. What that method was, outsiders do not need to know, reducing the burden of getting everyone @@ -524,7 +593,7 @@ We always intended from the very beginning to destroy postmodern capitalism and restore the modern capitalism of Charles the Second. -The commits form a directed acyclic graph. +The commits form a directed acyclic graph. Each particular individual who knows the preimage of *some* of the hashes of outputs and commits committed to the public broadcast channel knows *some* paths through the directed acyclic graph. @@ -546,12 +615,12 @@ the ledger consistent along this named path. *And* we want him to be able to prove that he is showing facts about his ledger that are consistent with everyone else's ledgers. To do that, triple entry accounting, where a journal entry -that lists an obligation of a counterparty as an asset, +that lists an obligation of a counterparty as an asset, or an obligation to a counterparty as a liability, references a jointly signed row that must exist in both party's ledgers, jointly signed by the non fungible name tokens of both parties. -Double entry accounting shows the books balance. +Double entry accounting shows the books balance. Triple entry accounting shows that obligations between parties recorded on their books balance. Triple entry accounting was originally developed by cypherpunks when we were attempting to diff --git a/docs/manifesto/sharding.md b/docs/manifesto/sharding.md new file mode 100644 index 0000000..0d01fa4 --- /dev/null +++ b/docs/manifesto/sharding.md @@ -0,0 +1,9 @@ +--- +# katex +title: >- + sharding +sidebar: true +notmine: false +abstract: >- + Consensus is a hard problem, and gets harder when you have shards +--- diff --git a/docs/manifesto/white_paper.md b/docs/manifesto/white_paper.md index 7da1dcd..620f6fa 100644 --- a/docs/manifesto/white_paper.md +++ b/docs/manifesto/white_paper.md @@ -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