1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-19 05:45:07 +01:00

spellcheck

This commit is contained in:
Paul Sztorc 2019-04-05 09:59:18 -07:00
parent c6da99018d
commit a9b0bc593a

View File

@ -1,5 +1,3 @@
<pre>
BIP: ????
Layer: Consensus (soft fork)
@ -144,7 +142,7 @@ D1 is updated via M1 and M2.
==== New Block Validation Rules ====
# Escrows are added in a procedure that resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgement" of the sidechain in 95% of the following 2016 blocks.
# Escrows are added in a procedure that resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 95% of the following 2016 blocks.
# It is possible to "overwrite" an escrow. This requires 6 months (26298 blocks) of M2s, instead of 2 weeks (XXXX). This possibility does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26298 blocks).
@ -214,9 +212,9 @@ From one block to the next, "ACKs" can only change as follows:
* The ACK-counter of any withdrawal can only change by (-1,0,+1).
* Within a sidechain-group, upvoting one withdrawal ("+1") requires you to downvote all other withdrawals in that group. However, the minimum ACK-value is zero (and, therefore, downvotes cannot reduce it below zero).
* While only one withdrawal can be upvoted at once, they can all be unchangd at once ("abstain") and they can all be downvoted at once ("alarm").
* While only one withdrawal can be upvoted at once, they can all be unchanged at once ("abstain") and they can all be downvoted at once ("alarm").
One option for explict transmission of M4 is:
One option for explicit transmission of M4 is:
4-byte - Message identifier (0x????????)
1-byte - Version of this message
@ -253,7 +251,7 @@ We come, finally, to the critical matter: where users can take their money *out*
In each block, a withdrawal in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150).
Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transtion (the txn that actually withdraws funds from the escrow). The two cannot match exactly, beacuse "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing).
Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transaction (the txn that actually withdraws funds from the escrow). The two cannot match exactly, because "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing).
To solve this, we define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. Specifically, these bytes are the first input and the first output.