Merge remote-tracking branch 'origin-pull/2115/head'

bip-0110.mediawiki

@@ -23,7 +23,7 @@ This document is licensed under the 3-clause BSD license.
 Blocks during a temporary, one-year deployment are checked with these additional rules:
 
 # New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.
-# OP_PUSHDATA* payloads and witness stack elements exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.
+# OP_PUSHDATA* payloads and [[#script-argument-witness-items|script argument witness items]] exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.
 # Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.)
 # Witness stacks with a Taproot annex are invalid.
 # Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.
@@ -33,6 +33,10 @@ Blocks during a temporary, one-year deployment are checked with these additional
 Inputs spending UTXOs that were created before the activation height are exempt from the new rules.
 Once the softfork expires, UTXOs of all heights are once again unrestricted.
 
+===GetBlockTemplate===
+
+This deployment uses the GBT deployment name "reduced_data" as defined in [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]. During mandatory signaling, the deployment's bit is included in "vbrequired".
+
 ==Motivation==
 
 In order to protect Bitcoin's intended function as the Internet's native money, the Bitcoin community has historically treated techniques for embedding arbitrary data into Bitcoin transactions with antagonism.
@@ -90,11 +94,27 @@ As far as Bitcoin is concerned, the data has some meaning other than the spammer
 (it is possible to write code that transforms *any* data into any other data - what matters is that Bitcoin has a well-defined meaning that is distinct from the unsupported one).
 Requiring users to divide their files into chunks of at most 256 bytes, raising the cost both in fees and in effort, sends a clear message that data storage abuses in general are unwelcome rather than sanctioned or supported.
 
-'''Why is there an exception for BIP16 redeemScripts?'''
+<span id="script-argument-witness-items"></span>
+'''What are "script argument witness items", referred to in rule 2?'''
 
-The content of redeemScripts are another script, which is then executed.
-Its contents are then also subject to the same OP_PUSHDATA* restrictions.
-Restricting it is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage.
+Script argument witness items are the witness stack elements that are placed on the script interpreter's stack as inputs before the script is executed - the witness equivalent of data pushes in scriptSigs.
+
+The following witness stack elements are '''not''' script argument witness items, and are thus excluded from rule 2 (though some are limited/invalidated by other rules):
+
+* Some items are part of a spend that invokes the script interpreter, but are popped from the witness stack before the remaining elements are passed to it as inputs:
+** Witness scripts and Tapleaf scripts (not limited)
+** Control blocks (limited by rule 5)
+** Annexes (invalidated by rule 4)
+* Others are not part of a script-path spend at all, so the script interpreter is not invoked:
+** Taproot key path signatures (limited to exactly 64 or 65 bytes by BIP 341 signature validation)
+** Witness stacks in spends of undefined witness versions (invalidated by rule 3)
+
+All '''other''' witness stack elements are script argument witness items, and are thus limited to 256 bytes by rule 2.
+
+'''Why are BIP16 redeemScripts, witness scripts, and Tapleaf scripts exempt from rule 2?'''
+
+BIP16 redeemScripts, witness scripts, and Tapleaf scripts are scripts, not data. Their contents are subject to the same OP_PUSHDATA* restrictions during execution.
+Restricting them is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage.
 
 '''Why make spending undefined witness/Tapleaf versions invalid?'''
 
@@ -317,15 +337,16 @@ This deployment deviates from standard BIP9 in five ways:
 
 '''Mandatory signaling period''': Similar to BIP8, this deployment enforces mandatory signaling during the retarget period immediately before mandatory lock-in (blocks 961632 to 963647; lock-in happens no later than block 963648). During this window, blocks that do not signal bit 4 are rejected as invalid. Mandatory signaling ends once the deployment reaches the LOCKED_IN state.
 
-'''Expiry via active_duration''': Standard BIP9 deployments are permanent once ACTIVE. This proposal includes an active_duration of 52416 blocks (~1 year), making the deployment temporary rather than permanent. The state machine remains in ACTIVE, but consensus rule enforcement is conditional: rules are only enforced for blocks with height < activation_height + active_duration. After 52416 blocks, the rules cease to be enforced and UTXOs are once again unrestricted.
+'''Expiry via active_duration''': Standard BIP9 deployments are permanent once ACTIVE. This proposal includes an active_duration of 52416 blocks (~1 year), making the deployment temporary rather than permanent. After active_duration blocks, the state machine transitions from ACTIVE to EXPIRED, a new terminal state. Once EXPIRED, the rules cease to be enforced and UTXOs are once again unrestricted.
 
 '''State transitions''': The state machine follows this progression:
 # DEFINED: Initial state until starttime
 # STARTED: After starttime; miners may signal with bit 4
 # LOCKED_IN: Entered at the start of the first retarget period where the threshold was reached in the previous period; mandatory signaling (blocks 961632-963647) ensures this happens no later than height 963648
 # ACTIVE: Entered one retarget period after LOCKED_IN; rules enforced for active_duration blocks
+# EXPIRED: Entered when block height >= activation_height + active_duration; rules no longer enforced (terminal state)
 
-The FAILED state is never reached because timeout is disabled. ACTIVE is the final state; there are no transitions after it. Miner signaling after expiry has no effect because the deployment is no longer in the STARTED state, and miner signaling only governs the STARTED → LOCKED_IN transition. After active_duration blocks, the deployment remains in the ACTIVE state but rules are no longer enforced. There is no separate EXPIRED state in the state machine.
+The FAILED state is never reached because timeout is disabled. EXPIRED is the final state; there are no transitions after it. Miner signaling after expiry has no effect because the deployment is no longer in the STARTED state, and miner signaling only governs the STARTED -> LOCKED_IN transition.
 
 ==Credits==