As described in CVE-2020-14199 it is unsafe to only rely on witness
UTXO information when signing. Hardware wallets fixed this by also
requiring the full non-witness UTXO to be present for a witness input.
To be compatible with those newer hardware wallet firmware, we need to
remove the sanity checks that disallowed setting witness and non-witness
UTXOs at the same time.
See https://github.com/bitcoin/bitcoin/pull/19215 for comparison which
removed the sanity checks in Bitcoin Core.
This commit fixes a panic when deserializing PSBTs in raw binary.
If the key type was SighashType and the value was not 4 bytes long,
the call to binary.LittleEndian.Uint32(value) would panic as the
function expects 4 bytes to parse into a uint32. We now perform a
sanity check that asserts that the value is 4 bytes long.
This is a fix/workaround for a special case that's caused by
https://github.com/btcsuite/btcd/blob/master/wire/msgtx.go#L426.
When a wire format transaction with no inputs is serialized, the wire
package assumes it's a non-witness transaction (as there is indeed no
witness data present).
But when de-serializing the same transaction, the line mentioned above
assumes that for the special case of a zero input length, the
transaction must be in the witness format, which causes the
de-serialization to fail.
The workaround in this commit fixes this special case by just trying
to deserialize the transaction in the non-witness format too.
In this commit, we modify the Extract method to return the transaction
directly as in many cases a user will likely want to write the
transaction to disk, or perform additional validation rather than obtain
the raw bytes directly.
The creator struct really didn't do anything before, as a result in this
commit we move to get rid of it, and create a `New` method as
customarily used in go packages.
This commit removes the uint64Slice type and performs sorting during
filter construction and ZipMatchAny using sort.Slice. The benchmarks
indicated that this speeds up BuildGCSFilter and ZipMatchAny by 10-12%,
likely to the overhead of needing to resolve the sort.Interface methods.
The benchmarks indicate that this improvement is not present for the
smallest query size in our benchmarks, i.e. 100 elements, but the
reduction is only about 3%. This would indicate the at these small
values, the use of reflection is actually slightly slower than interface
method resolution in total.
