diff --git a/docs/libraries.md b/docs/libraries.md
index 5b66077..663773b 100644
--- a/docs/libraries.md
+++ b/docs/libraries.md
@@ -139,13 +139,14 @@ being stronger than the underlying elliptic curve.  With password
 strengthening, we can randomly leave out one of the adjectives or adverbs
 from one of the passphrases.
 
-# Polkadot, substack and gitcoin
+# Polkadot, Near, substack and gitcoin
 
 It has become painfully apparent that building a blockchain is a very large project.
 
 Polkadot is a blockchain ecosystem, and substack a family of libraries for
 constructing blockchains.  It is a lot a easier to refactor an existing
-blockchain than to start entirely from scratch.
+blockchain than to start entirely from scratch.  [Near] is way ahead of me, 
+because not suffering from not invented here syndrome.
 
 Polkadot is designed to make its ecosystem subordinate to the primary
 blockchain, which I do not want - but it also connects its ecosystem to
diff --git a/docs/merkle_patricia-dac.md b/docs/merkle_patricia_dag.md
similarity index 98%
rename from docs/merkle_patricia-dac.md
rename to docs/merkle_patricia_dag.md
index fd59dc7..d03c71c 100644
--- a/docs/merkle_patricia-dac.md
+++ b/docs/merkle_patricia_dag.md
@@ -1002,11 +1002,22 @@ solve the problem of the number of items not being a power of two?
 	</g>
 </svg>
 
-This is a Merkle binary dag, not a Merkle-patricia tree.  I found that
+This data structure means that instead of having one gigantic
+proof that takes weeks to evaluate that the entire blockchain is
+valid, you have an enormous number of small proofs that each
+particular part of the blockchain is valid.  This has two huge
+advantages over the chain structure.
+
+1. It protects clients against malicious peers, since any claim
+the peer makes about the total state of the blockchain can
+be proven with $\bigcirc(\log_2n)$ hashes.
+1. If a block gets lost or corrupted that peer can identify that one specific block that is a problem.  Peers have to reload down, or at least re-index, the entire blockchain far too often.
+
+This is not a Merkle-patricia tree.  I found that
 generalizing Merkle patricia trees to handle the case of immutable append
 only files led to more complicated data structures and more complicated
 descriptions.  It has a great deal in common with a Merkle-patricia tree, but
-a Merkle vertex is its own type, even though it convenient for it to have
+this vertex is its own type, even though it convenient for it to have
 much in common with a Merkle patricia vertex.  Putting it into the patricia
 straightjacket generated a lot of mess.  A Merkle patricia vertex is best
 handled as a special case of a Merkle vertex, and a Merkle patricia tree as
@@ -1019,7 +1030,7 @@ structure that another party is using.
 
 This reduces the amount of trust that clients have to place in peers.  When
 the blockchain gets very large there will be rather few peers and a great
-many peers, thus there will be a risk that the peers will plot together to
+many clients, thus there will be a risk that the peers will plot together to
 bugger the clients.  This structure enables a client to verify that any part of
 the blockchain is what his peer say it is, and thus avoids the risk that peer
 may tell different clients different accounts of the consensus.  Two clients