-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathspec.html
More file actions
160 lines (151 loc) · 25.4 KB
/
Copy pathspec.html
File metadata and controls
160 lines (151 loc) · 25.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>bitcoin-kernel specification - Bitcoin's consensus rules, with conformance</title>
<meta name="description" content="A conformance specification for Bitcoin's consensus rules: normative rules generated from a machine-readable ruleset, a conformance definition, a test suite, and an independent implementation that runs on Node and in the browser.">
<meta property="og:title" content="bitcoin-kernel specification">
<meta property="og:description" content="A conformance specification for Bitcoin's consensus rules: normative rules, a test suite, and an independent implementation that runs on Node and in the browser.">
<meta property="og:type" content="website">
<meta property="og:url" content="https://bitcoin-kernel.com/spec.html">
<meta property="og:image" content="https://bitcoin-kernel.com/og.png?v=4">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="bitcoin-kernel specification">
<meta name="twitter:description" content="A conformance specification for Bitcoin's consensus rules: normative rules, a test suite, and an independent implementation that runs on Node and in the browser.">
<meta name="twitter:image" content="https://bitcoin-kernel.com/og.png?v=4">
<style>
:root{--bg:#fff;--fg:#16181d;--mut:#5b6470;--bd:#e6e8eb;--pan:#fafbfc;--ac:#e8830c;--ac2:#0969da;--good:#1a7f37;--bad:#cf222e;--mono:ui-monospace,SFMono-Regular,Menlo,Consolas,monospace}
*{box-sizing:border-box}html{scroll-behavior:smooth}
body{margin:0;background:var(--bg);color:var(--fg);font:16px/1.7 -apple-system,system-ui,"Segoe UI",sans-serif}
a{color:var(--ac2);text-decoration:none}a:hover{text-decoration:underline}
nav{border-bottom:1px solid var(--bd);position:sticky;top:0;background:rgba(255,255,255,.9);backdrop-filter:blur(8px)}
nav .in{max-width:860px;margin:0 auto;padding:0 1.5rem;display:flex;align-items:center;gap:1.3rem;height:54px}
nav .brand{font-weight:700;letter-spacing:-.3px;margin-right:auto;color:var(--fg);font-size:1rem;text-decoration:none}nav .brand b{color:var(--ac)}
nav a{color:var(--mut);font-size:.9rem;font-weight:500}nav a.on{color:var(--fg)}
main{max-width:860px;margin:0 auto;padding:0 1.5rem 5rem}
header.doc{padding:3rem 0 1.4rem;border-bottom:1px solid var(--bd)}
.kicker{font:600 .78rem var(--mono);letter-spacing:.14em;text-transform:uppercase;color:var(--ac)}
h1{font-size:2.4rem;letter-spacing:-1px;margin:.5rem 0 0;font-weight:800}
.tagline{font-size:1.18rem;color:#37414d;margin:.6rem 0 0}
.docmeta{font:.82rem var(--mono);color:var(--mut);margin:1rem 0 0}
.plain{background:var(--pan);border:1px solid var(--bd);border-radius:12px;padding:1.4rem 1.6rem;margin:2rem 0 0}
.plain h2{margin:0 0 .3rem;font-size:1.15rem}
.plain>p{margin:.2rem 0 1rem;color:#37414d}
.stack{margin:0;display:grid;gap:.7rem}
.stack div{display:grid;grid-template-columns:11rem 1fr;gap:1rem}
.stack dt{font-weight:700}.stack dd{margin:0;color:var(--mut)}
ol.toc{margin:2.2rem 0 0;padding:1rem 1.4rem 1rem 2.6rem;border:1px solid var(--bd);border-radius:10px;color:var(--ac2);font-size:.95rem}
ol.toc li{margin:.2rem 0}
h2.sec{font-size:1.5rem;letter-spacing:-.4px;margin:2.8rem 0 .6rem;padding-top:.6rem;border-top:1px solid var(--bd)}
h3{font-size:1.12rem;margin:1.8rem 0 .3rem}
p.blurb{color:var(--mut);margin:.2rem 0 .8rem}
.keywords{font-family:var(--mono);font-weight:700;color:var(--fg)}
.normbox{border-left:3px solid var(--ac);background:#fff8f0;padding:.8rem 1.1rem;margin:1rem 0;border-radius:0 8px 8px 0}
table{width:100%;border-collapse:collapse;margin:.6rem 0 0;font-size:.9rem}
th,td{text-align:left;padding:.5rem .7rem;border-top:1px solid var(--bd);vertical-align:top}
thead th{border-top:none;border-bottom:2px solid var(--bd);font-size:.78rem;text-transform:uppercase;letter-spacing:.04em;color:var(--mut)}
table.rules .rid{font-family:var(--mono);font-size:.8rem;white-space:nowrap;color:var(--ac)}
table.rules .rbip{font-family:var(--mono);font-size:.8rem;color:var(--mut);white-space:nowrap}
table.rules .rerr{font-family:var(--mono);font-size:.78rem;color:var(--mut)}
.vfile{font-family:var(--mono);font-size:.82rem;white-space:nowrap}
code{font-family:var(--mono);font-size:.88em;background:var(--pan);padding:.1em .35em;border-radius:4px}
ul.refs{padding-left:1.3rem}ul.refs li{margin:.3rem 0}
footer{border-top:1px solid var(--bd);margin-top:3rem;padding:2rem 0;color:var(--mut);font:.82rem/1.6 var(--mono)}
@media(max-width:600px){h1{font-size:1.9rem}.stack div{grid-template-columns:1fr;gap:.1rem}}
</style>
</head>
<body>
<nav><div class="in">
<a href="./index.html" class="brand">bitcoin<b>·</b>kernel</a>
<a href="./index.html">Test suite</a>
<a href="./random.html">Verify a block</a>
<a href="./cache.html">Your node</a>
<a href="./spec.html" class="on">Specification</a>
<a href="https://github.com/bitcoin-kernel/bitcoin-kernel.github.io">Source ↗</a>
</div></nav>
<main>
<header class="doc">
<div class="kicker">Specification</div>
<h1>bitcoin-kernel</h1>
<p class="tagline">A conformance specification for Bitcoin's consensus rules.</p>
<p class="docmeta">Engine v0.0.24 · 34 rules · generated from the source ruleset · living document</p>
</header>
<section class="plain">
<h2>In plain terms</h2>
<p>This is a standard, in the ordinary sense. It has the same parts a web or internet standard has.</p>
<dl class="stack">
<div><dt>The rules</dt><dd>What makes a Bitcoin header, block and payment valid. 34 of them, listed in §4.</dd></div>
<div><dt>The specification</dt><dd>This document. The rules in §4 are generated from the machine-readable ruleset, so the words here and the running code cannot drift apart.</dd></div>
<div><dt>The test suite</dt><dd>Real test vectors that exercise the rules, including Bitcoin Core's own script vectors (§5).</dd></div>
<div><dt>Conformance</dt><dd>An implementation conforms if it agrees with every vector. Pass them all and you conform (§3).</dd></div>
<div><dt>Implementations</dt><dd>bitcoin-kernel, a library that runs these rules on Node and in the browser (§6). Others may follow.</dd></div>
<div><dt>The demo</dt><dd>The whole suite, run live in your browser, on the <a href="./index.html">home page</a>.</dd></div>
</dl>
</section>
<ol class="toc">
<li><a href="#abstract">Abstract</a></li>
<li><a href="#status">Status of this document</a></li>
<li><a href="#conformance">Conformance</a></li>
<li><a href="#rules">Rules</a></li>
<li><a href="#vectors">Test vectors</a></li>
<li><a href="#implementations">Implementations</a></li>
<li><a href="#references">References</a></li>
</ol>
<h2 class="sec" id="abstract">1. Abstract</h2>
<p>This document specifies the consensus rules a Bitcoin full node applies when deciding whether to accept a block, together with a conformance test suite. It exists so that independent implementations can be checked against a single, machine-readable definition of the rules. The normative rules in §4 are generated directly from the engine's source-of-truth ruleset (<a href="./engine/schema/validate.jsonld"><code>validate.jsonld</code></a>); the test vectors in §5 are run, in full, by the <a href="./index.html">live demo</a>.</p>
<h2 class="sec" id="status">2. Status of this document</h2>
<p>This is a living document, generated from source on each build. It is an independent community project and is <strong>not affiliated with, nor endorsed by, Bitcoin Core or the Bitcoin project</strong>. It describes the rules as implemented by bitcoin-kernel, an independent implementation, and is offered as a cross-check, not as a replacement for Bitcoin Core. Where this document and the Bitcoin network disagree, the network is correct and this document is in error.</p>
<h2 class="sec" id="conformance">3. Conformance</h2>
<p>The key words <span class="keywords">MUST</span>, <span class="keywords">MUST NOT</span>, <span class="keywords">REQUIRED</span>, <span class="keywords">SHALL</span>, <span class="keywords">SHOULD</span>, and <span class="keywords">MAY</span> in this document are to be interpreted as described in RFC 2119.</p>
<div class="normbox">
<p>An implementation <span class="keywords">conforms</span> to this specification if and only if, for every test vector defined in §5, the verdict it computes (<em>accept</em> or <em>reject</em>) equals that vector's expected verdict.</p>
</div>
<p>A conforming validator <span class="keywords">MUST</span> implement every rule in §4. It <span class="keywords">MUST</span> reject any header, block, or transaction that a normative rule rejects, and <span class="keywords">MUST NOT</span> reject one that every applicable rule accepts. A conforming validator <span class="keywords">SHOULD</span> demonstrate conformance by running the test suite; the live demo does so in the browser and reports any divergence. Rules marked with a BIP <span class="keywords">MUST</span> be enforced only at and after that BIP's activation height, as the corresponding rule records.</p>
<h2 class="sec" id="rules">4. Rules</h2>
<p>Each rule below is normative. A conforming validator <span class="keywords">MUST</span> enforce it. Rules are grouped by the stage at which a node applies them, and each carries its originating BIP, where one exists, and the error code a node raises when the rule is violated.</p>
<h3 id="rules-header">4.1 Header rules</h3>
<p class="blurb">Constraints every block header must satisfy: it links to the previous block, its proof of work meets the target, its timestamp is within range, its version is allowed at that height, and its difficulty is correct, including the testnet4 timewarp fix.</p>
<table class="rules"><thead><tr><th>Rule</th><th>Requirement</th><th>BIP</th><th>Error code</th></tr></thead><tbody><tr><td class="rid">rule-header-prev-link</td><td>The header's prevBlockHash must equal the hash of the preceding header, extending a known chain.</td><td class="rbip"></td><td class="rerr">bad-prevblk</td></tr><tr><td class="rid">rule-header-pow</td><td>The header's hash, interpreted as a 256-bit number, must not exceed the target encoded by its bits field.</td><td class="rbip"></td><td class="rerr">high-hash</td></tr><tr><td class="rid">rule-header-difficulty</td><td>The bits field must equal the expected target: unchanged within a difficulty epoch; at each 2016-block boundary, retargeted by the previous epoch's actual timespan (clamped to [targetTimespan/4, targetTimespan*4]), never easier than powLimit.</td><td class="rbip"></td><td class="rerr">bad-diffbits</td></tr><tr><td class="rid">rule-header-mtp</td><td>The header's timestamp must be strictly greater than the median timestamp of the previous 11 blocks.</td><td class="rbip"></td><td class="rerr">time-too-old</td></tr><tr><td class="rid">rule-header-time-future</td><td>The header's timestamp must be no more than maxFutureBlockTime (2 hours) ahead of network-adjusted time.</td><td class="rbip"></td><td class="rerr">time-too-new</td></tr><tr><td class="rid">rule-header-version</td><td>Obsolete block versions are rejected once the corresponding deployment is buried: version >= 2 from params.bip34Height, >= 3 from params.bip66Height, >= 4 from params.bip65Height.</td><td class="rbip">BIP 34, 66, 65</td><td class="rerr">bad-version</td></tr><tr><td class="rid">rule-header-timewarp</td><td>On networks with the timewarp fix (testnet4), the first block of a difficulty epoch may not be timestamped more than params.maxTimewarp (600s) before its predecessor, closing the timewarp difficulty exploit. Skipped on networks without the fix.</td><td class="rbip">BIP 94</td><td class="rerr">time-timewarp-attack</td></tr></tbody></table>
<h3 id="rules-transaction">4.2 Transaction rules</h3>
<p class="blurb">Standalone validity of a transaction: it has at least one input and one output, no value exceeds the 21 million coin limit, and it never spends the same output twice.</p>
<table class="rules"><thead><tr><th>Rule</th><th>Requirement</th><th>BIP</th><th>Error code</th></tr></thead><tbody><tr><td class="rid">rule-tx-inputs-nonempty</td><td>inputs-nonempty</td><td class="rbip"></td><td class="rerr">bad-txns-vin-empty</td></tr><tr><td class="rid">rule-tx-outputs-nonempty</td><td>outputs-nonempty</td><td class="rbip"></td><td class="rerr">bad-txns-vout-empty</td></tr><tr><td class="rid">rule-tx-size</td><td>A single transaction may not exceed the block weight limit.</td><td class="rbip"></td><td class="rerr">bad-txns-oversize</td></tr><tr><td class="rid">rule-tx-output-values</td><td>Each output value must be in [0, maxMoney], and so must their sum.</td><td class="rbip"></td><td class="rerr">bad-txns-vout-toolarge</td></tr><tr><td class="rid">rule-tx-inputs-unique</td><td>No two inputs of a transaction may spend the same outpoint.</td><td class="rbip"></td><td class="rerr">bad-txns-inputs-duplicate</td></tr><tr><td class="rid">rule-tx-prevouts</td><td>A coinbase has exactly one input with the null outpoint; a non-coinbase transaction must have no null outpoints.</td><td class="rbip"></td><td class="rerr">bad-txns-prevout-null</td></tr><tr><td class="rid">rule-tx-coinbase-script</td><td>A coinbase scriptSig must be between 2 and 100 bytes. Skipped for non-coinbase transactions.</td><td class="rbip"></td><td class="rerr">bad-cb-length</td></tr></tbody></table>
<h3 id="rules-block">4.3 Block rules</h3>
<p class="blurb">Internal consistency of a block: exactly one coinbase, placed first; the merkle root commits to every transaction; no duplicate transaction ids; and the size and signature-operation budgets are respected.</p>
<table class="rules"><thead><tr><th>Rule</th><th>Requirement</th><th>BIP</th><th>Error code</th></tr></thead><tbody><tr><td class="rid">rule-block-coinbase-first</td><td>The block must be non-empty and its first transaction must be the coinbase.</td><td class="rbip"></td><td class="rerr">bad-cb-missing</td></tr><tr><td class="rid">rule-block-coinbase-single</td><td>No transaction after the first may be a coinbase.</td><td class="rbip"></td><td class="rerr">bad-cb-multiple</td></tr><tr><td class="rid">rule-block-merkle-root</td><td>The merkle root recomputed from the transactions' txids must equal the header's.</td><td class="rbip"></td><td class="rerr">bad-txnmrklroot</td></tr><tr><td class="rid">rule-block-tx-duplicates</td><td>No two transactions in the block may share a txid (guards the merkle mutation of CVE-2012-2459).</td><td class="rbip"></td><td class="rerr">bad-txns-duplicate</td></tr><tr><td class="rid">rule-block-sigops</td><td>Total legacy signature operations (CHECKSIG counts 1, CHECKMULTISIG counts 20, over all scriptSigs and scriptPubKeys) times the witness scale factor (4) may not exceed params.maxBlockSigopsCost.</td><td class="rbip"></td><td class="rerr">bad-blk-sigops</td></tr><tr><td class="rid">rule-block-weight</td><td>weight-limit</td><td class="rbip"></td><td class="rerr">bad-blk-weight</td></tr><tr><td class="rid">rule-block-transactions</td><td>Every transaction in the block passes the transaction phase.</td><td class="rbip"></td><td class="rerr">bad-txns</td></tr></tbody></table>
<h3 id="rules-block-context">4.4 Contextual block rules</h3>
<p class="blurb">Validity of a block against the chain state it extends: coinbase height and maturity, timelocks and sequence locks, every input unspent and available, non-negative fees, the witness commitment, and successful execution of every input script.</p>
<table class="rules"><thead><tr><th>Rule</th><th>Requirement</th><th>BIP</th><th>Error code</th></tr></thead><tbody><tr><td class="rid">rule-blockctx-bip34-height</td><td>The coinbase scriptSig must begin with a push of the block height. Active from params.bip34Height.</td><td class="rbip">BIP 34</td><td class="rerr">bad-cb-height</td></tr><tr><td class="rid">rule-blockctx-finality</td><td>Every transaction must be final at this block: lockTime of zero, or lockTime below the block height (if < 500,000,000) or below the median-time-past (otherwise), or all input sequences final (0xffffffff).</td><td class="rbip">BIP 113</td><td class="rerr">bad-txns-nonfinal</td></tr><tr><td class="rid">rule-blockctx-sequence-locks</td><td>BIP68 relative lock-time (enforced via BIP112). For a transaction of version >= 2, each input whose nSequence leaves the disable flag (bit 31) clear imposes a relative lock on the coin it spends. Height-based locks (type flag, bit 22, clear) require spendingHeight >= coinHeight + (nSequence & 0xffff). Time-based locks (bit 22 set) require (nSequence & 0xffff) << 9 seconds to have elapsed since the spent coin's median-time-past; that per-coin time context is not available to a light or pruned validator, so time-based locks are skipped honestly rather than guessed. A height-based lock whose coin height is unknown (out-of-window) is likewise skipped. Coinbase transactions and version-1 transactions are exempt.</td><td class="rbip">BIP 68, 112</td><td class="rerr">bad-txns-nonfinal</td></tr><tr><td class="rid">rule-blockctx-inputs-available</td><td>Every non-coinbase input must spend a coin that exists and is unspent at this point in the block's execution (no double spends within or across the block's transactions).</td><td class="rbip"></td><td class="rerr">bad-txns-inputs-missingorspent</td></tr><tr><td class="rid">rule-blockctx-coinbase-maturity</td><td>A coinbase coin may be spent only at least params.coinbaseMaturity (100) blocks after its creation. In a pruned window the rule fails on a provably premature spend of a window coinbase; spends of out-of-window coinbase coins, whose height is unknowable, skip.</td><td class="rbip"></td><td class="rerr">bad-txns-premature-spend-of-coinbase</td></tr><tr><td class="rid">rule-blockctx-fees</td><td>For every non-coinbase transaction, the sum of input values must be at least the sum of output values.</td><td class="rbip"></td><td class="rerr">bad-txns-in-belowout</td></tr><tr><td class="rid">rule-blockctx-coinbase-amount</td><td>The coinbase outputs may not exceed the block subsidy plus the block's total fees.</td><td class="rbip"></td><td class="rerr">bad-cb-amount</td></tr><tr><td class="rid">rule-blockctx-witness-commitment</td><td>If any transaction has witness data, the coinbase must carry a commitment output (OP_RETURN 0xaa21a9ed…) equal to dsha256(witnessMerkleRoot || witnessReservedValue). Active from params.segwitHeight.</td><td class="rbip">BIP 141</td><td class="rerr">bad-witness-merkle-match</td></tr><tr><td class="rid">rule-blockctx-scripts</td><td>Every resolvable non-coinbase input's unlocking script (and witness) must satisfy its prevout's locking script, with real signature verification: ECDSA for legacy/segwit-v0 paths (legacy and BIP 143 sighash) and Schnorr for taproot key and script paths (BIP 340/341/342). The only honest skips remaining are pruned-away prevouts (taproot additionally needs every input's prevout, as its sighash commits to all of them) and unknown future witness/leaf versions.</td><td class="rbip"></td><td class="rerr">mandatory-script-verify-flag-failed</td></tr></tbody></table>
<h3 id="rules-spv">4.5 Light client (SPV) rules</h3>
<p class="blurb">Verification of a merkle inclusion proof: a light client can confirm that a transaction is committed to by a block header without possessing the whole block.</p>
<table class="rules"><thead><tr><th>Rule</th><th>Requirement</th><th>BIP</th><th>Error code</th></tr></thead><tbody><tr><td class="rid">rule-spv-pow</td><td>The embedded header's hash must satisfy its own target. (Chain membership and cumulative work are established by the header phase.)</td><td class="rbip"></td><td class="rerr">high-hash</td></tr><tr><td class="rid">rule-spv-tree</td><td>The partial merkle tree must be well-formed: every hash and every flag bit consumed exactly once (modulo byte padding), no identical left/right branches (CVE-2012-2459), and a non-zero transaction count.</td><td class="rbip"></td><td class="rerr">bad-merkle-tree</td></tr><tr><td class="rid">rule-spv-merkle-root</td><td>The root reconstructed from the partial tree must equal the header's merkleRoot.</td><td class="rbip"></td><td class="rerr">bad-txnmrklroot</td></tr><tr><td class="rid">rule-spv-inclusion</td><td>The transaction being verified must appear among the proof's matched txids. Skipped when no target transaction is specified.</td><td class="rbip"></td><td class="rerr">tx-not-included</td></tr></tbody></table>
<h2 class="sec" id="vectors">5. Test vectors</h2>
<p>The test suite is the set of vectors below. They are vendored into this repository under <code>engine/vectors/</code> and are run, in full, by the <a href="./index.html">live demo</a>. An implementation conforms (§3) if it produces each vector's expected verdict.</p>
<table><thead><tr><th>Vector set</th><th>Description</th><th>Rules</th></tr></thead><tbody>
<tr><td class="vfile"><a href="./engine/vectors/script_tests.json">script_tests.json</a></td><td>Bitcoin Core's own script test vectors: valid and invalid spends, with the expected verdict for each. About 1,191 are run.</td><td class="vfile">§4.2, §4.4</td></tr>
<tr><td class="vfile"><a href="./engine/vectors/genesis-block.json">genesis-block.json</a></td><td>The Bitcoin genesis block: its header, proof of work, merkle root and coinbase.</td><td class="vfile">§4.1, §4.3</td></tr>
<tr><td class="vfile"><a href="./engine/vectors/retarget-32256.json">retarget-32256.json</a></td><td>The first difficulty retarget in Bitcoin history (block 32,256).</td><td class="vfile">§4.1</td></tr>
<tr><td class="vfile"><a href="./engine/vectors/retarget-modern.json">retarget-modern.json</a></td><td>A modern difficulty retarget (block 951,552).</td><td class="vfile">§4.1</td></tr>
<tr><td class="vfile"><a href="./engine/vectors/header-chain-100k.json">header-chain-100k.json</a></td><td>Consecutive mainnet headers around height 100,000, validated in sequence.</td><td class="vfile">§4.1</td></tr>
<tr><td class="vfile"><a href="./engine/vectors/pruned-window-100000.json">pruned-window-100000.json</a></td><td>A real mainnet block with its transactions, for structural and contextual checks.</td><td class="vfile">§4.3, §4.4</td></tr>
<tr><td class="vfile"><a href="./engine/vectors/merkleblock-block100000.json">merkleblock-block100000.json</a></td><td>A merkle inclusion proof for a transaction in block 100,000.</td><td class="vfile">§4.5</td></tr>
<tr><td class="vfile"><a href="./engine/vectors/merkleblock-first-segwit.json">merkleblock-first-segwit.json</a></td><td>A deeper merkle inclusion proof (the first-ever SegWit transaction).</td><td class="vfile">§4.5</td></tr>
</tbody></table>
<p>The script vectors are <a href="https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json">Bitcoin Core's own <code>script_tests.json</code></a>, used unmodified. The remaining vectors are real mainnet data, independently verifiable on any block explorer.</p>
<h2 class="sec" id="implementations">6. Implementations</h2>
<p><strong>bitcoin-kernel</strong> is the reference implementation: a JavaScript library, with no runtime dependencies, that implements every rule in §4. The same code runs on a Node server and in a browser tab; the <a href="./index.html">demo</a> runs it client-side. The interpreter and engine are at <a href="https://cdn.jsdelivr.net/gh/bitcoin-kernel/kernel@v0.0.2/packages/kernel/codec/interpreter.js"><code>engine/codec/</code></a> and developed in the open at <a href="https://github.com/bitcoin-desktop/schema">github.com/bitcoin-desktop/schema</a>.</p>
<p>An implementation in any language conforms to this specification (§3) if it produces the expected verdict for every vector in §5. Reporting partial conformance (for example, the script rules only) is <span class="keywords">RECOMMENDED</span> where full conformance is not yet reached.</p>
<h2 class="sec" id="references">7. References</h2>
<ul class="refs">
<li>S. Bradner, <a href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a>.</li>
<li><a href="https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json">Bitcoin Core, <code>src/test/data/script_tests.json</code></a> (the script test vectors).</li>
<li>Bitcoin Improvement Proposals referenced by the rules above:<ul class="refs"><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki">BIP 34</a></li><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki">BIP 65</a></li><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">BIP 66</a></li><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">BIP 68</a></li><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki">BIP 94</a></li><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">BIP 112</a></li><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">BIP 113</a></li><li><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">BIP 141</a></li></ul></li>
</ul>
</main>
<footer><div style="max-width:860px;margin:0 auto;padding:0 1.5rem">
Generated from <a href="./engine/schema/validate.jsonld">validate.jsonld</a> (engine v0.0.24). Independent community project, not affiliated with Bitcoin Core. <a href="./index.html">Test suite</a> · <a href="https://github.com/bitcoin-kernel/bitcoin-kernel.github.io">Source</a>
</div></footer>
</body>
</html>