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

minor changes

Browse Source
This commit is contained in:
Cheng 2023-07-19 21:29:11 -07:00
parent 8c07e05a82
commit 8ad667f81f
No known key found for this signature in database
GPG Key ID: 571C3A9C3B9E6FCA
3 changed files with 24 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/blockdag_consensus.md
View File

@ -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

13
docs/merkle_patricia_dag.md
View File

@ -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" >
<g font-family="'Times New Roman'" font-size="10" font-weight="400"
fill-rule="evenodd" fill="black" >
@ -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" />
<g font-weight="800" fill=#FFF>
<g fill=#FFF>
<g id="link_bits" font-size="18">
<text>
<text font-weight="bold" fill=#FFF>
<tspan y="74" x="134">10</tspan>
<tspan y="134" x="228">0</tspan></text>
<text fill=#000>
<tspan y="74" x="134">10</tspan>
<tspan y="134" x="228">0</tspan></text>
</g>
@ -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

6
docs/names/zookos_triangle.md
View File

@ -103,6 +103,12 @@ Zooko’s triangle is the solution to this problem. It is explained in several p
</g>
</svg>
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