cleaning up the very incomplete, but publishable, outline of

what needs doing, and also changed the unintellible

docs/immutable_append_only_data_structure.md

@@ -41,7 +41,16 @@ The blocks one color, the intermediate vertexes another, and final vertex defini
 
 
 
-You really need a physical implementation that is a physically append only file of irregular sized merkle vertexes, plus a rule for finding the physical location of the item hashed, plus a collection of quick lookup files that contain only the upper vertexes.  On the other hand, sqlite is already written, so one might well want to think of implementing this as an ever incrementing oid, which we can get around to making into a physically append only file another day.  Stashing hashes of variable heights into a single table with an ever incrementing oid is the same problem as the physical file, except that sqlite allows variable length records. (and does that housekeeping for us.)
+You really need a physical implementation that is a physically an append
+only file of irregular sized merkle vertexes, plus a rule for finding the
+physical location of the item hashed, plus a collection of quick lookup
+files that contain only the upper vertexes.  On the other hand, sqlite is
+already written, so one might well want to think of implementing this as an
+ever incrementing rowid, which we can get around to making into a physically
+append only file another day.  Stashing hashes of variable heights into a
+single table with an ever incrementing rowid is the same problem as the
+physical file, except that sqlite allows variable length records. (and does
+ that housekeeping for us.)
 
 The data defined by hash is immutable but discardable.
 

docs/lightning_layer.md

@@ -407,13 +407,13 @@ to those snooping on other people’s business.
 ### Other use cases for a reliable broadcast channel
 
 The use case of joint signatures implies an immutable data structure of the
-tuple oid, hash, public key, and two scalars.
+tuple rowid, hash, public key, and two scalars.
 
 But another use case is to publicly root private immutable data.
 
 If you continually upload the latest version, you wind up uploading most of
 tree, or all of it, which does not add significantly to the cost of each
