@smartledger/bsv 9.16.0 → 9.18.0

package/CHANGELOG.md

@@ -7,6 +7,195 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [9.18.0] - 2026-10-03
+
+9.17.0 was committed but never published to npm; its contents are included here. The version
+number is skipped on the registry rather than reused, so a reader comparing git to npm cannot find
+two different 9.17.0s.
+
+### Fixed — `NotaryHash.verifySignature` reported a missing `createdAt` as a signature failure
+
+It derived its inputs from `Certificate.toProofInput`, which also decodes `createdAt` because the
+proofHash commits to the creation time. **The signature does not.** So on a certificate with no
+`createdAt`, `toUnixSeconds(undefined)` threw, the function's `try/catch` turned that into `false`,
+and the caller was told the signature did not match its payloadHash and public key.
+
+That is the one answer a caller cannot act on correctly. `verifySignature` returning `false` means
+exactly one thing to every reader — the cryptography does not check out — so the remedy they reach
+for is their key, their digest convention or their endian handling. On this library that has
+historically been the right place to look, which makes the misdirection worse rather than better.
+
+The regression arrived with the BRC-220 reference format work; 9.3.0 answered `true` for all of
+these. Measured, identical inputs:
+
+| certificate | 9.3.0 | 9.16.1 | 9.18.0 |
+|---|---|---|---|
+| no `createdAt` | true | **false** | true |
+| with `createdAt` | true | true | true |
+| `anchor: {txid}`, no `createdAt` | true | **false** | true |
+| `anchor: {}`, no `createdAt` | true | **false** | true |
+
+`Certificate.toSignatureInput` now returns only the five fields a signature check uses, and
+`toProofInput` builds on it by adding `createdAtUnix`. Nothing that should fail now passes: a
+signature over a different digest, a different public key, a flipped byte, a truncated signature
+and a certificate missing `signature`, `publicKey` or `payloadHash` are all still `false`.
+**Certificate completeness is unchanged** — `Certificate.validateShape` lists every missing
+required field by name, and `NotaryHash.verify` runs it first and returns before the signature
+check, so a certificate with no `createdAt` is still not a valid certificate.
+
+### Added — `NotaryHash.verifySignatureOnly(payloadHash, signature, publicKey, algorithm?)`
+
+For the case that exposed the bug: verifying a submitted signature **before** spending anything to
+anchor it, when no certificate exists yet and so there is no `createdAt`, `proofHash` or `anchor`.
+Certificate metadata cannot influence the answer because none is passed.
+
+It takes Buffers or hex, and **throws** on input it cannot decode rather than returning `false`. A
+boolean that means both "the signature does not match" and "your hex was malformed" is the
+ambiguity this entry point exists to remove, and a pre-flight check is where acting on the wrong
+one costs money.
+
+Reported with a complete reproduction by the ordinals mint that anchors BRC-220 proofs, which hit
+it as a pre-anchor check rejecting every valid submission with a 400.
+
+## [9.17.0] - 2026-10-03
+
+### Deprecated — `Script.fromHex` accepts a string that does not decode whole
+
+`Buffer.from(str, 'hex')` stops at the first character it cannot decode — including the trailing
+nibble of an odd-length string — and returns what it had. So `Script.fromHex` has always answered
+a malformed string with a **shorter script, or none, and no error**:
+
+```js
+Script.fromHex('<html>503</html>')        // 0 bytes
+Script.fromHex('76a91')                   // 2 bytes, the last nibble dropped
+Script.fromHex('<p2pkh hex>' + '\nmore')  // the 25-byte prefix, still a valid P2PKH
+```
+
+A caller that builds an output from the result pays to a truncated script with nothing to tell it,
+and `Transaction#addOutput` accepts a zero-byte script without complaint. `Script.fromString`,
+directly below it in the source, has always refused non-hex with `JSUtil.isHexa`; this function
+never did.
+
+The damage is bounded in one useful way: **truncation can only drop a suffix.** It cannot alter the
+bytes it did decode, so an address derived from the result is always the one the input's leading
+bytes named, never a third party's. That makes this a correctness problem rather than a theft one.
+
+A string that does not decode whole now emits a deprecation notice naming the replacement, once per
+process. **Nothing throws and no verdict changes**; the notice is the whole change. `10.0.0` will
+refuse it, which under STABILITY.md cannot land before 2027-09-01.
+
+Callers wanting the strict behaviour today should check the round trip, which separates every
+truncating input from every whole one:
+
+```js
+if (Script.fromHex(h).toHex() !== h.toLowerCase()) throw new Error('not whole hex')
+```
+
+Found while answering a downstream consumer about an upgrade: its paymail resolver passes a remote
+host's string to `Script.fromHex`. That consumer was not exposed — it gates the result on
+`isPublicKeyHashOut()` — but it had no help from this library in getting there.
+
+
+### Changed — `@noble/curves`, `@noble/hashes` and `@noble/ciphers` to `^2.4.0`
+
+The declared range was already `^2.3.0`, so a fresh consumer install had been resolving 2.4.0
+while the shipped bundles still inlined 2.3.0. This release realigns them: the floor moves to
+`^2.4.0` and the bundles are a reproducible build of it. All three declare `engines` of
+`node >= 20.19.0`, unchanged, so the supported runtime floor does not move. Five bundles grew by
+2-3 KB.
+
+## [9.16.1] - 2026-10-01
+
+Three resource and validation defects in the shift and binary-conversion opcodes, found by a
+differential fuzzer run against this package and by independent review of the first fix. The
+conformance corpus passes 1483/1483 before and after: every one of these was invisible to it.
+
+### Security — `OP_LSHIFT` and `OP_RSHIFT` did work proportional to the shift COUNT
+
+Both built the shifted value as a bignum and then truncated it, so `ushln(n)` allocated a value of
+the shifted width — the count's magnitude, not the operand's. A short script could therefore buy
+an unbounded amount of work from a verifier, in **every era**, since a count of 2^31-1 fits the
+four bytes allowed before Genesis, and `IsOpcodeDisabled` in the node disables only `OP_2MUL`
+and `OP_2DIV` — never the shifts. Confirmed by execution: a pre-Genesis `OP_LSHIFT` with a count
+of 2^31-1 is accepted and returns one zero byte. Past a certain count the implied length is not a valid array
+length and bn.js raised a `RangeError`, which the evaluator reported as
+`SCRIPT_ERR_UNKNOWN_ERROR`. **That is a false reject**, not merely a slow one: the node returns
+zero bytes for the same script, so this library refused spends the node accepts. So the path had
+two faults at once — unbounded work, and a wrong verdict in the direction of refusal. No false
+accept was found on this path; the false accept in this release is the separate empty-operand bug
+below.
+
+Both opcodes now follow the node's shape, which bounds the work by the operand:
+
+```cpp
+CScriptNum n{top, requireMinimal, params.MaxScriptNumLength(), utxo_after_genesis};
+if(n < 0) return SCRIPT_ERR_INVALID_NUMBER_RANGE;
+if(n >= values.size() * bits_per_byte) fill(begin(values), end(values), 0);
+else { ... LShift(values, n.getint()) ... }
+```
+
+The count is compared as a bignum before any narrowing, and a shift reaching the operand's full
+width returns that many zero bytes directly. The node's `LShift` allocates
+`valtype result(x.size(), 0x00)` and loops over `x.size()`; nothing it allocates follows the
+count. Verified against the previous implementation on 719,360 operand-and-count pairs — every value at
+operand lengths 1 to 4, sampled above 4096 per length, at every count from 0 to 8·len+4, both
+directions — and against an independent bit-string model. That equivalence covers the **valid
+counts for which the previous implementation completed**, and over those the output is
+byte-identical. It deliberately does not cover the counts that previously threw, or the
+empty-operand counts in the next section, where the verdict changes on purpose; both are covered
+by their own tests.
+
+### Security — an invalid shift count was accepted whenever the operand was empty
+
+Both opcodes short-circuited when the value being shifted was empty, popping the count without
+decoding it, and therefore without any of its three checks. A negative count, a count too wide for
+the era, and a non-minimally-encoded count were all accepted, where the node refuses each by name.
+**A false accept.** The node's only guard before the decode is `stack.size() < 2`, and it checks
+`n < 0` before it reads the operand at all.
+
+This one was found by review of the first shift fix, which corrected the cost and left this in
+place.
+
+### Fixed — `OP_NUM2BIN`'s size was not bounded by `INT32_MAX`
+
+The node caps it in every era, **before** the element-size test:
+
+```cpp
+if(n < 0 || n > std::numeric_limits<int32_t>::max()) return SCRIPT_ERR_PUSH_SIZE;
+const auto size{n.to_size_t_limited()};
+if(!utxo_after_genesis && (size > MAX_SCRIPT_ELEMENT_SIZE_BEFORE_GENESIS))
+    return SCRIPT_ERR_PUSH_SIZE;
+```
+
+The era only widens the second test; the first is fixed. Without it a size above `INT32_MAX`
+passed the post-Genesis element check, which is effectively unbounded, and the allocation that
+followed was proportional to the operand's **value** rather than its length. A size the node
+refuses without allocating is now refused the same way, and the bound is checked on the bignum
+before narrowing, because `toNumber()` rounds past 2^53 and returns `Infinity` at extreme widths
+rather than failing.
+
+**This cap matches the node; it does not make the opcode cheap.** A size just under `INT32_MAX` is
+consensus-valid and still requests an allocation approaching 2 GB, from a script of a few bytes —
+so a limit on script size does not address it. **This release adds no execution or allocation
+budget, and this package enforces none.** Evaluating untrusted scripts therefore needs a bound on
+execution resources, not just on input size: run it in a process whose memory and CPU time are
+capped, or do not evaluate untrusted scripts in a process you need to keep alive.
+
+### Note on `OP_DIV` and `OP_MOD`
+
+Both are quadratic in operand length. **This is not a consensus divergence, and it is not fixed in
+this release.** The node shares the shape: `OP_DIV`/`OP_MOD` are bounded only by
+`params.MaxScriptNumLength()` and its `bsv::bint` division is also schoolbook, so verdicts and
+bounds match and changing ours would diverge from consensus.
+
+Parity settles the verdict, not the cost. **Quadratic CPU exhaustion remains a risk when
+evaluating attacker-controlled scripts**, and the node's practical protection is policy rather
+than consensus — `DEFAULT_MAX_SCRIPT_SIZE_POLICY_AFTER_GENESIS` of 500 KB and
+`DEFAULT_STACK_MEMORY_USAGE_POLICY_AFTER_GENESIS` of 100 MB. Neither is a CPU-time bound, and this
+package enforces neither. Measured here: 320 KB of operand takes about 18 seconds, growing by
+roughly 4× per doubling. Bound execution resources yourself, as above. An opt-in budget is under
+consideration and will not change default behaviour.
+
 ## [9.16.0] - 2026-10-01
 
 ### Security — `OP_CHECKMULTISIG`'s counts were decoded with the era's length, not four bytes

