diff --git a/docs/blockdag_consensus.md b/docs/blockdag_consensus.md index 9e2d919..27ab990 100644 --- a/docs/blockdag_consensus.md +++ b/docs/blockdag_consensus.md @@ -70,9 +70,7 @@ there is for a prong of a fork. ### Sampling the peers So we have to sample the peers, or rather have each peer draw consensus -from the same representative sample. And then we implement something -similar to Paxos and Raft within that small sample. And sometimes peers -will disagree about which sample, resulting in a fork, which has to be resolved. +from the same representative sample. For each peer that could be on the network, including those that have been sleeping in a cold wallet for years, each peer keeps a running cumulative @@ -83,6 +81,16 @@ On each block of the chain, a peer’s rank is the bit position of the highest bit of the running total that rolled over when its stake was added for that block. +*edit note* + +Here I propose making the weight in any block $2^rank$, but perhaps a better rule is that exclusive or of the previous and new value of the running total is the weight, which obviates the need for multiple peers to sign on to resolve draws. + +And also I propose a running limit on the rank. A better solution is that in the event of deep fork, where several blocks differ between the two branches of the fork, you prefer the branch that has the greatest median weight on all the blocks that differ multiplied by the total weight, rather than the total weight. If there are an even number of blocks, he takes the average of the two median weights. There is a limit on the number of blocks permitted since the alleged time on the last identical block. However a block with great block weight is allowed to be produces faster than a block with little block weight, so a higher weight branch can also have more total blocks. + +Which gives the same outcome, that on average and over time, the total weight will reflect the total weight of peers online and actively participating, and the total weight of a branch of a deep fork will reflect the total weight of the peers on that fork, so that in the event of a long network bisection, the group that has the most peers is likely to win when the bisection is fixed. + +*end edit note* + So if Bob has a third of the stake of Carol, and $N$ is a rank that corresponds to bit position higher than the stake of either of them, then Bob gets to be rank $R$ or higher one third as often as Carol. But even if diff --git a/docs/merkle_patricia_dag.md b/docs/merkle_patricia_dag.md index 13d6060..fcba2bb 100644 --- a/docs/merkle_patricia_dag.md +++ b/docs/merkle_patricia_dag.md @@ -119,7 +119,7 @@ The resulting patricia tree with infix keys is: xmlns="http://www.w3.org/2000/svg" width="29em" height="24em" viewBox="0 -10 320 265" - style="background-color:#FF9" stroke-width="1.5" + style="background-color:#FFF" stroke-width="1.5" stroke-linecap="round" > @@ -130,9 +130,12 @@ The resulting patricia tree with infix keys is: M 273,227 c20,-30 -60,-100 -57,-140 M 197,227 c12,-35 -52,-35 -44,-70 c 2,35 -38,35 -32,70" /> - + - + + 10 + 0 + 10 0 @@ -424,9 +427,7 @@ advantages over the chain structure. peer is generally accepted. This is not a Merkle-patricia tree. This is a generalization of a Merkle -patricia dag to support immutability. - -The intended usage is an immutable append only dag. +patricia dag to support immutability.. 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 that diff --git a/docs/names/zookos_triangle.md b/docs/names/zookos_triangle.md index 0fb1332..7085ab9 100644 --- a/docs/names/zookos_triangle.md +++ b/docs/names/zookos_triangle.md @@ -103,6 +103,12 @@ Zooko’s triangle is the solution to this problem. It is explained in several p +A Zooko name system can only be useful inside a user interface that detects name collisions in human readable names by looking at the globally unique public key and substitutes, or insists on someone substituting, a securely unique local human readable name (petname). + +Without this essential piece of machinery, which no one ever gets around to implementing, the unbearable load of distinguishing public keys is dumped on the end user. + +Zooko's triangle is thus a design for enabling humans to navigate public key systems, an as yet unimplemented design, though everyone, by rubbing up against problems, usually winds up implementing ad hoc something resembling a partial, incomplete, internally incosistent, and somewhat defective implementation of the Zooko name system. + - [Lambda for Humans: The PetName Markup Language](http://www.erights.org/elib/capability/pnml.html) Each identity, whether a human, a server, or something else, has a globally