Commit 24e673ae introduced a bug that cause the Error() function to
call itself recursively forever, causing a stack overflow. We explicitly
cast the error to its base type to avoid the recursion and add a small
test case that would've triggered the bug before.
The version 1.16 of golang is more diligent when it comes to the go.sum
file and seems to always check whether all dependencies are contained.
Previous versions seem to have ignored this. This change should be
backward compatible though so we might as well commit it.
Since bech32 itself works with data encoded with 5 bits per byte (aka
base32) padded out to the nearest byte boundary, the existing functions
for Encode and Decode accept and return data encoded that way.
However, the most common way to use bech32 is to encode data that is
already encoded with 8 bits per byte (aka base256) without padding which
means it is up to the caller to use the ConvertBits function properly to
convert between the two encodings.
Consequently, this introduces two convenience functions for working
directly with base256-encoded data named EncodeFromBase256 and
DecodeToBase256 along with a full set of tests to ensure they work
expected.
BIP173 specifically calls out that encoders must always output an all
lowercase bech32 string and that the lowercase form is used when
determining a character's value for calculating the checksum.
Currently, the implementation does not respect either of those
requirements.
This modifies the Encode function to convert the provided HRP to
lowercase to ensure the requirements are satisfied and adds tests
accordingly.
This commit brings a host of improvements to the bech32 package. The
public interface of the package remains unchanged.
Summary of changes:
* Improved error handling using dedicated error types. Programmatically
detect if the errors produced are the expected ones.
* Improve test coverage to test more corner cases. Added test vectors
from Bitcoin Core.
* Add a benchmark for a full encode/decode cycle of a bech32 string.
* Add a new function DecodeNoLimit, for decoding large bech32 encoded
strings. It does NOT validate against the BIP-173 maximum length
allowed for bech32 strings.
* Automatically convert the HRP to lowercase in Encode function.
* Improve performance of encode/decode functions by using
strings.Builder.
* Improve memory allocation in ConvertBits function.
* Updated documentation.
Credits: @matheusd
Closes#152 and #168.
This adds a new method to the ExtendedKey type that allows cloning the
extended key with custom HD version bytes. It does not mutate the
original extended key on which the method is called.
Added some tests to demonstrate the utility of this method, i.e.,
conversion between standard and SLIP-0132 extended keys.
This function should only `by` used by applications that need to create custom ExtendedKeys. => This function should only `be` used by applications that need to create custom ExtendedKeys
A wallet that has patched the CVE-2020-14199 vulnerability will always
include a non-witness UTXO, even for witness inputs. In the signer, we
detect that the input we spend is a witness input and copy over the
TxOut to the witness UTXO field. Therefore it is possible that both UTXO
fields are set at the same time. We need to adjust the sanity checks
when adding a partial signature to account for that.
As a countermeasure to CVE-2020-14199 new HW wallet firmwares require
the full non-witness UTXO to be set even for witness inputs.
We therefore shouldn't remove it when signing.
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.
