repeated and clarified the explantion on monero, contracts, and beating Metcalfe's law and the cold start problem

docs/manifesto/social_networking.md

@@ -966,7 +966,7 @@ Monero did OK, because it is the leading privacy coin.  It has a niche, but
 cannot break out of the not very large niche.  Because its privacy mechanism means it is
 a worse Bitcoin than Bitcoin in other respects.
 
-And the cold start problem means we cannot directly take over that niche either.
+And the cold start problem means we cannot directly take over Monero's niche either.
 
 But our proposed privacy mechanism means we have a tech advantage over both
 Bitcoin and Monero - better contract capability than Bitcoin or Ether, because
@@ -975,10 +975,25 @@ with a costly proof of fulfillment, and without revealing everything to the
 network, and without the rest of the network needing to know what that there was
 a contract, what that contract is nor to be able to evaluate it.
 Because of its privacy mechanism,
+
 Monero cannot do contracts, which prevents atomic exchange between Monero
 and Bitcoin, and prevents Monero from doing a lightning network that would
 enable fast atomic exchange between itself and Bitcoin lightning.
 
+In order to do atomic exchanges between two blockchains, which is to say,
+to enable people to move value between one blockchain and another without
+registering for Know Your Customer, have to have contracts on the blockchain.
+
+In order to provide DeFi markets for the exchange of fiat for crypto currency,
+have to have contracts on the blockchain.
+
+In order to have a lightning network, have to have contracts on the blockchain.
+
+To compete, have provide people with an off ramp and on ramp to bitcoin,
+in the expectation that there will in due course the off ramp will be
+a whole lot busier than the on ramp. If no contracts on the blockchain, no ramp,
+making it a whole lot harder to solve Metcalfe’s law and the cold start problem.
+
 So if we get a niche, get differentiation from Monero and Bitcoin,
 we can then break out of that niche and eat Monero, being a better
 privacy coin, a better Monero, and from the Monero niche eat Bitcoin,

docs/number_encoding.md

@@ -202,55 +202,67 @@ And so on and so forth for signed integers of unlimited size.
 
 # bitstrings
 
-Bitstrings in Merkle-patricia tree representing an sql index
-are typically very short, so should be represented by a 
-variable length quantity.  Which does not need to have the correct
-bytestring sort order.
+It might be convenient to represent the data as a pile of edges,
+rather than a pile of vertices, thus solving the problem that
+the tree must always start with an edge, not vertex.
+This duplicates the start position of every edge,
+but this duplication does not matter because the patricia representation of an index,
+and the standard and usual database representation of an index,
+compresses out the leading duplication.
 
-I have no end of clever ideas to represent them in fully compressed form,
-but all we actually need is a count of the bits of the vertex, the difference
-counts for the number of bits in the left and right edges,
-the left bytestring which contains the parent and left bitstrings, and, 
-if the right bitstring is more than one bit longer than the parent bitstring, 
-the difference bytes for the right bitstring.
+So we are representing an sql index by table whose primary key is the
+bitstring of the start position, and whose values are the
+start position and the end position.
+The patricia edges of this table live in the same table, just
+their values are distinguished from actual leaf values.
 
-If we want to be terribly clever at optimization, if both leaf bitstrings
-are only greater by one than the parent bistring, we have bytes containing
-the parent bitstring, otherwise the bytestring containing all the bits of 
-the longest edge bitstring, plus the difference bytes for the shorter
-bitstring if it is longer than its parent by more than one.
+Variable length bitstrings are represented as variable
+length bytestrings by appending a one bit followed by 
+zero to seven zero bits.
 
-An edge in a Merkle-patricia sql index contains the bit path
-of the thing pointed to, and the completely unrelated hash of the
-thing pointed to, which contains its own type information.
-But sometimes, often, we are indexing things
-*by* their hash, so need a flag on a leaf edge to denote this case.
+In the table we may compress the end values by discarding
+all leading bytes except the overlap byte.
+
+Thus the actual table, containing only the leaf values,
+is a virtual table based on a select statement that
+excludes the internal edges of the patricia tree from
+the table of all edges, and concatenates the compressed
+value with the index to form the absolute value.
+
+It is very common for the end value to be very short.
+
+We could save a byte (which is a premature optimization)
+as follows:
+
+If S is the length of the bitfield in bits:
+
+If $0\le S \lt 5$, it is represented by the variable
+length integer obtained by prepending a set bit to the bitfield.
+
+If $5\le S$ we represent the bit sequence as a byte
+sequence prepended with the byte count plus 48,
+(leaving a gap of sixteen impermissible values for future expansion)
 
 # Dewey decimal sequences.
 
-The only thing we ever want to do with Dewey decimal sequences is $<=>$,
-and they are always positive numbers less than $10^{14}$, so we represent them as
-a sequence of variable length numbers terminated by the number minus one
-and compare them as bytestrings.
+The only operation we ever want to do with Dewey
+decimal sequences is $<=>$, and they are always
+positive numbers less than $10^{34}$, so we represent
+them as a sequence of variable length positive
+numbers terminated by a byte that corresponds
+to the header of an impermissibly large number, the
+byte `0xFFFF`, and compare them as bytestrings.
 
-### SQL blobs.
+Albeit we could add, subtract, multiply, and divide
+Dewey decimal sequences as polynomials,
+which would require signed integer sequences,
+but I cannot see any use case for this,
+while unsigned integer sequences have the advantage
+that the ones used to sort and identify things are always
+positive in practice, and one may consider a utf
+string to be a very long Dewey decimal sequence.
 
-In order for blobs in a database representing bitfields to sort
-correctly, we do not use seven bit nibbles, but eight bit bytes,
-with a final byte representing zero to seven bits as an eight bit byte.
 
-For this we use the mapping:
-Where if\
-$j$ is the bitfield interpreted as a number\
-$m$ is the length of the bitfield\
-$c$ is a count of the set bits in the bitfield
-
-The value of the eight bit field is:\
-$j*(2^{(7-m)}-1)+c$
-
-The difference is that blob is preceded by a count field
-that is not used in the sort order, which is tricky to
-do in a Merkle-patricia tree representing an sql index.
 
 ## Use case
 

docs/writing_and_editing_documentation.md

@@ -126,6 +126,7 @@ $$\int \sin(x) dx = \cos(x)$$
 $$\sum a_i$$
 $$\lfloor{(x+5)÷6}\rfloor = \lceil{(x÷6}\rceil$$
 $$\lfloor{(x+5)/6}\rfloor = \lceil{(x/6}\rceil$$
+$$0\le S \lt 5$$
 Use `\bigcirc`, not capital O for Omicron $\bigcirc$.  `\Omicron` will not always
 compile correctly, but `\ln` and `\log` is more likely to compile correctly than
 `ln` and `log`, which it tends to render as symbols multiplied, rather than one