Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

[1.6.0] - 2026-11-06

Added

• Haskoin.Crypto.Keys.Slip39: Shamir’s secret-sharing for mnemonic codes, SLIP-0039, as a standalone module. generateMnemonics splits a master secret, encrypted with a passphrase, into share mnemonics under a two-level scheme of groups and members, and combineMnemonics rebuilds it from a threshold of them. generateShares and generateMnemonics draw their random bytes from the operating system, through getEntropy of the entropy package; generateSharesFrom takes the source of random bytes as an argument, and generateSharesWith the identifier and the random values themselves, so that a split can be reproduced. encodeShare and decodeShare read and write one share, with its checksum, padding and ranges checked as the specification requires; a share has at most 1023 words, the length the checksum covers, which is a value of 1270 bytes. encryptMasterSecret and decryptMasterSecret are the passphrase step, and both refuse a passphrase outside printable ASCII, as the specification requires; decryptMasterSecretBytes takes the passphrase as unchecked bytes, to recover shares of software that allowed other characters. splitSecret, recoverSecret and interpolate are the sharing over GF(256), and rs1024Checksum the checksum. No error text and no Show instance holds a word or a value of a share: an unknown word is named by its position. The 45 vectors of the reference implementation, a share set of Sparrow’s library, and split cases with fixed random values made by an independent Python implementation of the specification, test/Haskoin/Crypto/Keys/slip39_verify.py, check it. The word list is data/slip39_wordlist.txt, the file of the specification, and its SHA-256 is checked.
• tryDerivePath and tryDerivePubPath in Haskoin.Crypto.Keys.Extended derive along a path and return an error value when the path cannot be followed. Use them for a path that comes from outside, such as the path of a PSBT record. derivePath and derivePubPath throw DerivationException in that case, as before.
• maxRedeemScriptSize (520) and maxWitnessScriptSize (10,000) in Haskoin.Script.Standard are the largest scripts that a pay-to-script-hash and a pay-to-witness-script-hash output can commit to and still be spent: MAX_SCRIPT_ELEMENT_SIZE and MAX_SCRIPT_SIZE of Bitcoin Core. p2shScriptHash and p2wshScriptHash give the hash of a script for those outputs, and fail above the limit.
• p2shP2wpkhAddr in Haskoin.Address is the P2SH-P2WPKH address of a public key hash.
• SigHashFlag has a Bounded instance.
• decodeTx in Haskoin.Transaction.Common reads a transaction from bytes that hold the transaction and nothing else, as DecodeHexTx requires in Bitcoin Core. deserialize reads a transaction from the front of a longer input, as a block needs it to, and does not notice bytes that follow. Use decodeTx for a transaction that arrives on its own.
• dustThreshold in Haskoin.Transaction.Builder gives the amount below which nodes do not relay an output of a kind, as GetDustThreshold computes it in Bitcoin Core at the default dust relay fee: 546 satoshi for pay-to-public-key-hash, 294 for pay-to-witness-public-key-hash, 330 for pay-to-witness-script-hash and Taproot. chooseCoins can return a change below it, and its documentation now says to leave such a change to the fee.
• maxStandardTxWeight (400,000) in Haskoin.Transaction.Builder is the weight above which nodes do not relay a transaction: MAX_STANDARD_TX_WEIGHT of Bitcoin Core, and the 100,000 bytes of MAX_STANDARD_TX_SIZE of Bitcoin Cash Node.
• data/core_signed_txs.json holds 97 transactions that Bitcoin Core 32.1 signed on regtest, one for each of 16 kinds of coin and each hash type. The tests verify them with verifyStdTx, so that the verifier is checked against signatures the library did not make.
• arbitraryKeyPairC generates a key pair in compressed form.
• maxPayloadSize in Haskoin.Network.Message gives the largest payload a message of a command may have on a network, and getMessage applies it. On Bitcoin Cash every message but block, cmpctblock and blocktxn is limited to 2 MiB, the new maxProtocolMessageSize of Network, as CMessageHeader::IsOversized does in Bitcoin Cash Node. The limit was 64 MB for every message, and one 33.5 MB getblocktxn took 19 seconds and 5.7 GiB to parse. A node should use maxPayloadSize on the message header before it buffers a payload.
• getCompactBlock, getGetBlockTxn and getBlockTxn in Haskoin.Network.CompactBlock read the compact block messages of a network. On Bitcoin a transaction position above 65535, the new maxCompactBlockIndex of Network, fails the parse, and so does a compact block of more than 65535 transactions, as in BIP 152 and Bitcoin Core. Bitcoin Cash keeps 32 bits, as Bitcoin Cash Node. getMessage uses them.
• getNetworkTx in Haskoin.Network.Data reads a transaction as a peer of the network sends it: without the SegWit format on a network that has no SegWit. getMessage uses it for tx, block, blocktxn and cmpctblock.
• minimumChainWork in Network is the nMinimumChainWork of Bitcoin Core 32.1 and of Bitcoin Cash Node. Once the best block has that work, connectBlock and connectBlocks refuse a new header whose chain has less, which bounds cheap forks from far below the tip. A node that is still syncing below that work is not protected by this.
• getVarIntListMax, and the limits maxInvSize (50000), maxAddrSize (1000), maxHeadersSize (2000), maxLocatorSize (101) and maxFilterHashes (2000) in Haskoin.Network.Common. The parsers of inv, getdata, addr, addrv2, headers, getheaders, getblocks and cfheaders fail above them, as soon as the count is read.
• extractIndexedMatches and merkleBlockIndexedTxs in Haskoin.Block.Merkle give the position of each matching transaction of a partial Merkle tree. maxMerkleFlagBits is the number of flag bits a valid proof can use.
• leafHashBytes in Haskoin.Transaction.Taproot is the tapleaf hash of a script given as bytes, for a script that is not a list of opcodes. checkTapTree tells whether every leaf of a script tree can be spent: it fails for a node deeper than 128, which no control block can prove, and for a leaf version that is odd or is 0x50. Run it on a tree before you give out its address. scriptPathScriptBytes gives the script bytes of a script path spend as they are in the witness. taprootSignature builds a TaprootSignature and fails for a hash type that Taproot does not define.
• data/taproot_mainnet_spends.json holds 24 Taproot script path spends from Bitcoin mainnet blocks 840000 and 900000, with scripts of 34 to 635 bytes. The tests check that each one is read and that its script and control block commit to the output key of the coin it spends.
• requirePreviousTx on a PSBT Signer. With it, the signer refuses a SegWit version 0 coin that is known from its witness output only, since the amount of such a coin is a claim of whoever wrote the PSBT (CVE-2020-14199). keySigner and xPrvSigner set it.
• inputCoins and psbtFee: the coin of each PSBT input with whether it comes from the previous transaction, and the fee when every coin does.
• psbtPartialTransaction: the transaction of a PSBT that is still being signed.
• data/psbt_complex_core32.json: nine coins of every kind, signed by Bitcoin Core 32.1 without finalizing.

Changed

