summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Dashjr <luke_github1@dashjr.org>2022-07-28 21:04:46 +0000
committerGitHub <noreply@github.com>2022-07-28 21:04:46 +0000
commit43da5dec5eaf0d8194baa66ba3dd976f923f9d07 (patch)
tree05338c489e2e1c8083c0ed54b4a8c836e9760199
parentbcb66af5c353d2cfcd8da668b85886731c1810d0 (diff)
parent858b6beb79933f2a77178bc6ec048ac91fa96d98 (diff)
downloadbips-43da5dec5eaf0d8194baa66ba3dd976f923f9d07.tar.xz
Merge pull request #1333 from 54627384/patch-1
Update bip-0300.mediawiki with consistent use of "ACK-counter" term
-rw-r--r--bip-0300.mediawiki8
1 files changed, 4 insertions, 4 deletions
diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki
index f8c9b4d..3cecd85 100644
--- a/bip-0300.mediawiki
+++ b/bip-0300.mediawiki
@@ -210,7 +210,7 @@ D2 controls Bundles, and is driven by M3, M4, M5, and M6.
| 3
| ACKs (Work Score)
| uint16_t
-| The current total number of ACKs (the PoW that has been used to validate the Bundle).
+| The current ACK-counter, which is the total number of ACKs (the PoW that has been used to validate the Bundle).
|-
| 4
| Blocks Remaining (Age)
@@ -226,7 +226,7 @@ A hash of D2 exists in each coinbase txn, and has consensus-significance.
# The Bundles must be listed in a canonical order (so that the hashes match).
# From one block to the next, "Age" fields must increase by exactly 1 (ie, Blocks Remaining decreases by 1).
# Bundles are stored in D2 until they fail (which occurs at "Age" = "MaxAge"), or they succeed (Bundle is paid out).
-# From one block to the next, the value in the ACKs field can increase or decrease by a maximum of 1 (see below).
+# From one block to the next, the value in the ACKs field (ACK-counter) can increase or decrease by a maximum of 1 (see below).
If a Bundle succeeds (in D2), it "becomes" an M6 message and is included in a block.
@@ -254,7 +254,7 @@ Once a Bundle is in D2, how can we give it enough ACKs to make it valid?
From one block to the next, "ACKs" can only change as follows:
* The ACK-counter of any Bundle can only change by (-1,0,+1).
-* Within a sidechain-group, upvoting one Bundle ("+1") requires you to downvote all other Bundles in that group. However, the minimum ACK-value is zero.
+* Within a sidechain-group, upvoting one Bundle ("+1") requires you to downvote all other Bundles in that group. However, the minimum ACK-counter is zero.
* While only one Bundle can be upvoted at once; the whole group can all be unchanged at once ("abstain"), and they can all be downvoted at once ("alarm").
M4 does not need to be explicitly transmitted. It can simply be inferred from the new state of D2. M4 can therefore be improved over time, without affecting consensus.
@@ -285,7 +285,7 @@ As far as mainchain consensus is concerned, all deposits to a sidechain are alwa
We come, finally, to the critical matter: where users can take their money *out* of the sidechain.
-In each block, a Bundle in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150).
+In each block, a Bundle in D2 is considered "approved" if its "ACK-counter" value meets the threshold (13,150).
The Bundle must meet all these criteria: