P2WPKH outputs are a similar case as P2PK outputs in that inputs that spend them
cannot be matched by a bloom filter: their scriptSig is empty and their witness
(which would contain a matching pubkey) is not tested for a match. This is a
shortcoming of the SegWit spec.
Hopefully this fixes https://github.com/bitcoinj/bitcoinj/issues/1690
Coin selection is a per SendRequest, per createSend() or per getBalance() call affair.
Having it wallet-global can lead to race conditions, as sometimes experienced in the
WalletTest unit tests.
This allows usage in both wallettemplate and tools and replaces
similar code in BlockFileLoader.java in core.
Requires minor back-port of Path.of() functionality from JDK11.
The checkState() on ScriptChunk.decodeOpN() was excessively strict: it excluded OP_0. As the method calls Script.decodeFromOpN(), which itself has a check on the passed-in opcode, we simply remove the check entirely.
No code in bitcoinj was calling ScriptChunk.decodeOpN().
The startLocationInProgram field of ScriptChunk was used as a caching mechanism for storing the location of each ScriptChunk in a Script. This was memory-inefficient, as this integer was only actually used during interpretation of OP_CODESEPARATOR. Furthermore, it was dangerous and inconsistent: the ScriptBuilder methods, for example, do not properly set startLocationInProgram, leading to a potential runtime failure when interpreting ScriptBuilder-constructed Scripts.
Rather than caching each chunk's location, we add a method called size() that efficiently returns the size of a serialized ScriptChunk. During Script interpretation, we use this method to track the program counter.
Additionally, we add an exhaustive test to ensure that size() properly returns the size of a serialized ScriptChunk.
This will break any code that relied on ScriptChunk.getStartLocationInProgram().
This bug was never exposed outside the SegwitAddress class (and thus can't be tested) because the encode method is only ever called by fromHash, where the script version is always set to 0.
Nevertheless, this bug could result in faults in future code, as other witness program versions begin to be used: The other construction methods, such as fromBech32(), leave the version byte as a simple representation of the version number. This means that, were the SegwitAddress constructor ever called with a non-0 version number, getWitnessVersion() would return an incorrect result, and ScriptBuilder.createOutputScript() would fail, re-running encodeToOpN() on the now greater-than-16 version byte.
