[CROSS POST FROM HERE]
I’m wondering if enough knowledge about BU and emergent consensus exists to write a white paper. The purpose of this thread is to (a) brainstorm the main points that such a paper should touch upon, and (b) collect links to the relevant information that should be cited.
To get us started...
1. Introduction
2. The Most Extended Chain
- Miners mine upon the most-likely-to-win chain rather than the longest chain. We'll refer to the most-likely-to-win chain as the “most extended” chain (as per
@Roger_Murdock) .
- The "most extended" chain is normally the longest chain (it contains the most PoW) but it gets "retarded" by a factor that accounts for strange things that might make miners and nodes more likely to reject or orphan it.
- For example, a chain with a block at its tip that takes longer than 10 min to validate/propagate is
less extended than the chain without that block (as per
@theZerg's
recent paper) even though it contains more work.
- Formalize this idea further...
- The "retardation factor" cannot be precisely measured or defined--only approximated. Each node and miner is free to make its own estimates.
- It is through this process of miners picking the most-likely to win chain by using their discretion for edge cases--rather than blindly mining upon the chain with the most PoW--that keeps Bitcoin's consensus objective.
- The reason for this is that the alternative is to define "the longest valid chain as the valid chain" which--as
@digitsu just pointed out in his
recent article--relies on weak subjectivity (Core defines what is "valid" rather than validity being an emergent property of the network).
In BU, the subjectivity would appear to enter into the system in real-time in a decentralized fashion as each miner applies his own "retardation factor" (based also on what he thinks will be accepted by the nodes).
3. There is No Block Size Limit
- Rational arguments against the existence of a strict block size limit:
+ node operators and miners have always been free to roll their own code
+ The 1 MB limit in Core's reference implementation was just an "inconvenience barrier"
+ Core cannot prevent nodes/miners from changing their limits if miners and nodes are free to join the network
- Empirical evidence against the existence of a strict block size limit:
+
my charts here.
4. Large Blocks
- Formalize with math when a node will fork from consensus and when a block will be accepted into the longest PoW chain. Prove that:
+ A node with a block size limit greater than the hash-power weighted median will always follow the longest chain.
+ A large block will be accepted into the longest chain if it is smaller than the hash-power weighted median block size limit.
+ Analyze the conditions for network split events.
5. Forking Pressure
- Introduce the concept of "forking pressure" in the context of the block size limit as a node's or miner's desire to allow the network to process more transactions per second (looks like
@Roger_Murdock just spoke about this
here)
- Here is perhaps a partial
quantitative description (the deadweight loss due to the existence of a production quota with Qmax < Q* is a sort of "pressure.")
6. Consensus Pressure
- Introduce the concept of "consensus pressure," which is particularly important for miners, and which is related to the great advantage that ensues if miners agree together on the same (or compatible) limits.
- It is best if the majority of the hash power has the
exact same limit, in order to prevent network split under the conditions defined in Section 4 (in the very unlikely cases when it could happen).
- Perhaps "consensus pressure" could be modelled as something as simple as:
P_consensus = K x ( Median limit - Node's limit).
7. A Simple Model of Emergent Consensus
- Show using a simple program (a la
Wolfram NKS) that entities that can "feel" forking pressure and that can "feel" consensus pressure, will spontaneously agree on new block size limits as pressure builds, so long as they have some means to signal their settings to the other nodes.
8. Conclusion
[CROSS POST FROM HERE]
