Comments:BIP 0150
This proposal lacks sufficient justification for the large scale attacks that it naively facilitates.
We assume peer operators want to limit the access of different node services or increase datastream priorities to a selective subset of peers.
This is a case where the interests of "peer operators" are at odds with the interest of Bitcoin as a public network. There is no discussion in the proposal of the significant systemic risks that it introduces. Bitcoin must remain a public network for its security model to remain valid.
Also we assume that peers want to connect to specific peers to broadcast or filter transactions (or similar actions that reveal sensitive informations)
Anonymity cannot be achieved by connection to strongly-identifiable peers. This requires an anonymizing network.
and therefore operators want to authenticate the remote peer and ensure that they have not connected to a MITM (man-in-the-middle) attacker.
Another word for this screening is censorship.
Benefits of peer authentication:
- Peers can detect MITM attacks when connecting to known peers
- Peers can allow resource hungry transaction filtering only to specific peers
- Peers can allow access to sensitive information that can lead to node fingerprinting (fee estimation)
- Peers can allow custom message types (private extensions) to authenticated peers
This is a laundry list of forms of censorship options; selectively allowing access to specified people. The identity of a peer is not meaningful if it is anonymous. Identity ultimately refers to the person who controls the node.
Incidentally, it is not a necessary aspect of a Bitcoin node that it retain the "fingerprints" of past users. This is generally a design flaw resulting from ill-advised attempts at optimization. It is also not a material issue if one avoids the ill-advised use of Tor in the P2P protocol itself, and properly uses a trusted full node for queries and only posts transactions as a Client to a public Server via an anonymizing network.
A simple authentication scheme based on elliptic cryptography will allow peers to identify each other and selectively allow access to restricted services or reject the connection if the peer identity cannot be verified.
Simple or not, there is no justification for integrating node identity into the P2P protocol. By design Bitcoin provides consensus-based validation as the means to ensure the validity of information obtained from untrusted peers. Introduction of trust into the protocol will inevitably lead to calls for all "major players" (mining pools, exchanges, web wallets, web APIs, merchant services, etc.) to both establish private connections to each other and eventually to exclude all connections that do not provide an authorized identity.
Such requirements will eventually arrive from regulatory agencies around the world. This BIP should be referred to as the "Know Your Customer" proposal, if not the central "Anti-Money Laundering" feature. As this happens, which is entirely predictable, Bitcoin will become a private financial network reachable for the public only through banks calling themselves Bitcoin Wallets.
--Eric Voskuil, 2017-01-21
`
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`**