new file: docs/manifesto/bitcoin.md

new file:   docs/manifesto/lightning.md
modified:   docs/manifesto/scalability.md
modified:   docs/setup/set_up_build_environments.md
modified:   docs/setup/wireguard.md

docs/manifesto/bitcoin.md

@@ -0,0 +1,37 @@
+---
+lang: en
+title: How to move Bitcoin to recursive snarks
+---
+
+::: myabstract
+[abstract:]{.bigbold}
+Crypto currencies based on recursive snarks are the future.  Polygon's aggregated blockchains are a proposal to move the Ethereum ecosystem to recursive snarks, and if the Ethereum ecosystem moves to recursive snarks, and Bitcoin does not, Bitcoin will die.
+:::
+
+# Step one
+
+Very soon there will recursive snark currencies all over the place.
+
+One of them, and likely most of them, is going to have wrapped bitcoin -- a coin issued on their blockchain that is backed by a bitcoin reserve of equal value.  Unfortunately such backing is apt to be lost or stolen.
+
+The way to do wrapping right without the Bitcoin software being modified is threshold signatures as with Thorchain.  A supermajority of voters, eighty or ninety percent threshold, from time to time vote a bitcoin transaction on the bitcoin blockchain that redeems wrapped bitcoin on the recursive snark blockchain, and also the same vote reallocates votes in proportion to new ownership of wrapped bitcoin.
+
+(Schnorr signatures allow threshold votes to take up the same space as an ordinary signature, and a threshold signature is indistinghable from an ordinary signature, even if it is taken over a thousands of votes.)
+
+# Step two
+
+And, being a recursive snark blockchain, generate a snark that proves that bitcoin transaction and new allocation of votes was in accordance with the rules, to each holder of wrapped bitcoin on their home blockchain.
+
+The wrapped bitcoin is still insecure, since the voters could vote wrongfully, but now the holders of wrapped bitcoin on the snark blockchain will know if the vote is wrongful.  Which means the voters lose their wrapped bitcoin, but they do not care because they have the real bitcoin.
+
+# Step three
+
+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
+
+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.
+
+# Step five
+
+Since the snark wrapped bitcoin is now as secure as bitcoin on the main Bitcoin blockchain, transactions are far faster and cheaper, and vastly more powerful and general contracts are possible, over time everyone gradually moves their bitcoin to the snark blockchain, where it is wrapped in snarks, and slow and expensive redemption operations become rarer and rarer.

docs/manifesto/lightning.md

@@ -0,0 +1,47 @@
+---
+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.

docs/manifesto/scalability.md

@@ -148,6 +148,73 @@ vertices, with all the paths through the dag for which we need to
 generate proofs being logarithmic in the size of the contents of
 the reliable broadcast channel and the height of the blockchain.
 
+### scaling the reliable broadcast channel to billions of peers,exabytes of data, and terabytes per second of bandwidth
+
+At scale, which is not going to happen for a long time,
+the reliable broadcast channel will work much like bittorrent.
+There are millions of torrents in bittorrent,
+each torrent is shared between many bittorrent peers,
+each bittorrent peer shares many different torrents,
+but it only shares a handfull of all of the millions of torrents.
+
+Each shard of the entire enormous reliable broadcast channel will be
+something like one torrent of many in bittorrent, except that
+torrents in bittorent are immutable, while shards will continually
+agree on a new state, which is a valid state given the previous
+state of that shard *and all the other shards* and the peers
+sharing a shard will generate a recursive proof that the new state
+is valid, in that for each transaction causing a change in state,
+the peer that wants that transaction generates a recursive proof
+of knowledge of valid transactions going all the way back to the
+genesis block which justifies that change of state as valid. and
+all these proofs are recursively incorporated into a new proof
+that the shard is valid, which eventually gets incorprated into
+a single proof over all shards.  Which peers sharing other shards
+will use when they in turn generate new state in those other shards.
+
+If Bob wants to pay Carol on layer one, he constructs a proof
+that the transaction is valid, the transaction gets incorporated
+into the state of a shard, or several shards that he is sharing,
+the proof gets incorporated into the proof that the shard is
+valid, he sends that proof and transaction to Carol, who can
+subsequently use that proof, that transaction, and that
+transaction output (a transaction output that can only be
+used to generate a transaction in a shard that Carol is sharing,
+but Bob is not necessarily sharing).  Which transaction that
+Carol later generates will likely make payment to Dave in yet
+another shard that neither she nor Bob is sharing.
+
+When Bob generates a transaction, the inputs must belong to
+some of the few shards that he is sharing, but the outputs
+can belong to any shard.
+
+He generates the proof of knowledge using only data available in
+the shards he is sharing, but the proof, being recursive,
+shows that someone in some shard knew each transaction leading to
+this one was valid, including zetabytes of transactions now long
+lost in the mists of time, all the way back to the genesis block.
+
+It will be quite a while before we need more than one shard,
+but with recursive proofs of knowledge, we can easily have an
+enormous number of mutable shards, as bittorrent has an enormous
+number of immutable torrents.
+
+Each shard will not have to store a very large amount of data.
+Sharding is likely to be forced by transaction volume and
+bandwidth limits, by data processing rather than data storage.
+Unless someone is using the blockchain as a publishing mechanism,
+and wants to keep a vast pile of data around and available,
+which is a perfectly valid and acceptable use, indeed an intended
+use since we intend to use the blockchain as a free speech
+mechanism, though when there is a lot of very old
+speech it will probably only be accepted in some shards
+and not others.
+
+Some shards will be primarily be blogs, or a community of many
+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.
+
 ## merkle patricia tree
 
 A merkle patricia tree is a representation of an SQL index as a
