Voting Process
+Voting Process
Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such that the ledger_index modulo 256 is equal to 0.) In the ledger immediately before the flag ledger, each validator whose account reserve or transaction cost preferences are different than the current network setting distributes a "vote" message alongside its ledger validation, indicating the values that validator prefers.
In the flag ledger itself, nothing happens, but validators receive and take note of the votes from other validators they trust.
+In the flag ledger itself, nothing happens, but validators receive and take note of the votes from other validators they trust.
After counting the votes of other validators, each validator attempts to compromise between its own preferences and the preferences of a majority of validators it trusts. (For example, if one validator wants to raise the minimum transaction cost from 10 to 100, but most validators only want to raise it from 10 to 20, the one validator settles on the change to raise the cost to 20. However, the one validator never settles on a value lower than 10 or higher than 100.) If a compromise is possible, the validator inserts a SetFee pseudo-transaction into its proposal for the ledger following the flag ledger. Other validators who want the same change insert an identical SetFee pseudo-transaction into their proposals for the same ledger. (Validators whose preferences match the existing network settings do nothing.) If a SetFee psuedo-transaction survives the consensus process to be included in a validated ledger, then the new transaction cost and reserve settings denoted by the SetFee pseudo-transaction take effect starting with the following ledger.
In short:
-
diff --git a/concept-fees.html b/concept-fees.html
index a3443584ae..b3521e7dd7 100644
--- a/concept-fees.html
+++ b/concept-fees.html
@@ -127,6 +127,7 @@