diff --git a/docs/merkle_patricia_dag.md b/docs/merkle_patricia_dag.md
index 47ebc86..911cdc4 100644
--- a/docs/merkle_patricia_dag.md
+++ b/docs/merkle_patricia_dag.md
@@ -258,11 +258,13 @@ information from the peer that has the node with more children.
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="29em" height="18em"
- viewBox="0 170 220 140"
- style="background-color:ivory" stroke-width="1"
+ viewBox="0 170 220 140"
+style="background-color:ivory"
+ stroke-width="1"
stroke-linecap="round" >
-
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 three huge
+particular part of the blockchain is valid. This has three
advantages over the chain structure.
1. A huge problem with proof of stake is "nothing at stake".
@@ -423,26 +425,32 @@ patricia dag to support immutability.
The intended usage is an immutable append only dag.
In a binary patricia tree each vertex has two links to other vertices,
-one of which corresponds to appending a $0$ bit to the bitstring, and
-one of which corresponds to adding a $1$ bit to the bitstring that
-identifies a vertex and the path to the vertex
+one of which corresponds to appending a $0$ bit to the bitstring that
+identifies the vertex and the path to the vertex, and one of which
+corresponds to adding a $1$ bit to the bitstring.
-In this dag vertices that have bit strings ending in a $0$ bit have a
+In this dag vertices identfied by bit strings ending in a $0$ bit have a
third link, that links to a vertex whose bit string is truncated back to
-the previous $0$ bit, a shorter bitstring. Thus, whereas in blockchain
-(Merkle chain) you need $n$ hashes to reach and prove data $n$ blocks
-back, in this Merkle patricia dag, you only need $\bigcirc(\log_2n)$ hashes.
+the previous $1$ bit, and that trailing $1$ bit zeroed, a shorter bitstring. Thus, whereas in blockchain (Merkle chain) you need $n$ hashes to
+reach and prove data $n$ blocks back, in this Merkle patricia dag, you
+only need $\bigcirc(\log_2n)$ hashes to reach any vertex of the blockdag.
+
+The vertex $0010$ has an extra link back to the vertex $000$, the
+vertices $0100$ and $010$ have extra links back to the vertex $00$, the
+vertices $1000$, $100$, and $10$ have extra links back to the vertex $0,
+and so on and so forth.
This enables clients to reach any previous vertex through a chain of
hashes, and thus means that each new item in sequence is a hash of
-all previous data in the tree.
+all previous data in the tree. Each new item has a hash
+commitment to all previous items.
-The clients keep the old roots of the balanced binary trees of blocks
-around, so the peers cannot sodomize them. This will matter more
-and more as the blockchain gets bigger, and bigger, resulting in ever
-fewer peers with ever greater power and ever more clients, whose
-interests are apt to be different from that of ever fewer and
-ever greater and more powerful peers.
+The clients keep the old roots of the balanced binary trees of
+blocks around, so the peers cannot sodomize them. This will matter
+more and more as the blockchain gets bigger, and bigger, resulting
+in ever fewer peers with ever greater power and ever more clients,
+whose interests are apt to be different from those of ever the fewer
+and ever greater and more powerful peers.
The superstructure of balanced binary Merkle trees allows us to
verify any part of it with only $O(log)$ hashes, and thus to verify that
@@ -478,10 +486,22 @@ ever growing oids.
When we defined the key for a Merkle patricia tree, the key
definition gave us the parent node with a key field in the middle of
-its chilren, infix order
+its chilren, infix order. For the tree depicted above, we want postfix order.
-For this dag, we would like to define an oid field so that the oid
-field of a parent follows the oid fields of its children.
+Normally, if the bitstring is a full field width, the vertex contains the
+information we actually care about, while if the bitstring is less than
+the field width, it just contains hashes ensuring the data is
+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
+simply that bitstring, while the oid 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
+for the parent vertices, if the leaf vertices, the vertices with full field
+width bitstrings, are sequential and ever increasing..
Let us suppose the leaf nodes of the tree depicted above are fixed size $c$, and the interior vertices are fixed size $d$ ($d$ is probably thirty two or sixty four bytes) and they are being physically stored in
memory or a file in sequence.
@@ -494,20 +514,6 @@ relationship to the bitstring of a vertex corresponding to a complete
field, which is the field that represents the meaning that we actually
care about).
-We can calculate the location of an interior vertex from the number
-of the largest numbered leaf node that it could be a parent of:\
-To find the oid of a vertex accessed as an sql table pad its bitstring
-out to the field width plus one with $1$ bits, (equivalent to
-subtracting one from key and oring the result with the key) subtract
-the `std::popcount` of the bitstring, and you have the sequential
-and always incrementing oid, such that the oid of a parent is always
-one greater than the oid of its right child.
-
-If the field is an integer, the block height, the number of blocks in
-the blockchain, the oid is one bit larger and approximately twice the
-size of that integer, assuming that we are putting vertices and block
-roots in the same sql table. (Which we probably won't.)
-
# Blockchain
A Merkle-patricia block chain represents *an immutable past and a constantly changing present*.
diff --git a/docs/writing_and_editing_documentation.md b/docs/writing_and_editing_documentation.md
index 82c7c19..7dae4b8 100644
--- a/docs/writing_and_editing_documentation.md
+++ b/docs/writing_and_editing_documentation.md
@@ -247,6 +247,28 @@ through a narrow pass, in which case you are going to have a C
curve going to the narrow pass, and an S curve going to the
destination or the next narrow pass.
+When you want to join two points, and don't care about the path, use an L straight line
+
+When you want to join two points, and you care about the direction
+in which it starts, or the direction in which it finishes, but not both,
+use a Q, which gives you one degree of control freedom.
+
+When you want to join two points, and care about the direction it
+starts, and the direction it ends, use a C, which gives you two
+degrees of control freedom.
+
+When you want to join two points, and care about the direction it
+starts, the direction it ends, and you want it to go through a
+gateway in the middle, use a C S, which gives you three degrees
+of control freedom. But watch out for the reflection of the last control
+point in the C landing somewhere difficult inside the S curve. If the last control point in the C is further from the end point of the C
+than the end point of the S, things can get strange. Sometimes you
+want to adjust the behavior of the S curve by moving the last
+control point of the previous C or S to the right position. A distant
+previous control point is apt to have a big effect on the following S,
+a near control point little effect, but likely to give you an
+unpleasantly sharp turn at the join.
+
``` default
M point c point point point s point point
s point point ... s point
@@ -256,8 +278,8 @@ Is guaranteed to give you a smooth curve, for reasonably sane
control points, with the curve passing through the second point of
the s, and its direction set by the first point of the s.
-You change a point, the effect is entirely local, does not propagate
-up and down the line.
+You change a control point, the effect is entirely local, does not
+propagate up and down the line.
``` default
M point q point point t point t point ... t point
@@ -269,7 +291,9 @@ of the t points, but you cannot easily control the direction the curve
takes through the points. Changing the control point of the first q
will result in things snaking all down the line, and changing any of
the intermediate t points will change the the direction the curve
-takes through all subsequent t points.
+takes through all subsequent t points, sometimes pushing the curve
+into pathological territory where bezier curves give unexpected and
+nasty results.
Scalable vector graphics are dimensionless, and the `