From 858b6beb79933f2a77178bc6ec048ac91fa96d98 Mon Sep 17 00:00:00 2001 From: 54627384 <72476593+54627384@users.noreply.github.com> Date: Sun, 19 Jun 2022 10:05:04 +1000 Subject: Update bip-0300.mediawiki I've assumed that all mentions of ACK value and ACK counter are synonymous and therefore have updated all instances of this within the BIP to be "ACK-counter". I've noticed that M4 shows the different terms on two different lines (Line 256 and Line 257), which has made me think that potentially these terms aren't synonymous. Updates made to align with term used through out the BIP: Line 213 - adding explicit mention of "ACK-counter" Line 229 - adding explicit mention of "ACK-counter" Line 257 - replaced "ACK-value" with "ACK-counter" Line 288 - replaced "ACK value" with "ACK-counter" --- bip-0300.mediawiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'bip-0300.mediawiki') 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: -- cgit v1.2.3