@bitauth/libauth
Advanced tools
Changelog
3.0.0
#127 e5c275f
Thanks @bitjson! - Add support for relative BIP32 derivation
Relative BIP32 Hierarchical Deterministic (HD) derivation is now supported via the deriveHdPathRelative
utility, and the Libauth compiler has been updated to explicitly use relative derivation by default for HdKey
s. Absolute derivation has also been enhanced to validate the expected depth of provided HD keys.
If you application relies on relative derivation but uses deriveHdPath
, you'll need to switch to using the new deriveHdPathRelative
, as absolute derivation will now fail if provided with a non-zero depth HD key.
Fixes #49.
#127 e5c275f
Thanks @bitjson! - CashAssembly: .signature
is now .ecdsa_signature
All CashAssembly scripts using the .signature
operation should instead call .ecdsa_signature
or switch to .schnorr_signature
.
Additionally, signing_serialization.token_prefix
is now available.
#127 e5c275f
Thanks @bitjson! - Unify object parameters and error handling across library
A number of existing Libauth utilities have been modified to adhere to Libauth's object parameter and error handling conventions:
crackHdPrivateNodeFromHdPublicNodeAndChildPrivateNode
decodeHdKey
(decodeHdKeyUnchecked
)decodeHdPrivateKey
/encodeHdPrivateKey
decodeHdPublicKey
/encodeHdPrivateKey
deriveHdPath
deriveHdPathRelative
deriveHdPrivateNodeFromSeed
deriveHdPrivateNodeIdentifier
/deriveHdPublicNodeIdentifier
deriveHdPrivateNodeChild
/deriveHdPublicNodeChild
deriveHdPublicKey
deriveHdPublicNode
hdKeyVersionIsPrivateKey
/hdKeyVersionIsPublicKey
hdPrivateKeyToIdentifier
/hdPublicKeyToIdentifier
Please see the relevant guide(s) for usage examples:
#127 e5c275f
Thanks @bitjson! - Add usage guides and API overview
#127 e5c275f
Thanks @bitjson! - Add P2PKH CashAddress utilities
The following utilities are now available:
hdPrivateKeyToP2pkhLockingBytecode
hdPrivateKeyToP2pkhCashAddress
hdPublicKeyToP2pkhLockingBytecode
hdPublicKeyToP2pkhCashAddress
privateKeyToP2pkhLockingBytecode
privateKeyToP2pkhCashAddress
publicKeyToP2pkhLockingBytecode
publicKeyToP2pkhCashAddress
For usage examples, see wallets.md
.
#127 e5c275f
Thanks @bitjson! - Validate all keys prior to compilation, expose validateCompilationData
The compiler now validates all compilation data (i.e. validate all public and private keys), prior to compilation, regardless of whether or not the offending public or private key material is used. This is intended to surface software defects (particularly in the software used by counterparties) as early as possible.
#127 e5c275f
Thanks @bitjson! - Add support for decodeTransactionOutputs
Changelog
2.0.0
Libauth is now a pure ESM package, simplifying the developer experience by allowing WASM crypto to be instantiated internally/automatically by default 🎉. This refactor also simplifies the usage of and types surrounding Libauth virtual machines and compilers, and several other APIs have been improved.
New, dedicated Telegram channels are also available for Libauth release announcements and Libauth developer discussions.
Previously, Libauth VMs were very strictly-typed such that error messages and opcodes used chain-specific enums (e.g. AuthenticationErrorBCH
and OpcodesBCH
). While this configuration did ensure that VMs and VM results were strictly-typed with chain information, the configuration ultimately made library components much harder to remix without deep knowledge of TypeScript's type system. In both cases, such type information rarely catches downstream implementation bugs:
number
to 0 | 1 | 2 | ... | 254 | 255
.In both cases, the differing types offer only very marginal benefit at the cost of exceptional added complexity (widespread proliferation of generic types throughout the codebase). This refactor migrates the opcode type to number
and the error type to string | undefined
, leaving the opcode and error enums primarily as a form of documentation.
Transaction validation infrastructure is now a part of each VM instance, so transaction validation is as simple as vm.verify({ transaction, sourceOutputs })
(returning either true
or an error string
). This behavior offers individual VMs full control of transaction parsing and validation, allowing Libauth VMs to implement proposals for significant modifications like new transaction formats or high-level transaction validation changes.
Beginning with this version, Libauth will no longer maintain support for defunct VM versions. For example, BCH_2019_05
was an upgrade which enabled Schnorr signature support in CHECKSIG and CHECKDATASIG and a clean-stack exception for SegWit recovery. The BCH_2019_05
VM was replaced without a network split by the BCH_2019_11
upgrade, meaning BCH_2019_05
is no longer in use by any public network. As such, relevant code paths, flags, and other VM-specific functionality for BCH_2019_05
has been removed to simplify currently supported Libauth VMs. (Of course, historical implementations will always remain available in previously-released versions of Libauth.)
With this change, the existing VM implementations have been significantly simplified, removing unused code and reducing type complexity. Built-in VM instruction sets are now specified in a single file, making them easier to review and copy.
Several other improvements have been made:
Secp256k1
doesn't throw - the Secp256k1
interface previously threw errors, breaking from Libauth's convention of well-typed errors. All Secp256k1
methods now return error messages as string
s where applicable.vmb_tests
test vector generation system to produce sets of cross-implementation test vectors as serialized transactions; this allows for sets of test vectors that fully test all transaction validation infrastructure without making assumptions about implementation internals.type
is distinguished from typeBit
.string
s.