cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Saner plan for representing bit strings.

Browse Source 
Because I realized that the merkle
vertex encloses them and gives them order
and the merkle vertex is itself enclosed
and given order.
This commit is contained in:
reaction.la 2023-11-03 23:19:26 +00:00
parent 022d794d5f
commit a88fc58e71
No known key found for this signature in database
GPG Key ID: 99914792148C8388
1 changed files with 12 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/number_encoding.md
View File

@ -1,5 +1,5 @@
--- ---
# katex #katex
title: Number encoding title: Number encoding
sidebar: true sidebar: true
... ...
@ -207,22 +207,18 @@ are typically very short, so should be represented by a
variable length quantity. Which does not need to have the correct variable length quantity. Which does not need to have the correct
bytestring sort order. bytestring sort order.
So for bitstrings of six bits or less, we represent it as a byte with I have no end of clever ideas to represent them in fully compressed form,
a leading zero bit, and the bits following the first one bit are but all we actually need is a count of the bits of the vertex, the difference
the bitstring, and if the leading bit is one, it is a byte count counts for the number of bits in the left and right edges,
of byte aligned bits. Because we know the start alignment, the the left bytestring which contains the parent and left bitstrings, and,
beginning of the bitfield is implicit, and the final byte encodes if the right bitstring is more than one bit longer than the parent bitstring,
a bit field of zero to seven bits. This can represent a bytestring the difference bytes for the right bitstring.
of one to 128 bytes. However unreasonably large values, representing
variable length bytestrings representing unreasonably large bitstrings,
we reserve for future expansion, since the largest bitstring that will
be valid in normal usage will be thirty three bytes, being a full sized
hash followed by a byte representing the zero length bitstring.
If the bitstring representing the edge brings us the end of field, it If we want to be terribly clever at optimization, if both leaf bitstrings
is leaf edge, which is a different type, being a pointer to what is are only greater by one than the parent bistring, we have bytes containing
being indexed rather than a pointer to another patricia vertex and the parent bitstring, otherwise the bytestring containing all the bits of
may have additional data. the longest edge bitstring, plus the difference bytes for the shorter
bitstring if it is longer than its parent by more than one.
An edge in a Merkle-patricia sql index contains the bit path An edge in a Merkle-patricia sql index contains the bit path
of the thing pointed to, and the completely unrelated hash of the of the thing pointed to, and the completely unrelated hash of the