With this commit we add a Makefile with the goal of removing the
goclean.sh script. We also use the more powerful golangci-lint linter
and split the GitHub actions into multiple sections to parallelize them.
To avoid a lot of code duplication, we extract the common parts of the
AddressWitnessPubKeyHash and AddressWitnessScriptHash types into a
common base type called AddressSegWit.
In this commit, we add two new package level functions: `EncodeM`, and
`DecodeGeneric`. The new encode method is intended to allow callers to
specify that they want to use the new bech32m checksum. This should be
used when encoding segwit addresses with version 1 and beyond. The new
`DecodeGeneric` function allows a caller to decode a bech32 and bech32m
string with a single function. A new return value is added which is the
version of the returned bech32 string, which allows callers to perform
additional segwit addr validation (v1+ should use bech32m etc).
We opted to add new functions rather than modifying the existing
functions to not cause a breaking API change, as most uses in the wild
can just use the existing functions, and only taproot related logic/code
needs to worry about the new methods.
A series of tests have been added to ensure that `DecodeGeneric`
extracts the proper bech version, and we've also adopted the bech32m
tests from BIP 350.
In this commit, we add an additional field to the ErrInvalidChecksum,
the bech32m version of a checksum. When decoding, we don't now what
version they actually _intended_ to use, so we'll opt to include both
checksums to aide in debugging and error reporting.
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.
