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.
In this commit, we decrease the default fp rate to 19, or 1/2^19. We do
this as recent analysis by sipa on the bitcoin dev mailing list has
shown that optimally, we can use a value of 2^19 for the fp rate, while
use n=1.497137*2^P rather than n directly. As a result, we can shrink
the filter size by quite a bit, while still maintaining a sane false
positive value.
A bug was recently fixed in btcec wherein we would fail to detect
invalid point decompressions for the curve. This how now been fixed, and
as a result, we'll fail an invalid point earlier in the ParsePubKey
method. We update the error string to reflect this change.
