Rust Bitcoin merged a small but useful documentation change on October 17: conversions to its new ScriptCode type borrow the entire script. That wording matters because a script used to authorize a Bitcoin payment and the script data included in its signature calculation are not always identical. The documentation follow-up makes that boundary more explicit.
It follows an October 13 merge introducing ScriptCode into signing interfaces. Together, the changes offer a useful case study in software reliability: a clearer interface can help developers recognize a mistake, while still leaving them responsible for supplying the right data.
These are verified development-branch changes. Their merge dates do not establish that any particular packaged wallet has incorporated them.
The signature depends on the message
Rust Bitcoin supplies building blocks for applications, including transaction, script, address and key handling. Its project documentation explicitly warns against using the library as a substitute for full consensus validation. That distinction helps place this update: it concerns how applications construct signing data, rather than a change to Bitcoin's network rules.
A transaction signature is checked against a digest assembled according to specific rules. For version-zero SegWit inputs, BIP143 defines that calculation. Among its components are the amount being spent and a piece of script data called scriptCode. Producing a signature with the right private key is insufficient if the application signed the wrong digest.
For a pay-to-witness-script-hash input, commonly abbreviated P2WSH, the witness script supplies the spending conditions. When it has no OP_CODESEPARATOR instruction, its full contents supply the scriptCode. With that instruction, the relevant bytes depend on execution: everything through the last separator executed before the signature check is excluded. Later separators remain. These are existing BIP143 requirements, not newly introduced restrictions.
The emphasis on execution is important. Finding the last separator in a file is not necessarily the same as identifying the last one executed before a particular check.
A better name cannot choose the execution path
An April design issue identified a related source of confusion: scriptCode was represented using a type named WitnessScriptBuf. The issue proposed distinguishing the concepts explicitly and discussed different implementation choices. Naming the data after its role makes the interface easier to reason about.
The October implementation adds ScriptCode and a specialized P2wpkhScriptCode, which holds the fixed 25-byte signing script for P2WPKH without heap allocation. It also changes the P2WSH signature-hash interface so callers can supply the relevant script portion. Existing witness-script arguments remain supported through conversions to the new type. Those details are recorded in the merged implementation.
But conversion does not determine which instructions executed. The October 17 clarification says it borrows the whole script; it does not promise to prepare a shortened signing script automatically. The practical inference is straightforward: developers should inspect the meaning of a conversion, rather than assume the new type proves that every required transformation occurred.
This was already recognized as an interface problem in the project's August issue, which called for better handling of separators in the SegWit signing API. The improvement gives applications a clearer way to express the correct answer. It cannot supply information about execution that the caller never provided.
What integration tests should establish
Our recommendation for application teams is to treat this as a signing-path review, not just a dependency bump. First identify which signing functions the application calls and which input types those paths support. Record the exact dependency version or commit used in the build.
Then test the boundary cases deliberately. BIP143 includes worked P2WSH examples and recommends testing implementations against its vectors. A useful integration test should compare the calculated digest with the expected value, then verify the signature for the intended spending path. Merely obtaining a signature object is a weaker result. BIP143 examples
Keep ordinary scripts and separator-bearing scripts in separate test cases, and make unsupported cases fail clearly. The goal is to prevent a convenient conversion from concealing an assumption that only holds for simpler inputs. These are editorial testing recommendations; no wallet builds were tested for this article.
For users evaluating an application's update notice, the useful questions are whether its signing paths needed adjustment, what regression tests cover them and which released build contains the work. A merged library change answers only part of that chain. The broader lesson is that reliable signing requires both correctly represented data and evidence that the application selected the right data to represent.