package/README.md

@@ -2,7 +2,7 @@
 
 Bitcoin SV library with an interpreter-verified script engine.
 
-[![Version](https://img.shields.io/badge/version-9.16.0-blue.svg)](https://www.npmjs.com/package/@smartledger/bsv)
+[![Version](https://img.shields.io/badge/version-9.18.0-blue.svg)](https://www.npmjs.com/package/@smartledger/bsv)
 [![License](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE)
 [![Stability](https://img.shields.io/badge/9.x%20stable%20until-2027--09--01-brightgreen.svg)](STABILITY.md)
 
@@ -155,44 +155,44 @@ const bsv = require('@smartledger/bsv')                 // 128 modules
 ### **Core Modules**
 | Module | Size | Use Case | CDN |
 |--------|------|----------|-----|
-| **bsv.min.js** | 1062KB | Core BSV + SmartContract | `unpkg.com/@smartledger/bsv@9.16.0/bsv.min.js` |
-| **bsv.bundle.js** | 1062KB | Everything in one file | `unpkg.com/@smartledger/bsv@9.16.0/bsv.bundle.js` |
+| **bsv.min.js** | 1065KB | Core BSV + SmartContract | `unpkg.com/@smartledger/bsv@9.18.0/bsv.min.js` |
+| **bsv.bundle.js** | 1065KB | Everything in one file | `unpkg.com/@smartledger/bsv@9.18.0/bsv.bundle.js` |
 
 ### **W3C Verifiable Credentials**
 | Module | Size | Use Case | CDN |
 |--------|------|----------|-----|
-| **🟢 bsv-didweb.min.js** | 166KB | **DID:web generation** | `unpkg.com/@smartledger/bsv@9.16.0/bsv-didweb.min.js` |
-| **🟢 bsv-vcjwt.min.js** | 166KB | **VC-JWT issue/verify** | `unpkg.com/@smartledger/bsv@9.16.0/bsv-vcjwt.min.js` |
-| **🟢 bsv-statuslist.min.js** | 256KB | **StatusList2021 revocation** | `unpkg.com/@smartledger/bsv@9.16.0/bsv-statuslist.min.js` |
-| **🟢 bsv-anchor.min.js** | 164KB | **BSV anchoring (hash-only)** | `unpkg.com/@smartledger/bsv@9.16.0/bsv-anchor.min.js` |
+| **🟢 bsv-didweb.min.js** | 166KB | **DID:web generation** | `unpkg.com/@smartledger/bsv@9.18.0/bsv-didweb.min.js` |
+| **🟢 bsv-vcjwt.min.js** | 166KB | **VC-JWT issue/verify** | `unpkg.com/@smartledger/bsv@9.18.0/bsv-vcjwt.min.js` |
+| **🟢 bsv-statuslist.min.js** | 256KB | **StatusList2021 revocation** | `unpkg.com/@smartledger/bsv@9.18.0/bsv-statuslist.min.js` |
+| **🟢 bsv-anchor.min.js** | 164KB | **BSV anchoring (hash-only)** | `unpkg.com/@smartledger/bsv@9.18.0/bsv-anchor.min.js` |
 
 ### **Smart Contract & Development**
 | Module | Size | Use Case | CDN |
 |--------|------|----------|-----|
-| **bsv-smartcontract.min.js** | 141KB | Complete covenant framework | `unpkg.com/@smartledger/bsv@9.16.0/bsv-smartcontract.min.js` |
-| **bsv-covenant.min.js** | 35KB | Covenant operations | `unpkg.com/@smartledger/bsv@9.16.0/bsv-covenant.min.js` |
-| **bsv-script-helper.min.js** | 33KB | Custom script tools | `unpkg.com/@smartledger/bsv@9.16.0/bsv-script-helper.min.js` |
-| **bsv-security.min.js** | 32KB | Security enhancements | `unpkg.com/@smartledger/bsv@9.16.0/bsv-security.min.js` |
+| **bsv-smartcontract.min.js** | 141KB | Complete covenant framework | `unpkg.com/@smartledger/bsv@9.18.0/bsv-smartcontract.min.js` |
+| **bsv-covenant.min.js** | 35KB | Covenant operations | `unpkg.com/@smartledger/bsv@9.18.0/bsv-covenant.min.js` |
+| **bsv-script-helper.min.js** | 33KB | Custom script tools | `unpkg.com/@smartledger/bsv@9.18.0/bsv-script-helper.min.js` |
+| **bsv-security.min.js** | 32KB | Security enhancements | `unpkg.com/@smartledger/bsv@9.18.0/bsv-security.min.js` |
 
 ### **Legal & Compliance**
 | Module | Size | Use Case | CDN |
 |--------|------|----------|-----|
-| **bsv-ltp.min.js** | 542KB | Legal Token Protocol | `unpkg.com/@smartledger/bsv@9.16.0/bsv-ltp.min.js` |
-| **bsv-gdaf.min.js** | 1062KB | Digital Identity & Attestation | `unpkg.com/@smartledger/bsv@9.16.0/bsv-gdaf.min.js` |
+| **bsv-ltp.min.js** | 544KB | Legal Token Protocol | `unpkg.com/@smartledger/bsv@9.18.0/bsv-ltp.min.js` |
+| **bsv-gdaf.min.js** | 1065KB | Digital Identity & Attestation | `unpkg.com/@smartledger/bsv@9.18.0/bsv-gdaf.min.js` |
 
 ### **Advanced Cryptography**
 | Module | Size | Use Case | CDN |
 |--------|------|----------|-----|
-| **bsv-shamir.min.js** | 177KB | Threshold Cryptography | `unpkg.com/@smartledger/bsv@9.16.0/bsv-shamir.min.js` |
+| **bsv-shamir.min.js** | 177KB | Threshold Cryptography | `unpkg.com/@smartledger/bsv@9.18.0/bsv-shamir.min.js` |
 
 ### **Utilities**
 | Module | Size | Use Case | CDN |
 |--------|------|----------|-----|
-| **bsv-ecies.min.js** | 137KB | Encryption | `unpkg.com/@smartledger/bsv@9.16.0/bsv-ecies.min.js` |
-| **bsv-message.min.js** | 34KB | Message signing | `unpkg.com/@smartledger/bsv@9.16.0/bsv-message.min.js` |
-| **bsv-mnemonic.min.js** | 320KB | HD wallets | `unpkg.com/@smartledger/bsv@9.16.0/bsv-mnemonic.min.js` |
+| **bsv-ecies.min.js** | 139KB | Encryption | `unpkg.com/@smartledger/bsv@9.18.0/bsv-ecies.min.js` |
+| **bsv-message.min.js** | 34KB | Message signing | `unpkg.com/@smartledger/bsv@9.18.0/bsv-message.min.js` |
+| **bsv-mnemonic.min.js** | 320KB | HD wallets | `unpkg.com/@smartledger/bsv@9.18.0/bsv-mnemonic.min.js` |
 ```html
-<script src="https://unpkg.com/@smartledger/bsv@9.16.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.18.0/bsv.min.js"></script>
 <script>
   const key = bsv.PrivateKey.fromRandom()
 </script>
@@ -240,4 +240,4 @@ MIT
 
 ---
 
-**SmartLedger-BSV v9.16.0**
+**SmartLedger-BSV v9.18.0**