• unmarshal and unmarshalLazy fail when bytes are left over after the value. They used to read a value from the start of the input and ignore the rest, so two different byte strings could read as the same public key, signature or extended key. Code that reads a value from the start of a longer stream must run marshalGet itself.
• The binary form of XPubKey holds a compressed public key in exactly 33 bytes, as BIP 32 defines it and as xPubImport already required. A key in the 65-byte form used to be read.
• decodeStrictSig, and with it the binary and JSON forms of Sig, apply the encoding rule of BIP 66 and nothing more. A signature with a high S value is now read. Low S is a relay rule of Bitcoin Core (SCRIPT_VERIFY_LOW_S), not a consensus rule, and blocks hold signatures with a high S. isCanonicalHalfOrder tests the relay rule. The form of a transaction signature, TxSignature, still applies it. The signers make low-S signatures, as before.
• makeXPrvKey throws DerivationException for a seed that is not 16 to 64 bytes long, the range that BIP 32 gives and that Bitcoin Core enforces. A seed of any length used to give a master key, the empty string included, and anyone can compute the keys of such a wallet. A wallet that was made from a seed of another length can still be opened without this function: its master key is XPrvKey 0 "00000000" 0 chain key, where key and chain are the two halves of hmac512 "Bitcoin seed" seed.
• applyPath returns Left for a path that leads below depth 255, which no key can have. It used to throw DerivationException, although its type promises an error value.
• The path constructors :| and :/ throw DerivationException for an index of 2^31 or more. Such a path could be built before, but its text and binary forms did not read back to the same path, and deriving along it threw. The two constructors are now pattern synonyms. Code that builds and matches paths with them compiles as before.
• fromMiniKey requires a mini key to start with the letter S and to hold only characters of the Base58 alphabet, as the format defines. One arbitrary string of 22 or 30 characters in 256 used to be read as a private key.
• getInteger reads only the encoding that putInteger writes: a tag byte of 0 or 1, a sign byte of 0x01 or 0xff, and the shortest bytes that hold the number. Several other byte strings used to read as the same number. Data written by putInteger reads as before. The reader also takes close to linear time now. A number of 400 KB used to take 54 seconds.
• getIntMap refuses keys that are not in ascending order, which is how putIntMap writes them. A key given twice used to be read, and its second element silently replaced the first.
• convertBits returns Nothing for a width that is zero or negative, where it used to loop forever, and for a digit that does not fit the width it is converted from, whose high bits it used to drop.
• bech32Encode returns Nothing for a five-bit word above 31. It used to raise an array index error.
• The JSON parser of Sig no longer copies the text it refuses into its error message.
• data/key_io_valid.json and data/key_io_invalid.json are the files of Bitcoin Core 32.1, with its Bech32m and testnet4 vectors. The tests run every vector through textToAddr and fromWif, as key_io_tests.cpp does.
• payToScriptAddress, payToWitnessScriptAddress and payToNestedScriptAddress return Either String Address, and toP2SH and toP2WSH return Either String ScriptOutput. They fail for a redeem script above 520 bytes and for a witness script above 10,000 bytes. A pay-to-script-hash redeem script is a push of the spending input, and consensus limits a push to 520 bytes, so coins sent to the hash of a longer script can never be spent. payToScriptAddress used to give an address for a multisig of 16 to 20 compressed keys (547 to 684 bytes), or of 8 or more uncompressed keys, and Bitcoin Core rejects every spend of such a coin with “Push value size limit exceeded”. Fifteen compressed keys fit, and twenty still fit a pay-to-witness-script-hash output. These functions also return the failure of encodeOutput for a multisig that no script can express, where payToScriptAddress used to raise an error call.
• deriveMSAddr and derivePathMSAddr return Either String (Address, RedeemScript), and deriveMSAddrs and derivePathMSAddrs return Either String of their list. They fail for more than 15 keys, whose address would be unspendable as described above, and for a number of required signatures that is not between 1 and the number of keys, which used to raise an error call when the address was forced. Coins that were sent to an address these functions gave for 16 to 20 keys are lost: no spend of them is valid.
• scriptToAddress, scriptToAddressBS and outputAddress take the Network as their first argument and give an address only for an output kind that the network has. A witness program has no address on Bitcoin Cash, and a 256-bit script hash (OP_HASH256 <32 bytes> OP_EQUAL) has none on Bitcoin, where Bitcoin Core reports that script as non-standard. Without the network these functions returned an address that has no text form on the chain it came from, and the JSON encoder of Address throws for such an address. One such output is in Bitcoin block 211997 (transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b, output 0), so an indexer that encoded the addresses of outputs failed on that transaction. Every address these functions return now has a text form on the network.
• decodeInput only reads a pay-to-script-hash input whose redeem script is in the form encodeOutput writes. A multisig redeem script whose keys are pushed with OP_PUSHDATA1 used to decode, and inputAddress then gave the hash of the re-encoded script, an address that never held the coin. Such an input now fails to decode, so inputAddress is always the hash of the redeem script bytes of the input, and encoding a decoded input never rewrites its redeem script. Spending such a script breaks the MINIMALDATA rule of the relay policy, so standard transactions are not affected.
• decodeInput reads a NestedWitnessInput only when the witness program is a direct push, as BIP 141 requires (“the scriptSig must be exactly a push of the BIP16 redeemScript”). A program pushed with OP_PUSHDATA1 used to decode, although such an input is invalid by consensus.
• inputAddress gives no address for a redeem script above 520 bytes.
• txSigHashForkId writes the hash type as four bytes on a network without a fork id, as SignatureHash of Bitcoin Core does for a SegWit input. It used to keep the low byte only, while txSigHash wrote all four. Nothing changes for a hash type that fits in one byte, which is every hash type a signature can carry.
• cashAddrDecode, and with it textToAddr and the JSON parser of Address on Bitcoin Cash networks, refuse a string longer than the prefix of the network, the colon and 112 characters before any other work. No valid address is longer, since the largest hash of the format is 64 bytes. A string of 1 MB used to take 1.5 seconds and several hundred megabytes of memory, and now takes less than a millisecond.
• cash32decode and cash32decodeType refuse a prefix that is not made of letters only, as the decoder of Bitcoin Cash Node does. A digit or a second colon in the prefix used to be read.
• cash32encode returns Maybe Cash32. It fails for a prefix that is empty or not made of ASCII letters, and it writes an uppercase prefix in lowercase. It used to write strings that cash32decode refuses: with an empty prefix, a digit, a colon, or a prefix of another case than the data.
• The Read instance of Address goes through witnessAddress and cashAddress for the two generic kinds. The derived instance read a witness version above 16, a program of any length and a CashAddr type above 15, which no other function builds.
• enumFrom, enumFromTo, enumFromThen, enumFromThenTo, succ and pred of SigHashFlag walk the five flags in the order of their constructors. [SIGHASH_ALL ..] and succ SIGHASH_SINGLE used to raise “Not a valid sighash flag”, because the values of the flags are not consecutive.
• The generators arbitraryMulSigSHInput, arbitraryMulSigSHInputC, arbitraryMulSigSHInputFull and arbitraryMulSigSHInputFullC draw a redeem script of at most 520 bytes. More than half of the inputs they drew could not exist. arbitraryP2SHMSParam, arbitraryP2SHMSParamC, arbitraryP2SHMSOutput and arbitraryP2SHMSOutputC are the new generators behind them. arbitrarySHSigInput and arbitraryPartialTxs use at most 7 keys for the same reason.
• arbitraryScriptOutput draws a 256-bit script hash output on networks that have CashAddr, and arbitraryScriptInput draws a nested witness input only on networks that have SegWit. arbitraryBitcoinAddress draws a Taproot address one time in six, through the new arbitraryTaprootAddress, and arbitraryBitcoinCashAddress a payable token-aware address one time in five, through the new arbitraryTokenAddress.
• makeSignature, and with it signTx, signInput, signNestedWitnessTx and signPsbt, refuse a hash type that no node accepts, with the reason: one that is not SIGHASH_ALL, SIGHASH_NONE or SIGHASH_SINGLE with or without SIGHASH_ANYONECANPAY (the test of IsDefinedHashtypeSignature in Bitcoin Core), the fork id flag on a network without a fork id, and a value that does not fit in the one byte a signature carries. On Bitcoin Cash this refuses SIGHASH_UTXOS (0x20), whose digest the library does not compute. The types 0x00, 0x04, 0x21, 0x41 and 0x80 used to be signed, and the result was a transaction that nodes do not relay. A type with upper bytes set, such as 0x101, gave a signature that does not verify. signTx still signs SIGHASH_NONE and SIGHASH_SINGLE when the SigInput asks for them: check the hash type of a SigInput that comes from someone else.
• makeSignature refuses a pay-to-script-hash coin without its redeem script, with a redeem script above 520 bytes, or with one that does not hash to the coin, and the same for a pay-to-witness-script-hash coin and its witness script, above 10,000 bytes. It used to sign whatever script it was given, and the output script itself when it was given none. Such a signature spends nothing.
• makeSignature refuses a SegWit coin, and signTx a Taproot coin, on a network without SegWit. signTx bch used to return a transaction with a witness, which no Bitcoin Cash node reads.
• signTx, signNestedWitnessTx and sigKeys refuse to sign a SegWit version 0 coin with an uncompressed key, whether the coin pays to the hash of the key or to a witness script that holds it. Nodes do not relay such a spend (SCRIPT_VERIFY_WITNESS_PUBKEYTYPE in Bitcoin Core), so the transaction they returned could not be broadcast. A block may still hold the spend. To make it on purpose, call signInput with the PrivateKey in its uncompressed form.
• signInput and signNestedInput refuse a key that is not a key of the coin: the key of a pay-to-public-key coin, the key whose hash the coin pays to, or a key of its multisig. They used to return an input that no node accepts.
• signTaprootInput refuses a secret key whose x-only public key is not the output key of the coin, and a spent output that is not a Taproot output. Passing the internal key in place of its tweak used to give a signature that does not verify.
• verifyStdInput and verifyStdTx require a multisig input to hold exactly as many signatures as its script requires, and no other item. OP_CHECKMULTISIG takes that many items as signatures, and the item below them must be empty (BIP 147), so no block can contain an input with an item after its signatures or with an empty item among them. They used to answer True for both, in bare, pay-to-script-hash and pay-to-witness-script-hash form. An empty item before the signatures is refused too: nodes do not relay it, and in a witness it is invalid.
• verifyStdTx refuses a transaction in which two inputs spend the same outpoint, as CheckTransaction does in Bitcoin Core (bad-txns-inputs-duplicate).
• verifyStdInput and verifyStdTx refuse a SegWit or Taproot input on a network without SegWit, and compare the input script of a nested SegWit input with the push of its program byte for byte.
• verifyStdTx looks up the coins once for the whole transaction. It used to walk the list of coins for every input, and to rebuild the list of spent outputs for every Taproot input, so its time grew with the cube of the number of Taproot inputs: 400 of them took 1.6 s and now take 0.14 s.
• signTx derives the public keys of its secret keys once for the whole transaction, not once per input. 400 Taproot inputs with 400 keys took 11.7 s and now take 0.2 s.
• guessTxFee returns Either String Word64. It fails when the fee does not fit in 64 bits, where it used to wrap around: 192 bytes at 2^58 satoshi per byte gave a fee of 0. It also fails for a kind of input or output that cannot exist, such as InputMulSig 16 16, whose redeem script would be 547 bytes, or a multisig of 3 of 2.
• chooseCoins and chooseCoinsSink add amounts as unbounded integers. A target near 2^64 used to wrap around with its fee, so that a coin of 1,000 satoshi “covered” a target of 2^64 - 101. They fail for a kind of input or output that cannot exist, and they stop with an error when the transaction would weigh more than maxStandardTxWeight. They keep the sums of the selection as coins are added: selecting 1,400 coins took 0.11 s and now takes under a millisecond.
• greedyAddSink adds amounts as unbounded integers as well. chooseCoinsSink no longer uses it.
• mergeTxs and mergeTxInput keep the witness of the transaction. They used to remove it, so a SegWit input that was signed before the multisig signers took their copies lost its signature. mergeTxs now answers “Transactions do not match” for copies whose witnesses differ, since it does not merge witnesses. mergeTxInput returns Left for an input index that one of the transactions does not have. It used to raise an error.
• hasWitness looks only at the stacks of the inputs. A witness item in a stack beyond the inputs used to turn the witness format on, which gave bytes with the marker and no witness item, a wrong weight and a wrong witness transaction id. Neither Bitcoin Core nor this library reads those bytes.
• The JSON form of Tx requires one witness stack per input, or none.
• buildAddrTx refuses an amount above the maxSatoshi of the network, as createrawtransaction refuses an amount out of range in Bitcoin Core.
• The generators of Haskoin.Util.Arbitrary.Transaction draw compressed keys for SegWit signing data, a pay-to-script-hash multisig InputKind of at most 15 keys, SegWit and Taproot signing data only on networks that have SegWit, and amounts of which a third are below 10,000 satoshi.
• fromMnemonic and mnemonicToSeed no longer put words of the sentence or checksum values into their error text. An unknown word is named by its position, as in fromMnemonic: words 3 and 7 are not in the list, and a failed checksum is fromMnemonic: checksum failed. A sentence typed in capitals used to be echoed whole, and the text of a Left ends up in logs.
• fromMnemonic and mnemonicToSeed do a bounded amount of work on text from an untrusted source. The sentence is split into words before anything is normalised, and a word longer than the eight letters of the longest list word is refused as it is. mnemonicToSeed refuses a passphrase whose NFKD form would hold more than 30 combining characters in a row, the limit of the Stream-Safe Text Format of Unicode (UAX #15), which no real text passes. 32 KB of combining characters used to take half a minute, and the time grew with the square of the length. Every sentence and passphrase that was accepted before, other than such a passphrase, gives the same seed. This adds a direct dependency on unicode-data, which unicode-transforms already used.
• The parser of MerkleBlock refuses more hashes than transactions and more flag bytes than the tree can use, before it reads them. A merkleblock message used to cost about 95 bytes of memory per flag byte, 1.5 GB for a 16 MB message. Proofs that verify are not affected.
• An empty witness item, and any empty byte string of the wire format, costs one list cell. A tx message with four million empty witness items kept 356 MB and now keeps 100 MB, as much as Bitcoin Core.
• bloomRelevantUpdate matches a transaction as BIP 37 and IsRelevantAndUpdate of Bitcoin Core do: by its hash, by the data of its output scripts, by the outpoints it spends and by the data of its input scripts. It only looked at outputs, so a transaction that spends a watched coin was not matched. Pay-to-pubkey and multisig outputs are told by the shape of the script, as Solver does, so a hybrid key or a key that is not on the curve counts. The Ctx argument is no longer used.
• The version, timestamp and startHeight fields of Version are Int32, Int64 and Int32, signed as in Bitcoin Core. A peer that sent version ffffffff appeared to have version 4294967295.
• validVersion applies its three conditions independently, as ContextualCheckBlockHeader does. It accepted old block versions on networks whose activation heights are not in the order BIP 34, BIP 66, BIP 65, which are Bitcoin Cash regtest and testnet4.
• chooseBest keeps the first block when two have the same work, whatever their heights, as Bitcoin Core does. It preferred the higher one.
• connectBlock and connectBlocks return the stored node of a header that is already in the store, as AcceptBlockHeader does in Bitcoin Core. A known header at or below a checkpoint used to be refused as “Rewriting pre-checkpoint chain”.
• The memory header store returns a node only for the hash that was asked for. It returned any node whose hash shared the first eight bytes.
• calcHash returns Maybe Hash256 and no longer calls error outside the tree. splitIn with a length below one returns the list as one chunk and no longer loops. Hashable BlockNode hashes the header only, like Eq.
• An addrv2 entry of the Tor v2 network is read whatever its length, since BIP 155 says to ignore such entries, and no longer fails the message. fromNetworkAddressV2 gives Nothing for an IPv6 entry that holds an IPv4-mapped or an OnionCat address. toNetworkAddressV2 gives a Tor v2 entry for an OnionCat address.
• getMessage checks the magic bytes before the command name.
• bloomCreate picks the number of hash functions with the integer division of Bitcoin Core.
• Read MessageCommand reads what Show writes for any bytes.
• btcRegTest has a target timespan of one day, as Bitcoin Core regtest, and btcTest4 pins no BIP 34 block hash, as Bitcoin Core testnet4.
• The reader of BlockNode refuses a chain work that is negative or does not fit 256 bits.
• The generators arbitraryMerkleBlock, arbitraryBlock, arbitraryBlockNode, arbitraryVarInt, arbitraryReject, arbitrarySendCompact, arbitraryCompactBlock and arbitraryBlockTxn cover more cases, and arbitraryNetworkTx, arbitraryNetworkGetBlockTxn and arbitraryPositionsUpTo are new.
• A TaprootSignature only holds a hash type that isTaprootSigHash accepts. Its constructor is now a pattern that only matches. Build a value with taprootSignature or decodeTaprootSig; the fields sig and hash are read as before and cannot be updated. encodeTaprootSig used to cut any hash type to one byte, so 0x100 was written as a 65-byte signature ending in 00, which BIP 341 forbids, and 0x101 as SIGHASH_ALL.
• ScriptPathData has a new last field, opaqueScript: the bytes of the script when they are not a list of opcodes, in which case script is empty. viewTaprootWitness now reads a script path spend whatever its script bytes are. It used to return Nothing for a Tapscript with an OP_SUCCESSx opcode followed by bytes that do not decode, and for a leaf of another version, although such spends can be valid. verifyScriptPathData takes the leaf hash on the script bytes of the witness, and is False for a proof of more than 128 hashes.
• encodeTaprootWitness returns Either String WitnessStack. It fails for an annex that is empty or does not start with 0x50, for a proof of more than 128 hashes, and for a leaf version that is odd or is 0x50. It used to write a witness that reads back as another spend, or that every node refuses.
• taprootSigHash fails for an annex that is empty or does not start with 0x50. No node takes such an item for an annex, so no node computes that digest.
• data/bip341.json is the file of the BIPs repository, whose key is fullySignedTx.
• Signer has a fourth field, requirePreviousTx.
• keySigner and xPrvSigner refuse a SegWit version 0 coin without its previous transaction. Attach the previous transaction, or set requirePreviousTx = False to trust the PSBT writer.
• psbtTransaction refuses a PSBT with an input that is not final. Use psbtPartialTransaction for the old behaviour.
• decodePsbt refuses what Bitcoin Core refuses: a key type that is not a compact size in its shortest form, a public key that is not on the curve, a partial signature that is not in the encoding of BIP 66 with a defined sighash byte, a previous transaction that the input does not spend, and a script tree that is not whole.
• signPsbt and finalizePsbt leave alone an input whose redeem or witness script is not a standard template, instead of failing the whole PSBT.
• signPsbt signs only for keys that the signed script names. It adds no signature to a script-hash coin whose script is missing, and signs a Taproot leaf only when its control block commits it to the coin.
• signPsbt and finalizePsbt refuse an uncompressed key on a SegWit version 0 coin.
• finalizePsbt verifies only the signatures of keys the script names, against one digest per input.
• finalizePsbt refuses a signature that is not SIGHASH_ALL (SIGHASH_DEFAULT for Taproot) when the input names no sighash type, and leaves alone a legacy coin known from its witness output only.
• addInput and addOutput check the map they are given.
• A PSBT error names at most 40 bytes of a key.

Fixed

• The documentation of the hardened markers, of the depth limit and of decodeSecKey no longer describes old behaviour of Bitcoin Core and of the secp256k1 binding. The documentation of PrivateKey and XPrvKey says that the Show instance of the SecKey inside them prints the secret.
• The documentation of TxSignature, decodeTxSig and decodeInput lists the rules they apply: strict DER, a low S and a defined hash type, the three signature rules of the relay policy of Bitcoin Core. A signature that only consensus accepts does not decode, so an input of an old block can fail to decode. The documentation also says that a Schnorr signature of Bitcoin Cash does not decode.
• The documentation of decodeOutput says that a multisig whose keys are not direct pushes, and a data carrier whose pushes are not the shortest, come back from encodeOutput as other bytes, and lists the scripts that the Solver of Bitcoin Core classifies and this function does not: a key in hybrid form or off the curve, and OP_RETURN OP_RESERVED.
• The documentation of txSigHash names SerializeScriptCode of Bitcoin Core for the removal of OP_CODESEPARATOR, and says that the pushes of the signature are not removed from the script, which FindAndDelete does in Bitcoin Core. The documentation of txSigHashForkId lists what is not supported on Bitcoin Cash: SIGHASH_UTXOS, coins that hold tokens, and Schnorr signatures.
• The documentation of Address says that a token-aware CashAddr and its plain form are different values that pay the same script, and that a value built with a constructor or read from the binary form is not checked against a network. The documentation of textToAddr says that white space around an address is refused and that some CashAddr kinds decode without being payable. The documentation of addressToOutput says that it does not know the network.
• The documentation of maxMultisigKeys says that 20 keys fit a bare and a pay-to-witness-script-hash multisig only.
• The documentation of verifyStdTx and verifyStdInput says what they check and what they do not: they are not a script interpreter, they never answer True for an input of the kinds they know that no block can contain, and they answer False for some inputs that a block may hold but nodes do not relay.
• The documentation of SigInput says that the value of a legacy coin is not committed to by its signature, so that a signer cannot check it without the previous transaction.
• The documentation of guessTxSize and txVirtualSize says that they do not count signature operations, which Bitcoin Core charges for in a transaction that is dense in them.
• The documentation of InputKind gives the ranges of a multisig kind, and that of buildTx and buildAddrTx says what they do not check.
• leafHash, and with it mastCommitment, taprootOutputKey, taprootScriptOutput, getMerkleProofs and verifyScriptPathData, write the script length of a Taproot leaf as a CompactSize, as BIP 341 defines the tapleaf hash and as ComputeTapleafHash does in Bitcoin Core. They wrote a base-128 varint, which is the same byte below 128 only. A leaf script of 128 bytes or more, such as a multi_a of four keys, therefore got a leaf hash, an output key and an address that no other software derives, and that leaf could not be spent. The address of every script tree with such a leaf changes. Trees whose leaf scripts are all shorter than 128 bytes, and outputs without a tree, are not affected. Coins at an address that version 1.5.1 or earlier made from such a tree can still move by the key path, or by the script path of a leaf shorter than 128 bytes. To rebuild the old output, put the old hash of each long leaf in the tree as a MASTCommitment. The old hash is the tagged hash TapLeaf of the leaf version, the script length as Data.Bytes.VarInt.VarInt of the bytes package, and the script bytes. taprootOutputKey and taprootOutputSecKey then give the old output key and the secret key of its key path, and getMerkleProofs gives the proofs of the short leaves. The long leaves of such an output can never be spent. The test “An output made by versions up to 1.5.1 with a leaf of 128 bytes or more” in TaprootSpec.hs has the code.
• getMerkleProofs lists the hashes of a proof from the leaf up to the root for a leaf at any depth, as BIP 341 and Bitcoin Core do. From depth 3 the order was wrong, and every node refused the control block built from it. It also hashes each subtree once instead of once per level.
• The JSON form of XOnlyPubKey reads the hex of 32 bytes only. It used to read the first 32 bytes of a longer value, so a 33-byte compressed key was taken for another key.
• tapTreeLeaves returns Nothing for a tree with a leaf deeper than 128, and no longer wraps the depth at 256.
• xPrvSigner no longer throws for a derivation path of more than 255 steps. The input stays unsigned.
• signPsbt signs a P2SH-P2WPKH coin by the hash of its key, without a derivation record.
• signPsbt and finalizePsbt use SIGHASH_ALL with the fork id flag on Bitcoin Cash when an input names no sighash type.
• signPsbt signs a Taproot key path when the record of the internal key lists a leaf.
• The PSBT scripts under scripts/ run again, against Bitcoin Core 32.1.

[1.5.1] - 2026-11-04

Fixed

• nextAsertWorkRequired evaluates the aserti3-2d formula at the parent of the new block, with the parent’s timestamp and height, as GetNextASERTWorkRequired does in Bitcoin Cash Node. It used the new block’s own timestamp and height, so the bits it required were wrong for every block that did not come exactly ten minutes after its parent. The bits check that 1.5.0 added to connectBlocks turned this into a rejected block on Bitcoin Cash mainnet at height 975899.

[1.5.0] - 2026-11-03

Added

• Taproot signing and verification, BIP 341 and BIP 342: taprootSigHash computes the digest a Taproot signature signs, for the key path and for a leaf of a script path; taprootOutputSecKey tweaks a secret key as taprootOutputKey tweaks its public key; signTx signs a SigInput of a Taproot output by its key path, with a key whose x-only public key is the output key or whose tweak without a script tree is, as a BIP 86 wallet spends, and signTaprootInput signs one input; verifyStdTx verifies key path spends, and script path spends whose leaf is a single key check. TaprootSignature, encodeTaprootSig and decodeTaprootSig are a Schnorr signature with its hash type, isTaprootSigHash tells the hash types a Taproot signature may use, and sigHashDefault is the default one. The key path vectors of BIP 341 and the BIP 86 vectors check them.

• The Taproot fields of PSBTs, BIP 371, in Haskoin.Transaction.Psbt: tapKeySig, tapScriptSigs, tapLeafScripts, inputTapDerivations, inputTapInternalKey, inputTapMerkleRoot, outputTapInternalKey, outputTapTree and outputTapDerivations, with their inserts. They are checked against the spec when a PSBT is read. signPsbt signs a Taproot coin by its key path when the input has its internal key, and by each leaf script that is a single key check; finalizePsbt finalizes both. The test vectors of BIP 371 check them.

• tapTreeLeaves and tapTreeFromLeaves in Haskoin.Transaction.Taproot convert a script tree to and from its leaves with their depth, the form of PSBT_OUT_TAP_TREE. encodeControlBlock and decodeControlBlock build and read a control block, which must be 33 bytes plus 32 per node with at most maxControlBlockNodes (128) nodes. leafHash, keyParity and tapscriptLeafVersion are exported.

• txWitnessHash in Haskoin.Transaction.Common is the witness transaction id of BIP 141. txWeight and txVirtualSize give the weight and the virtual size of a transaction, and hasWitness tells whether it has a witness.

• InputKind and OutputKind in Haskoin.Transaction.Builder name the kinds of inputs and outputs: pay-to-public-key, pay-to-public-key-hash with a compressed or an uncompressed key, pay-to-script-hash multisig, the native and nested SegWit kinds, Taproot, pay-to-script-hash of a 256-bit hash, and any other output script by its size. guessTxWeight, guessTxSize and guessTxFee estimate the weight, the virtual size and the fee of a transaction of those kinds, with inputWeight and outputSize per kind. The guess is an upper bound: it counts 72 bytes per signature, the one-byte empty witness stack of a legacy input in a transaction with a witness, and two bytes for each count of a multisig script above 16.

• Signer in Haskoin.Transaction.Psbt is a record: keyOfRecord gives the key a derivation record names, as before, and keyOfHash the key of a public key hash, so that signPsbt signs the coins whose keys it holds when the input has no derivation record. keySigner provides both, xPrvSigner the first.

• Tests for every function of the Haskoin.Transaction and Haskoin.Util modules, with the key path vectors of BIP 341, the vectors of BIP 86 and BIP 371, and literal sizes, ids and fee estimates.

• connectBlock and connectBlocks now check that a header carries the difficulty bits the chain requires, as ContextualCheckBlockHeader does in Bitcoin Core. validBlock takes the required bits as a new argument. Without this check a chain of headers mined at the minimum difficulty was accepted.

• asertAnchor finds the anchor block of the aserti3-2d algorithm for the chain that ends at a given block. mtp is now the median time past of the block itself, as in Bitcoin Core, instead of its parent’s.

• getVarIntList and putVarIntList in Haskoin.Network.Common read and write lists with their VarInt count. A count above maxListSize (32 MiB, the MAX_SIZE of Bitcoin Core) fails the parse instead of wrapping around and reading an empty list. Blocks, Merkle blocks, getblocks, getheaders, headers, inv, getdata, notfound and addr messages use them.

• genesisTx in Network holds the coinbase transaction of the genesis block. Haskoin.Transaction.Genesis exports mainnetGenesisTx, testnet4GenesisTx and genesisCoinbase.

• skipHeight and medianTime are exported from Haskoin.Block.Headers.

• Tests for every function of the Haskoin.Block modules, with vectors from Bitcoin Core and from mainnet block 100000.

• PSBT version 2 (BIP 370) in Haskoin.Transaction.Psbt: a PSBT of version 2 is read and written as its maps, with the unsigned transaction its fields describe and the lock time they determine. The roles take both versions, and version 2 has its constructor (addInput, addOutput), its updater (setInputSequence), the flags of PSBT_GLOBAL_TX_MODIFIABLE, which the signer and the combiner keep as the spec and Bitcoin Core do, and conversion between the versions (withVersion). The test vectors of BIP 370 and files of Bitcoin Core 32.1 check it.

• addrToBase58, addrToBech32 and addrToCash encode an address in one chosen format. addrToBase58 gives the legacy form of a Bitcoin Cash address.

• Token-aware CashAddr addresses (types 2 and 3) can be paid. addressToOutput, addressHash160 and addressHash256 treat them like their plain P2PKH, P2SH and P2SH32 counterparts.

• decodeSecKey in Haskoin.Crypto.Keys.Common builds a secret key from 32 bytes and refuses zero and values at or above the curve order. fromWif, fromMiniKey, xPrvImport, makeXPrvKey and the binary form of PrivateKey use it. The secKey of secp256k1-haskell 1.7.0 only checks the length, so such keys used to import and then crash derivePubKey and signMsg with an error call.

• Derivation paths accept h and H as hardened markers, so m/84h/0h/0h parses. Bitcoin Core and BIP 380 write ' or h, and BIP 32 writes a subscript H.

• Tests for BIP32 test vectors 4 and 5, for a BIP39 passphrase with accented letters, and for every function of the Haskoin.Crypto modules.

• The P2P messages added since 2016: addrv2 and sendaddrv2 (BIP 155) with AddrV2, NetworkAddressV2 and conversions from and to addr entries; feefilter (BIP 133); sendcmpct, cmpctblock, getblocktxn and blocktxn (BIP 152) in Haskoin.Network.CompactBlock; getcfilters, cfilter, getcfheaders, cfheaders, getcfcheckpt and cfcheckpt (BIP 157) in Haskoin.Network.BlockFilter; wtxidrelay (BIP 339) and sendtxrcncl (BIP 330). The inventory types InvCompactBlock and InvWTx, and the service bits nodeCompactFilters, nodeNetworkLimited and nodeP2PV2.

• maxMessageSize in Network bounds the payload getMessage reads: 4,000,000 bytes on Bitcoin, as in Bitcoin Core, and twice the block size on Bitcoin Cash.

• scriptPushData lists the data elements a script pushes, as GetOp does in Bitcoin Core.

• getVarIntBytes and putVarIntBytes read and write bytes with their count, under the same limit as lists.

• Tests with fixed wire bytes for every message type, the sample version, verack and addr messages of the protocol documentation, and every function of the Haskoin.Network modules.

• pushOpData gives the data that a push opcode puts on the stack, and isMinimalPush tells whether a push is in its shortest encoding, the rule of CheckMinimalPush in Bitcoin Core.

• OP_CHECKSIGADD is a pattern synonym for opcode 0xba, which OP_CHECKDATASIG also names, so a Tapscript can be written with the name of BIP 342.

• NestedWitnessInput is the input script of a P2SH-P2WPKH or P2SH-P2WSH output: a push of the witness output script. decodeInput, encodeInput, inputAddress and the signer use it, and isNestedWitnessInput tests for it. Such an input used to fail to decode.

• maxMultisigKeys is 20, the MAX_PUBKEYS_PER_MULTISIG of Bitcoin Core. decodeOutput reads a multisig output with 17 to 20 keys, whose counts are one-byte pushes, and encodeOutput writes one. Only 16 keys used to be supported.

• decodePubKey in Haskoin.Crypto.Keys.Common reads a public key from bytes that must hold the key and nothing else.

• Tests for every function of the Haskoin.Script modules, with literal vectors from BIP 67, BIP 143, BIP 173 and BIP 341.

Changed

• makeSignature, and with it signTx, signInput and signPsbt, refuse to sign a legacy input with SIGHASH_SINGLE when the input has no output at its index. The digest of that case is the constant 1, which commits to nothing, so the signature would spend any other coin of the key wherever the same case comes up. txSigHash still computes that digest, as a node must to verify such signatures, and verifyStdInput still accepts them. A SegWit input is signed in that case, since the BIP 143 digest commits to the coin.
• Signer has a new field, acceptedSigHashes: the sighash types it signs with. keySigner and xPrvSigner set it to defaultSigHashes, which are SIGHASH_DEFAULT and SIGHASH_ALL. signPsbt refuses an input that asks for another type, as BIP 174 asks of a signer: the other types leave part of the transaction unsigned, and the PSBT comes from someone else. A PSBT asking for SIGHASH_NONE or SIGHASH_SINGLE used to be signed as asked. The fork id flag is not compared, since the network decides it.
• PrivateKey and XPrvKey show their secret as <redacted>, and no longer have a Read instance; nor does XKey. The derived instances printed the key, and for XPrvKey the chain code, so a value in a log or an error message gave the coins away. toWif and xPrvExport write a key out.
• prvSubKey, pubSubKey, hardSubKey and cycleIndex throw DerivationException for a child index with the hard bit set, like every other failure of a derivation. They used to call error.
• A transaction with no inputs whose next byte, the flags of BIP 144, is neither 0x00 nor 0x01 fails to parse with “Unknown transaction optional data”, as in Bitcoin Core. Such bytes used to parse as a legacy transaction with no inputs that did not serialize back to the same bytes. A Tx string literal must hold the transaction and nothing else, as DecodeHexTx requires in Bitcoin Core.
• The documentation of decodeBase58 and decodeBase58Check says that their cost grows with the square of the length and that callers must bound untrusted input. The decoders of the library bound it already.
• taprootOutputKey and taprootScriptOutput tweak the x-only internal key, as BIP 341 defines the output key. An internal key with an odd y coordinate used to be tweaked as a full point, which gave an output key and an address no other wallet derives from that key, and that a BIP 341 signer could not spend.
• viewTaprootWitness reads a witness in the order of BIP 341: the annex last, then the control block, then the script, then the stack. It used to read the control block and the script in the other order, and so decoded no real script path witness. encodeTaprootWitness writes the annex only when there is one; it used to append an empty item, which made the witness invalid. The control block of a ScriptPathData is a list of digests, and a control block of a wrong length is refused. KeyPathSpend carries the annex of a key path spend.
• signPsbt applies the checks of the BIP 174 signer. A coin known from PSBT_IN_WITNESS_UTXO alone is signed only with a witness signature, since the legacy digest does not commit to the amount; the previous transaction is used first, and a witness output that is not its output is refused. A sighash type no node accepts, or whose fork id flag does not fit the network, is refused instead of signed. A redeem script that does not hash to the coin, or a witness script that does not hash to the witness program, is refused. An input whose coin script is not standard is left alone instead of failing the PSBT.
• finalizePsbt takes the Network and verifies every signature it uses, against the digest of the coin and the sighash type of the input when it has one, as PSBTInputSignedAndVerified does in Bitcoin Core. A signature that does not verify, is not a signature, or uses another sighash type is refused. It used to finalize any bytes stored as a signature.
• mergeTxs leaves an input that no transaction signed as it is. It used to crash with Prelude.head: empty list.
• chooseCoins takes the kinds of the outputs and a fee rate per virtual byte, and estimates the fee from the coinInputKind of each coin, a new method of Coin. chooseMSCoins, chooseMSCoinsSink, guessMSTxFee and guessMSSize are gone, since the kind of input lives on the coin. The old estimate counted every input as pay-to-public-key-hash and charged bytes rather than virtual bytes, so a SegWit wallet overpaid fees by about 60 %.
• hexToTxHash, and the Read, string and JSON forms of TxHash and OutPoint, refuse hex that is not exactly 32 bytes. Longer hex used to be accepted with its leading bytes dropped.
• Transaction parsing bounds the counts of inputs, outputs, witness stacks and witness items by maxListSize, as ReadCompactSize does in Bitcoin Core; a count of 2^64 - 1 used to wrap around and read as zero. A transaction with the witness marker but no witness item is refused (“Superfluous witness record”), as Bitcoin Core refuses it. A transaction whose witness stacks are all empty is serialized without the marker, and hasWitness is false for it.
• verifyStdTx and verifyStdInput take the coins of every input, matched by outpoint, so that Taproot inputs can be verified. A witness on an input whose coin is not a witness program is refused, as VerifyScript refuses it in Bitcoin Core, and verifyStdTx refuses outputs that spend more than the coins hold.
• nosigTxHash removes the witness as well as the input scripts, so that it is the same before and after signing a SegWit input.
• getBits raises an error for input shorter than the bits asked, getList and getLengthBytes refuse a count that does not fit an Int, and unmarshalLazy returns Either String a instead of throwing.
• setInputSequence refuses to change the sequence of an input that is signed, since every signature commits to it.
• WitnessProgram, WitnessProgramPKH, MAST, TaprootWitness and ScriptPathData have Show and Eq instances.
• The package requires secp256k1-haskell 2.0.0, whose normalizeSig is total. verifyHashSig normalises the signature with it, and isCanonicalHalfOrder is its isLowS.
• buildMerkleRoot returns Either String MerkleRoot. It fails for an empty list, which used to crash, and for a mutated tree in which two sibling nodes are identical (CVE-2012-2459). extractMatches rejects such a tree too, as CPartialMerkleTree::TraverseAndExtract does in Bitcoin Core, and reports why a partial tree is malformed.
• buildMerkleRoot, buildPartialMerkle and calcHash build the tree in linear time instead of quadratic. decodeMerkleFlags is linear too; it took a minute for 100 KB of flags, which a peer could send in a merkleblock message.
• genesisBlock no longer takes a Ctx and returns the right coinbase for every network. Bitcoin testnet4 has its own genesis coinbase, so genesisBlock btcTest4 used to return a block whose transactions did not match its header.
• The merkleroot field of the JSON form of BlockHeader is in display order, like prevblock and the getblockheader RPC call of Bitcoin Core. It was in internal byte order.
• hexToBlockHash and the JSON parser of BlockHeader reject a hash that is not exactly 32 bytes. They used to accept longer input and drop the leading bytes.
• computeAsertBits takes the proof-of-work limit of the network as its first argument instead of using the mainnet limit.
• connectBlocks adds each header to the store as it passes, so a batch with a bad header keeps the headers before it and makes the last of them the best block when it has the most work.
• Ord BlockNode compares the height and then the header, so that it agrees with Eq, which compares the header.
• appendBlocks dates every block one target spacing after its parent, so the chains it mines pass the median time past rule.
• blockLocatorNodes steps back like LocatorEntries in Bitcoin Core and lists the genesis block once.
• encodeCompact raises an error for a number wider than 255 bytes instead of wrapping the exponent.
• traverseAndBuild and traverseAndExtract are no longer exported.
• getMessage consumes exactly one message. It used to leave the payload in the stream and let the payload parser read past the declared length, so bytes outside the checksum could end up in a message. It now checks the magic before reading the payload, refuses a payload above maxMessageSize, and accepts a payload on message types that carry none, as Bitcoin Core does.
• VarInt refuses an encoding longer than the value needs, as ReadCompactSize does in Bitcoin Core. A transaction with such an encoding used to parse and re-serialize to different bytes. VarString refuses a count above maxListSize.
• MessageCommand refuses a name with a byte outside printable ASCII or with a byte other than NUL after it, as Bitcoin Core does, and serializing a name longer than twelve bytes is an error instead of a silent truncation.
• The extra field of Reject is a Maybe Hash256. It was a ByteString that only round-tripped when empty or 32 bytes long.
• Version refuses a user agent longer than 256 bytes, as Bitcoin Core does.
• BloomFilter refuses a filter above 36000 bytes or 50 hash functions when parsing, as Bitcoin Core refuses such a filterload, and reads its bytes in one go instead of one at a time. FilterAdd refuses an element above 520 bytes. BloomFlags reads only the two low bits of its byte, as Bitcoin Core does.
• bloomRelevantUpdate matches the data pushed by every output script, standard or not, and inserts outpoints according to the flags, as IsRelevantAndUpdate does in Bitcoin Core. It used to raise an error for any transaction with a non-standard output, and for a matching output that was not pay-to-pubkey or pay-to-multisig under BloomUpdateP2PubKeyOnly. It returns Just the filter whenever an output matches, unchanged under BloomUpdateNone.
• bloomInsert and bloomContains treat a filter with zero hash functions as matching everything, as Bitcoin Core does. bloomInsert used to loop over 2^32 hash functions and bloomContains used to answer False. bloomCreate gives zero hash functions for zero elements.
• bip34Block in Network is split into bip34Height and bip34Hash, the hash being optional. btcRegTest activates BIP34, BIP65 and BIP66 at height 1, as Bitcoin Core regtest does; it had the heights of Bitcoin Cash Node regtest. bchRegTest has the 32 MB block size of Bitcoin Cash Node.
• arbitraryBloomFilter generates a BloomFilter with random bits instead of a tuple.
• Replace the PSBT module with Haskoin.Transaction.Psbt, which keeps every field of a PSBT, known or not, writes maps with their keys in order as Bitcoin Core does, refuses what breaks BIP 174 (duplicate keys, keys out of shape, bytes after the last map, other versions), and reads and writes the global xpub and proprietary fields. It still creates, combines, signs, finalizes and extracts. The Haskoin.Transaction.Partial module and its types are gone.
• pubKeyWitnessAddr and pubKeyCompatWitnessAddr now return Maybe Address and refuse uncompressed keys. BIP 143 makes witness spends with uncompressed keys non-standard, so coins sent to such an address could not be spent through the normal network.
• The WitnessAddress and CashAddress constructors are now patterns that can only match. Build these addresses with witnessAddress and cashAddress, which validate the version and payload and return the dedicated constructor when one exists. Every address now has a single representation, so equal addresses compare equal.
• outputAddress and scriptToAddress no longer report the P2PKH address of the key for a pay-to-public-key output. Such coins cannot be spent with the P2PKH input script, so the address was misleading.
• convertBits in Haskoin.Util.Helpers returns Maybe [Word] and fails on padding bits that are not zero, or that are wide enough to hold a whole input digit, when padding is not allowed.
• JSON encoding of an address that has no text form on the given network now fails with an error instead of writing null.
• mnemonicToSeed NFKD-normalises the sentence and the passphrase, as BIP39 requires and as Trezor, Electrum, python-mnemonic and bitcoinjs do. A passphrase with accented letters used to give a seed that no other wallet derives, so the funds could not be restored elsewhere. fromMnemonic normalises the sentence before looking up its words. This adds a dependency on unicode-transforms.
• toMnemonic accepts 16 to 32 bytes of entropy and fromMnemonic accepts sentences of 12, 15, 18, 21 or 24 words, the sizes BIP39 allows. Entropy of 4 to 12 bytes and of 36 to 64 bytes, and sentences of 3 to 9 and 27 to 48 words, were accepted before, and no other wallet reads them. A word that is not in the list is reported with the fromMnemonic: prefix.
• xPrvImport and xPubImport require a payload of exactly 78 bytes, as Bitcoin Core does. Trailing bytes and an uncompressed public key used to be accepted. They also refuse a key at depth 0 whose parent fingerprint or index is not zero, as BIP32 test vector 5 requires.
• fromWif refuses strings longer than 52 characters, and xPrvImport and xPubImport strings longer than 112, before decoding them. No valid key is longer, and the time to decode Base58 grows with the square of the length.
• prvSubKey, pubSubKey and hardSubKey throw DerivationException when the parent is at depth 255. The depth of the child used to wrap around to 0.
• Parsing a derivation path reads each index as an unbounded integer and accepts decimal digits only. m/4294967296 used to wrap around to m/0, and hex, parenthesised and signed numbers were accepted.
• The JSON form of Sig is decoded with decodeStrictSig, like the binary form, so a high-S signature is refused by both.
• The Read instances of Hash160, Hash256 and Hash512, and textToFingerprint, refuse hex of the wrong length, as the string literal instances already did. A two-byte hash could be read and then crash signHash.
• encodeOutput returns Either String Script. It fails for a PayMulSig whose required count is not between 1 and its number of keys or that has more than 20 keys, and for a PayWitness whose version is 0 or above 16 or whose program is not 2 to 40 bytes long. Those values used to crash with an error call. marshalPut still fails with an error call for them, since it cannot report a failure.
• txSigHash and txSigHashForkId return Either String Hash256. They fail for an input index the transaction does not have. With SIGHASH_ALL, txSigHash used to return a digest over the transaction without any script code for such an index, and crash for the other hash types. makeSignature and makeSigHash return Either too.
• On a network with a fork id, txSigHash requires the SIGHASH_FORKID flag and decodeTxSig rejects a signature without it. makeSignature sets the flag, so signTx bch with a plain sigHashAll produces a signature the network accepts. It used to sign the legacy digest, which Bitcoin Cash has rejected since 2017.
• isSigHashUnknown is the test of IsDefinedHashtypeSignature in Bitcoin Core: after masking the SIGHASH_ANYONECANPAY and SIGHASH_FORKID bits, the hash type byte must be 1, 2 or 3. A byte such as 0x21 used to pass and be signed, although every node rejects it under STRICTENC.
• opPushData gives the minimal encoding of BIP 62: OP_0 for the empty string, OP_1 to OP_16 for one byte from 1 to 16 and OP_1NEGATE for the byte 0x81. The empty push used to be an OP_PUSHDATA that serialized to the byte of OP_0 but was not equal to it.
• DataCarrier holds the data of every push after OP_RETURN, as a list, since TxoutType::NULL_DATA of Bitcoin Core is OP_RETURN followed by any pushes. A bare OP_RETURN, several pushes and an empty push used to be “Non-standard output”.
• intToScriptOp returns Either String ScriptOp instead of crashing outside 1 to 16. scriptOpToInt no longer serializes its argument, so it cannot crash on an OP_PUSHDATA whose payload does not fit its type.
• sortMulSig returns any output that is not a multisig unchanged instead of crashing.
• decodeInput reads the input of a pay-to-script-hash output as its redeem script requires. A multisig template with the redeem script and no signature yet, OP_0 <redeem>, is a SpendMulSig [], which mergeTxs used to reject. An input that does not fit its redeem script fails.
• The generators of Haskoin.Util.Arbitrary.Script produce pushes of every PushDataType, pushes that are not minimal, multisig outputs of up to 20 keys, data carriers with any number of pushes, nested witness inputs, and, on networks with a fork id, only hash types with the flag.

Fixed

• A block whose timestamp equals the median time past of its parent is rejected, as in Bitcoin Core. It used to be accepted.
• connectBlocks keeps the block that was seen first as the best block when a competing block has the same work and height, as connectBlock and Bitcoin Core do. It used to switch the best block to every competitor.
• calcNextWork and computeTarget measure the time span of a retarget period as a signed number. A period whose last block is dated before its first block used to wrap around to four times the target timespan instead of being limited to a quarter.
• headerWork returns zero for bits that are negative, overflow or encode a zero target, like GetBlockProof in Bitcoin Core. It used to divide by zero for bits 0x03800001.
• The block version is compared as a signed number, as in Bitcoin Core, so versions with the top bit set are rejected once BIP34 is active.
• The Bitcoin Cash difficulty algorithms follow Bitcoin Cash Node: the minimum-difficulty rule of test networks applies to the ASERT algorithm and no longer applies to the EDA and DAA algorithms on mainnet, the EDA returns the bits of the last block without minimum difficulty on test networks, getSuitableBlock picks the same block as Bitcoin Cash Node when timestamps are equal, computeTarget no longer overshoots by one, the ASERT anchor is the first block whose own median time past reaches the activation time, and regtest never retargets.
• A PSBT of another version is refused by its version. The unsigned transaction was looked for first, and a PSBT of version 2 holds none.
• addressBytes returned a length-prefixed value for a generic CashAddr instead of the raw hash.
• Base58, Bech32 and CashAddr decoders accepted non-ASCII look-alike characters. Base58 truncated code points to one byte and Bech32 used Unicode case folding. All three now accept ASCII only, as the specifications require.
• cashAddrDecode accepted mixed-case strings, which the CashAddr specification rejects.
• CashAddr decoding accepted non-canonical strings whose padding bits were not zero, or that carried an extra group of padding, so several strings could stand for the same address.
• textToAddr decoded Base58 input of any length, with a cost growing with the square of the length. Strings longer than any valid address are now rejected first.
• Binary deserialization of an address now validates the witness version, the CashAddr type and the payload length, and checks the length prefix before converting it to an Int. Previously an invalid value could be read and later crash addressToScript.
• The Bech32 and bit conversion accumulators are masked so that they cannot overflow on long inputs.
• encodeOutput had no case for PayScript32Hash and crashed on it, so a P2SH32 address could not be turned into a script.
• The P2WSH test generator produced P2WPKH addresses.
• fromWif threw an exception on a Base58Check string with an empty payload, such as 3QJmnh, also through the JSON parser of PrivateKey. It returns Nothing now.
• The JSON parser of PublicKey accepted bytes after the key.
• decodeOutput matches the output templates on their exact bytes, as Bitcoin Core does. A script that wrote the hash of a P2PKH, P2SH, P2SH32 or witness output with OP_PUSHDATA1 or a longer push used to decode as that output and give its address. By consensus such a script is not a P2SH or witness output at all, and anyone can spend it, so a wallet could credit a payment to its address that was not one.
• A public key pushed in a script or a witness must fill its push. A 65-byte item that starts with 0x02 or 0x03 used to parse as the 33-byte key it starts with, so decodeOutput, decodeInput and the witness decoders reported a key the script did not hold, and verifyStdTx accepted a P2PKH or P2WPKH spend whose key item carried 32 extra bytes, which no node accepts.
• verifyStdInput returns False for an input index the transaction does not have, and parseExistingSigs reads no witness signatures when the witness list is shorter than the input index. Both used to crash.

[1.4.0] - 2026-10-31

Added

• Bitcoin testnet4 network (btctest4) with the BIP94 block storm and time warp rules.

Changed

• Update DNS seeds to match Bitcoin Core and Bitcoin Cash Node. Drop the Bitcoin ABC seeds, which now serve eCash.
• This package now requires base16 2.0 and secp256k1-haskell 0.7.

Fixed

• Compute the difficulty retarget in nextPowWorkRequired and nextEdaWorkRequired, which never reached their retarget branches.
• Fix the Bitcoin Cash DAA activation height, which had a typo (404031 instead of 504032).
• Start the DAA one block later on Bitcoin Cash testnet and testnet4, to match Bitcoin Cash Node.
• Fix the Bitcoin Cash ASERT half-life, which must be two days.

[1.3.0] - 2026-08-12

Changed

• Make script and address parsing more strict.
• Use smart constructors for addresses to avoid inconsistent or incorrect represtentations.

Fixed

• Support Bitcoin Cash 256-bit pay-to-script-hash scripts and addresses.
• Make addresses of incorrect length invalid.
• Avoid decoding scripts as standard when hash or public key length incorrect.
• Fix secp256 library function names.

[1.2.2] - 2025-05-08

Changed

• Standardize author name and correct README link.

[1.2.1] - 2025-05-08

Changed

• New home in github.com/jprupp rather than github.com/haskoin.

[1.2.0] - 2023-07-23

Changed

• Move from cryptonite to crypton for now.

[1.1.0] - 2023-03-14

Changed

• Update upstream dependencies & LTS Haskell.

[1.0.4] - 2023-10-09

Changed

• Export the BIP39 word list
• Add new BIP39 test vectors

[1.0.3] - 2023-09-02

Changed

• New dependency on data-default
• Renamed some arbitrary (test) functions for clarity
• Reworked the identity testing tool to include Marshal and MarshalJSON classes

[1.0.2] - 2023-08-04

Fixed

• Text files needed for testing now in tarball.

[1.0.1] - 2023-08-03

Changed

• Do not use alternative monad for Either String values.

[1.0.0] - 2023-07-28

Changed

• Shorten all field names allow duplicates, using DuplicateRecordFields extension.
• Use OverloadedRecordDot language extension and syntax.
• Use explicit context object from secp256k1-haskell library.
• Unify serialization into custom Marhsal and MarshalJSON classes.
• Use ormolu for formatting.
• Simplify module organisation.
• Strongly break backwards compatibility.

[0.22.0] - 2023-06-28

Changed

• Upgrade to lastest secp256k1 and base16 packages.

[0.21.2] - 2022-04-13

Changed

• Serialisation test now works for both strict and lazy bytestrings.

[0.21.1] - 2021-12-13

Changed

• Make Base58 faster.

[0.21.0] - 2022-11-23

Added

• BCH Testnet4 support.

Changed

• Fix inconsistent serialization/deserialization issues.

Fixed

• Makes finalScriptWitness field encoding conform to bitcoin core.
• Fixes bug in finalizeTransaction

Added

• Signing support for PSBTs
• Helper function for merging PSBTs
• More PSBT tests
• Partial support for taproot

[0.20.5] - 2021-09-13

Added

• Support Bech32m address format for Taproot.

[0.20.4] - 2021-06-08

Fixed

• Add missing case for witness version.

[0.20.3] - 2021-05-17

Fixed

• Allow unknown inv types.

[0.20.2] - 2021-05-17

Fixed

• Allow unknown messages of zero length.

[0.20.1] - 2021-05-14

Fixed

• Correct case where binary search returned the wrong element.

[0.20.0] - 2021-02-22

Chaged

• Use bytes instead of binary or cereal.

[0.19.0] - 2021-01-25

Added

• Hashable instances for extended keys.

Changed

• Mnemonic passphrases now Text instead of ByteString.

Fixed

• Tests now pass for witness addresses.

[0.18.0] - 2020-12-10

Added

• Support SegWit addresses with version other than 0.

[0.17.6] - 2020-12-07

Added

• Serialize instances for XPubKey and XPrvKey.

[0.17.5] - 2020-12-03

Fixed

• Handle special case in block header binary search function.

[0.17.4] - 2020-12-03

Fixed

• Bounds check too restrictive in block header binary search function.

[0.17.3] - 2020-11-17

Changed

• Reduce minimum version of text package dependency.

[0.17.2] - 2020-11-17

Changed

• Update lists of seeds for all networks.

[0.17.1] - 2020-11-02

Changed

• Use the C-preprocessor to handle versions of base16-bytestring

[0.17.0] - 2020-10-21

Added

• Support for Bitcoin Cash November 2020 hard fork.
• Functions to find block headers matching arbitrary sorted attributes.

Removed

• GenesisNode constructor for BlockNode type.

[0.15.0] - 2020-07-23

Added

• Add more test vectors

Changed

• stringToAddr renamed to textToAddr
• Move ScriptOutput to Standard.hs
• Move WIF encoding/decoding to Keys.hs
• (breaking) rename OP_NOP2 and OP_NOP3 to OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY resp.
• Update to latest secp256k1 bindings.

[0.14.1] - 2020-06-14

Fixed

• Correct some Bitcoin Cash Testnet3 seeds.
• Add helpers for writing Data.Serialize and Data.Aeson identity tests

[0.14.0] - 2020-06-14

Changed

• Expose all modules for tests.
• Tests depend on library instead of having access to its source code.
• Use MIT license.
• Update seeds.
• Bump secp256k1-haskell dependency.

[0.13.6] - 2020-06-05

Changed

• Expose the Arbitrary test instances under Haskoin.Util.Arbitrary

[0.13.5] - 2020-05-16

Changed

• Provide meaningful JSON instances for most types.

[0.13.4] - 2020-05-14

Added

• Support for Bitcoin Cash May 2020 hard fork.

[0.13.3] - 2020-05-08

Changed

• Improve code and documentation organisation.

[0.13.2] - 2020-05-08

Changed

• Move all packages from Network.Haskoin namespace to Haskoin namespace.
• Expose all top-level modules directly.

[0.13.1] - 2020-05-06

Changed

• Faster JSON serialization.

[0.13.0] - 2020-05-06

Changed

• Consolidate all modules in Haskoin module.

Removed

• Deprecate Network.Haskoin namespace.
• Hide QuickCheck generators in test suite.

[0.12.0] - 2020-04-10

Added

• Support for signing segwit transactions.
• High-level representation of segwit v0 data and auxilliary functions.

Changed

• Adds handling of segwit signing parameters to transaction signing code.

[0.10.1] - 2020-02-08

Added

• Lower bound versions for some dependencies.

[0.10.0] - 2020-01-15

Added

• DeepSeq instances for all data types.

Changed

• There is no SockAddr inside NetworkAddress anymore.

[0.9.8] - 2020-01-01

Added

• Ord instance for DerivPathI

[0.9.7] - 2019-12-04

Added

• JSON encoding/decoding for blocks.

Fixed

• Fix lowercase HRP test for Bech32.

[0.9.6] - 2019-10-29

Added

• bloomRelevantUpdate implementation for Bloom filters (thanks to @IlyasRidhuan).

Fixed

• Fix for Bech32 encoding (thanks to @pavel-main).

[0.9.5] - 2019-10-23

Added

• Expose functions added in 0.9.4.

[0.9.4] - 2019-10-23

Added

• Support for (P2SH-)P2WPKH addresses derived from extended keys.

Changed

• Change names of backwards-compatible P2SH-P2WPKH functions from 0.9.3.

[0.9.3] - 2019-10-22

Added

• Some support for P2WPKH-over-P2SH addresses.

[0.9.2] - 2019-10-09

Removed

• Disable unnecessary -O2 optimisation added in previous version.

Added

• Allow decoding unknown P2P messages.

[0.9.1] - 2019-10-02

Added

• Add a function to produce a structured signature over a transaction.
• Enable -O2 optimisations.

[0.9.0] - 2019-04-12

Changed

• Address conversion to string now defined for all inputs.

[0.8.4] - 2018-12-05

Added

• Add reward computation to block functions.
• Add PSBT BIP-174 types and functions.

[0.8.3] - 2018-12-04

Added

• Add reward halving interval parameter to network constants.

[0.8.2] - 2018-11-06

Added

• Recognize OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY opcodes.

[0.8.1] - 2018-10-13

Added

• Add instances of Hashable and Generic where possible.

[0.8.0] - 2018-10-13

Removed

• Remove deepseq dependency.
• Remove network constant reference from address and extended keys.

[0.7.0] - 2018-10-13

Added

• Add Serialize instance for network constants.
• Add Serialize instance for addresses that includes network constants.

Changed

• Move functions related to addresses from Script to Address module.

[0.6.1] - 2018-10-09

Added

• Compatibility with latest GHC and base.

Changed

• Update minimum base to 4.9.

[0.6.0] - 2018-10-08

Changed

• Force initialization of addresses through smart constructor.
• Assume addresses are always valid when instantiated in code.
• Allow to provide unwrapped private keys to transaction signing functions.

[0.5.2] - 2018-09-10

Changed

• Make dependencies more specific.

[0.5.1] - 2018-09-10

Changed

• Remove some unneeded dependencies from stack.yaml.
• Change secp256k1 dependency to secp256k1-haskell.

[0.5.0] - 2018-09-09

Added

• Support for Bitcoin Cash network block sychronization.
• Support for Bitcoin Cash signatures.
• Initial work on SegWit support.
• New version of secp256k1 bindings.
• Block header validation.
• Support for RegTest networks on Bitcoin and Bitcoin Cash.
• Support for Bitcoin Cash Testnet3 Network.
• Support for new Haskoin Wallet.
• Minikey decoding for Casascius coins.
• New tests for various networks and new features.
• Added CHANGELOG.md file.
• Support for SegWit addresses.
• Support for CashAddr addresses.

Changed

• Use of hpack package.yaml file to auto-generate Cabal file.
• Removal of dependency version limits, relying on stack.yaml instead.
• Tests moved to hspec.
• New documentation.
• Updated .gitignore.
• Renamed network constants to use same style for BTC and BCH.
• Network constants must be passed explicitly.
• Target LTS Haskell 12.9.

Removed

• Removed .stylish-haskell.yaml files.
• Removed old haskoin-node and haskoin-wallet packages from main repository.
• Removed support for non-strict signatures and related tests.
• Removed script evaluator and related tests.