-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Comments:BIP 0061
The reject message is backwards-compatible; older peers that do not recognize the reject message will ignore it.
This is an incorrect assumption. Peers of older versions should (and some do) validate the protocol against invalid messages. Sending a reject message when the peer has announced a version below 70002 should not be allowed by the protocol as it is not backward compatible.
It is also incorrect to assume that older protocol versions will cease to exist. It is perfectly reasonable for ancient versions of protocols to continue to operate. These protocols do not have expiration dates. New implementations can and do support configurable lower protocols levels than 70002.
If this precedent is allowed to hold the network is subject to trivial DOS attacks. The requirement to treat invalid messages as valid precludes a node from dropping the peer due to incorrect behavior. This statement should be struck (and offending implementations should be fixed so that they do not intentionally send invalid messages).
--Eric Voskuil, 2017-02-07
Clean and straightforward. Nodes should implement this. (Disagree with Voskuil's assessment, as nodes have always been expected to ignore unknown messages.) --Luke Dashjr, 2017-03-14
I also disagree with Voskuil's assessment: nodes have always ignored unknown messages. However, the reject message is of minimal utility and adds many strings to the protocol which are a common source of vulnerabilities and which wastes bandwidth with no clear gain. I recommend implementations do not implement this, or implement it only for transaction messages (which is the only case that I'm aware of anyone actually using it for something plausibly useful). --Greg Maxwell, 2017-03-14
It is true that some implementations ignore message types that are not recognized. However it is not a protocol requirement to do so. A properly implemented node does not send messages to a peer that it knows the peer will not understand. Obtaining knowledge of what messages a peer can understand is the purpose of the version exchange. So it is not the case that nodes are actually expected to ignore messages that are incorrectly sent, it just happens to be the case that some do. --Eric Voskuil, 2017-03-15
`
BIP: 119 Layer: Consensus (soft fork) Title: CHECKTEMPLATEVERIFY Author: Jeremy Rubin j@rubin.io Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119 Status: Draft Type: Standards Track Created: 2020-01-06 License: BSD-3-Clause
==Abstract==
This BIP proposes a new opcode, OP_CHECKTEMPLATEVERIFY, to be activated as a change to the semantics of OP_NOP4.
==Summary==
OP_CHECKTEMPLATEVERIFY uses opcode OP_NOP4 (0xb3) as a soft fork upgrade.
OP_CHECKTEMPLATEVERIFY does the following:
- There is at least one element on the stack, fail otherwise
- The element on the stack is 32 bytes long, NOP otherwise
- The DefaultCheckTemplateVerifyHash of the transaction at the current input index is equal to the element on the stack, fail otherwise
The DefaultCheckTemplateVerifyHash commits to the serialized version, locktime, scriptSigs hash (if any non-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and currently executing input index.
The recommended standardness rules additionally:
- Reject non-32 byte as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS.
==Motivation==
This BIP introduces a transaction template, a simple spending restriction that pattern matches a transaction against a hashed transaction specification. OP_CHECKTEMPLATEVERIFY reduces many of the trust, interactivity, and storage requirements inherent with the use of pre-signing in applications. For more details on applications, please see the references.
==Detailed Specification==
The below code is the main logic for verifying CHECKTEMPLATEVERIFY, described in pythonic pseudocode. The canonical specification for the semantics of OP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can be seen in the reference implementation.
The execution of the opcode is as follows:
# CTV always requires at least one stack argument
if len(self.stack) < 1:
return self.errors_with(errors.script_err_invalid_stack_operation)
# CTV only verifies the hash against a 32 byte argument
if len(self.stack[-1]) == 32:
# Ensure the precomputed data required for anti-DoS is available,
# or cache it on first use
if self.context.precomputed_ctv_data == None:
self.context.precomputed_ctv_data = self.context.tx.get_default_check_template_precomputed_data()
# If the hashes do not match, return error
if stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data):
return self.errors_with(errors.script_err_template_mismatch)
return self.return_as_nop()
# future upgrade can add semantics for this opcode with different length args
# so discourage use when applicable
if self.flags.script_verify_discourage_upgradable_nops:
return self.errors_with(errors.script_err_discourage_upgradable_nops)
else:
return self.return_as_nop()
The computation of this hash can be implemented as specified below (where self is the transaction type). Care must be taken that in any validation context, the precomputed data must be initialized to prevent Denial-of-Service attacks. Any implementation must cache these parts of the hash computation to avoid quadratic hashing DoS. All variable length computations must be precomputed including hashes of the scriptsigs, sequences, and outputs. See the section "Denial of Service and Validation Costs" below. This is not a performance optimization.
def ser_compact_size(l): r = b"" if l < 253: # Serialize as unsigned char r = struct.pack("B", l) elif l < 0x10000: # Serialize as unsigned char 253 followed by unsigned 2 byte integer (little endian) r = struct.pack("<BH", 253, l) elif l < 0x100000000: # Serialize as unsigned char 254 followed by unsigned 4 byte integer (little endian) r = struct.pack("<BI", 254, l) else: # Serialize as unsigned char 255 followed by unsigned 8 byte integer (little endian) r = struct.pack("<BQ", 255, l) return r
def ser_string(s): return ser_compact_size(len(s)) + s
class CTxOut: def serialize(self): r = b"" # serialize as signed 8 byte integer (little endian) r += struct.pack("<q", self.nValue) r += ser_string(self.scriptPubKey) return r
def get_default_check_template_precomputed_data(self): result = {} # If there are no s`**