-interaction recorded.  The simplest sql friendly data structure is (oid of
+interaction recorded.  The simplest sql friendly data structure is (rowid of
 this item, public key, hash, your index of hash, oids of two child hashes)
 with the reliable broadcast channel checking that the child hashes do in fact
 generate the hash, and that the tuple (public key, index of hash) is unique.
@@ -425,7 +425,7 @@ inconsistent pasts for immutable append only data structure associated with
 this key?
 
 To work around this problem, allow unbalanced Merkle trees, consisting of
-(oid of this item, public key, hash, your tree node index, index of the
+(rowid of this item, public key, hash, your tree node index, index of the
 highest index leaf governed by this hash, oids of two child hashes)  If an
 unbalanced node referencing an old tree root is uploaded at intervals of less
 than three months, it can be used to prove the contents and uniqueness of

docs/manifesto/Revelation.md

@@ -16,11 +16,14 @@ The intent of this technology is to liberate the reputational information that m
 
 These reputations will make it possible for an anonymous use-once identity to perform an instant on the spot transaction secured by the reputation of a large and long established peer on the blockchain with a pseudonymous reputation, the transaction being with an identity secured by a secret held by an anonymous individual, also secured by the reputation and secret held by someone who controls a large and long established peer with a pseudonymous reputation, whose physical servers are located in a data center in a nation state distant from the nation state and local authorities where the actual transaction takes place.
 
-But it is awfully close to, and very similar to, the profoundly oppressive technology of the Prophecy of the Beast. It is a dual use technology, that can be used by individuals to free themselves from centralized control, and could be used by powerful centers to enforce centralized control.
+The problem that we face is awfully close to, and very similar to, the profoundly
+oppressive technology of the Prophecy of the Beast. Networked money is a dual use
+technology, that can be used by individuals to free themselves from centralized
+control, and can be used and is being used by powerful centers to enforce centralized control.
 
 The free and pseudonymous end to end encrypted messaging is intended to undermine the officially unofficial state religion of progressivism, making the worship of Gnon possible and safe, but could easily be repurposed to the heavily censored messaging scrutinized by global databases belonging to the beast that today we see with Twitter, Facebook, and Gmail, which enforce the officially unofficial State Religion of the Beast.
 
-For example, this technology can be used to publish data obtained by the Scientific Method, secured by reputations for faithfully adhering to the scientific method, but Google Docs censors such information and downranks such reputations in search results in favor of data concocted by Peer Review, which are priestly truths established by the priestly method of Holy Synods, of the priesthood of the Beast.
+For example, this technology can be used to publish data obtained by the Scientific Method, secured by reputations for faithfully adhering to the scientific method, but Google Docs censors such information and downranks such reputations in search results in favour of data concocted by Peer Review, which are priestly truths established by the priestly method of Holy Synods, of the demonic priesthood of the Beast.  The scientific method is scientists saying they did things, and as a result saw things, while peer review is the official consensus about what what other people should have seen, regardless of what they actually saw.  Consensus is the priestly method to truth, observation the scientific method.  The priesthood of demons demand sacrifices, lest the wrath of their demons fall upon us, and the bigger the sacrifices, the more profit and power they get.  Censorship of scientific data, has, like other forms of censorship, rendered people cynical.  We need a mechanism for pseudonymous reputation that is resistant to hostile manipulation.
 
 ## The Prophecy of the Beast
 
@@ -115,7 +118,7 @@ becomes costly and burdensome, so with bitcoin we have alarmingly few
 miners, and power over the blockchain is concentrated in very few miners.
 
 The rhocoin design aims to ensure that when power gets concentrated, as with scaling it
-inevitably will, it gets concentrated into peers controlled by whaltes whose underlying identity
+inevitably will, it gets concentrated into peers controlled by whales whose underlying identity
 secrets can easily vanish off to another jurisdiction, and whose power depends
 on having lots of wealthy clients, many of whom are unlikely to want full
 scrutiny of all their transactions, lest envious people find some excuse for

docs/manifesto/motivation.md

@@ -10,11 +10,11 @@ the consensus of the blockchain, rather than the authority
 of giant organizations
 :::
 
-To secure the a crypto currency against hostile forces, we need to secure people's ability to hold conversations, including conversations about payment, contracts, and money, against hostile forces, so we need to replace the domain name system and tcp-ip, and build an overlay network inside and on top of that capable of hiding ip addresses from the parties to the conversation.  (Though such a conversation will necessarily be slow and inefficient, so not used routinely.)
+To secure a crypto currency against hostile forces, we need to secure people's ability to hold conversations, including conversations about payment, contracts, and money, against hostile forces, so we need to replace the domain name system and tcp-ip, and build an overlay network inside and on top of that capable of hiding ip addresses from the parties to the conversation.  (Though such a conversation will necessarily be slow and inefficient, so not used routinely.)
 
 Bitcoin and everything blockchain is a centralized ledger. Worse than that – it’s the One True Ledger. It isn’t like gold. Gold one can have directly on one’s person or indirectly in a vault somewhere.
 
-It is possible to have a crypto currency similar to bitcoin where though there is one global ledger recording what public keys own what, there is no way to tell which human actors know the private keys corresponding to those public keys.
+It is possible to have a crypto currency similar to bitcoin where though there is one global ledger recording what public keys own what, there is no way to tell which human actors know the private keys corresponding to those public keys. Instead of public ledger of all transactions, [a database of private ledgers containing only hashes whose preimages are the private transactions](./scalability.html).
 
 A crypto currency needs to be centerless – it needs to able to survive the seizure of key servers by a hostile powerful party.  Trouble with bitcoin is that it is not centerless – proof of work winds up being centralized in a small number of extremely powerful and extremely expensive computers.
 

docs/manifesto/scalability.md

@@ -95,7 +95,7 @@ merkle patricia tree of merkle dags. You have a recursive snark
 that proves the chain, and everything in it, is valid (no one
 created tokens out of thin air, each transaction merely moved
 the ownership of tokens) And then you prove that the new block is valid, given that rest of the chain was valid, and produce a
-recursive snark that the new block, which chains to the previou
+recursive snark that the new block, which chains to the previous
 block, is valid.
 
 ## reliable broadcast channel
@@ -188,15 +188,15 @@ the blockchain.
 
 Those of them that control the inputs to the transaction
 (typically one human with one wallet which is a client of one peer)
-commits unspent transactions outputs to that transaction,
+commit unspent transactions outputs to that transaction,
 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.
+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
 the transaction prove that the new transaction outputs are valid,
 and being new are unspent transaction outputs, without revealing
-the transaction or the inputs to that transaction.
+the transaction or the inputs to that transaction, and the 
 
 You have to register the unspent transaction outputs on the public
 index, the reliable broadcast channel, within some reasonable
@@ -279,7 +279,7 @@ We produce the summary block of past blocks just before we
 produce the base level block, and the base level block has an
 edge pointing to the previous base level block, a chain edge,
 and an edge pointing to the just created summary block a tree
-edge, a chain edge and a tree edge. And when we summarize two
+edge, a chain edge, has two edges, a chain edge and a tree edge. And when we summarize two
 blocks into a higher level summary block, their chain and tree
 edges are discarded, because pointing to data that the reliable
 broadcast channel will no longer carry, and the newly created
@@ -296,10 +296,10 @@ transaction can produce a proof that a commit is valid if no
 previous commit, but only a peer can prove no previous commit.
 
 So the peer, who may not necessarily be controlled by the same
-person as controls the wallet, will need to know the inputs to the
+person as controls the wallet, will need to know the hashes of the inputs to the
 transaction, and could sell that information to interested parties,
 who may not necessarily like the owner of the client wallet very
-much.  But the peer will not know the value of the transaction
+much.  But the peer will not know the preimage of the hash, will not know the value of the transaction
 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
@@ -330,7 +330,7 @@ that transaction that the transaction is valid. They do not need to
 publish on the reliable broadcast channel what transaction that
 was, and what the inputs to that transaction were.
 
-So we end up with the blockchain carrying only $\bigcirc\big(\log(h)\big)$
+So we end up with the blockchain carrying only $\bigcirc\ln(h)$
 blocks where $h$ is the block height, and all these blocks are likely
 to be of roughly comparable sizes to a single base level block.
 So, a blockchain with as many transactions as bitcoin, that has
@@ -348,3 +348,42 @@ blockchain. You cannot shard the bitcoin blockchain, because a
 shard might lie, so every peer would have to evaluate every
 transaction of every shard. But with recursive snarks, a shard can
 prove it is not lying.
+
+### sidechaining
+
+One method of sharding is sidechaining
+
+Each transaction output contains a hash of the verification rule,
+one of the requirements whereby one will prove that the output
+was validly committed as an input to a transaction when the time
+comes to commit it to a transaction.  One always has to prove that
+the transaction will not create money out of thin air, but one also
+has to prove the transaction was done by valid authority, and the
+output defines what is its valid authority. The normal and usual
+verification rule is to prove that the party committing the output
+knows a certain secret. But the verification rule could be anything,
+thus enabling contracts on the blockchain,
+and could instead be that a valid current state of the sidechain, which is a valid descendant of the state previously used in the previous similar transaction that created this output,
+committed this output as an input to the new transaction -- in which case the output
+represents the money on a sidechain, and the transaction moves money between the sidechain and mainchain.
+
+This hash allows anyone to innovate some sidechain idea, or
+some contract idea, without needing everyone else on the
+blockchain to buy in first.  The rest of the blockchain does not
+have to know how to verify valid authority, does not need to
+know the preimage of the hash of the method of verification, just
+verify that the party committing did the correct verification,
+whatever it was.  Rather than showing the reliable broadcast
+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.  And what that method was, outsiders do
+not need to know, reducing the burden of getting everyone
+playing by the same complex rules.  If a contract or a sidechain
+looks indistinguishable from any other transaction, it not only
+creates privacy and reduces the amount of data that other people
+on the blockchain have to handle and know how to handle, it also
+radically simplifies blockchain governance, bringing us closer to
+the ideal of transactions over distance being governed by
+mathematics, rather than men.

docs/manifesto/social_networking.md

@@ -5,6 +5,11 @@ title: >-
 sidebar: true
 notmine: false
 ...
+
+::: myabstract
+[abstract:]{.bigbold}
+Speech is suppressed by censorship, and on "free speech" platforms by state sponsored shill spam.  Crypto currency transaction metadata goes over insecure networks, so we need a secure, uncensorable, and spam resistent Web 3.0 both for freedom of speech and economic freedom.
+:::
 # the crisis of censorship
 
 If we have a mechanism capable of securely handling arbitrary free form

docs/merkle_patricia_dag.md

@@ -23,7 +23,7 @@ In a Merkle dag, vertices are data structures, and edges are hashes,
 as if one followed a link by looking up the preimage of a hash.
 Obviously this is seldom an efficient way of actually implementing a
 edges, and one is in practice going to use a pointer or handle for
-data structures in memory, and an oid for structures in a database,
+data structures in memory, and an rowid for structures in a database,
 but this is an internal representation.  The canonical form has no
 pointers, no oids and no handles, these are internal representations
 of the structure defined and implied by the hashes, and in
@@ -503,8 +503,8 @@ immutable, that the past consensus has not been changed
 underneath us, so, regardless of how the data is actually physically
 stored on disk, these belong in differnt sql tables.
 
-So, the oid of a vertex that has a full field width sized bitstring is
+So, the rowid of a vertex that has a full field width sized bitstring is
-simply that bitstring, while the oid of its parent vertices is obtained
+simply that bitstring, while the rowid of its parent vertices is obtained
 by appending $1$ bits to pad the bitstring out to full field width, and
 subtracting a count of the number of $1$ bits in the original bitstring,
 `std::popcount`, which gives us sequential and ever increasing oids
@@ -553,7 +553,7 @@ graph, each block being a tree representing the state of the system at
 that block commitment, but that tree points back into previous block
 commitments for those parts of the state of the system that have not
 changed. So the hash of the node in such a tree will identify, probably
-through an OID, a record of the block it was a originally constructed
+through an rowid, a record of the block it was a originally constructed
 for, and its index in that tree.
 
 A Merkle-patricia directed acyclic graph, Merkle-patricia dac, is a
@@ -628,7 +628,7 @@ If we represented the bitstring that corresponds to the block
 number, the block height, has having a large number of leading
 zero bits, so that it corresponds to a sixty three bit integer (we need
 the additional low order bit for operations translating the bitstring
-to its representation as a key field or oid field) a fixed field of sixty
+to its representation as a key field or rowid field) a fixed field of sixty
 four bits will do us fine for a trillion years or so.
 
 But I have an aesthetic objection to representing things that are not

docs/names/multisignature.md

@@ -363,7 +363,7 @@ maintained by a single host, albeit a notarization will not be evidence usable
 on the blockchain until its notary block is Merkle chained by the blockchain.
 If the blockchain automatically trusts notary signatures, they will rapidly
 cease to be trustworthy.  The chain, not the signature, makes it officially
-official.  The notary signature and oid is merely a promise to make it
+official.  The notary signature and rowid is merely a promise to make it
 official.  The blockchain will treat notaries as untrusted, so that everyone
 else can treat them as trusted at low risk.
 

docs/pandoc_templates/pandoc.template

@@ -47,7 +47,7 @@ $endif$
 </head>
 <body>
 <div class="logo-header">
-  <a href="$docroot$/manifesto/motivation.html">
+  <a href="$docroot$manifesto/motivation.html">
     <img src="$docroot$pandoc_templates/logo.svg" id="logo-graphic" alt="logo">
     <div style="height:18px;"></div>
     <div id="Rhocoin"></div>

docs/writing_and_editing_documentation.md

@@ -183,7 +183,10 @@ compile correctly, but `\ln` and `\log` is more likely to compile correctly than
 symbol.
 $$\ln(1+x)=x-\bigcirc(x^2)$$
 $$H(a|b|v)$$
-
+$\begin{align}
+   a&=b+c \\
+   d+e&=f
+\end{align}$
 though it is subtly prettier with katex, and some maths expressions will
 break Pandoc unless one tells it to use katex.