@@ -221,10 +288,10 @@ making them spent transaction outputs. But does not reveal that
 transaction, or that they are spent to the same transaction –
 though his peer can probably guess quite accurately that they are. The client creates a proof that this an output from a transaction with valid inputs, and his peer creates a proof that the peer verified the client's proof and that output being committed was not already committed to another different transaction, and registers the commitment on the blockchain.  The output is now valid for that transaction, and not for any other, without the reliable broadcast channel containing any information about the transaction of which it is an output, nor the transaction of which it will become an input.
 
-In the next block that is a descendant of that block the parties to
+In the next block that is a descendant of that block the parties
-the transaction prove that the new transaction outputs are valid,
+to the transaction prove that the new transaction outputs are
-and being new are unspent transaction outputs, without revealing
+valid, and being new are unspent transaction outputs, without
-the transaction or the inputs to that transaction, and the 
+revealing the transaction outputs, nor the transaction, nor the inputs to that transaction.
 
 You have to register the unspent transaction outputs on the public
 index, the reliable broadcast channel, within some reasonable

docs/setup/set_up_build_environments.md

@@ -32,7 +32,7 @@ platform environment.
 
 If you face grief launching an installer for your virtual box device
 make sure the virtual network is bridged mode
-and get into the live cd command line 
+and get into the live cd command line.
 
 ```bash
 sudo -i
@@ -66,7 +66,7 @@ apt-get -qy update && apt-get -qy upgrade
 ```
 
 To install guest additions, thus allow full communication between host
-and virtual machine, update Ubuntu, hen while Ubuntu is running,
+and virtual machine, update Ubuntu, then while Ubuntu is running,
 simulate placing the guest additions CD in the simulated optical drive.
 Then Ubuntu will correctly activate and run the guest additions
 install.
@@ -81,11 +81,14 @@ the OS in ways the developers did not anticipate.
 
 ### virtual box Debian install bug
 
-Debian 12 (bookworm) install fails on a UEFI virtual disk.
+install fails when installing Debian 12 UEFI
-The workaround is to install a base Debian 11 system as UEFI
+
-in Virtual Box. Update /etc/apt/sources.list from Bullseye
+Edit the Grub boot entry when booting off the install ISO.
-to Bookworm. Run apt update and apt upgrade.
+1. Highlight the "Install" option
-After that you have a functioning Debian 12 UEFI Virtual machine.
+2. Press "e" to edit the Grub entry
+3. Add `fb=false` before the `---` parameter
+Should read something like `linux /install.amd/vmlinuz vga=788 fb=false --- quiet`
+4. Press F10 or Ctrl+X to boot
 
 ### server in virtual box
 

docs/setup/wireguard.md

@@ -868,7 +868,7 @@ cat /etc/wireguard/ios.conf | qrencode -t ansiutf8
 ```
 This is apt to be easier, because it is likely to be hard to transfer information between android systems.
 
-Grencode is very useful for transferring data to android systems, which tend to be locked down against ordinary users transferring computer data.
+QRencode is very useful for transferring data to android systems, which tend to be locked down against ordinary users transferring computer data.
 
 ## Configure  VPN Client on Windows