Bitcoin SV Version 1.2.2 Release Notes

Overview

The 1.2.2 node release is an optional upgrade from version 1.2.1 that contains several improvements and bug fixes.

Important fixes and improvements in 1.2.2

• Relaxed and corrected the IsStandard transaction checks post-Chronicle, including the transaction version range and the push-only check on the scriptSig.
• Added a new disk-backed P2P message parser. Messages above the configured memory limit are now streamed to a temporary file on disk instead of being held entirely in memory.

Other items

• Dead code removal.
• General minor bug fixes, code-quality improvements and hardening.

New or modified configuration options

• -acceptnonstdtxn is now accepted on all chains, including mainnet (previously restricted to testnet and regtest).
• -maxreceivebuffer additionally controls the in-memory size limit used by the new disk-backed P2P message parser; P2P messages larger than this limit are streamed through a temporary file on disk.

Bitcoin SV Version 1.2.1 Release Notes

Overview

The 1.2.1 node release is a mandatory upgrade from version 1.2.0 that contains several important bug fixes and improvements.

Important fixes in 1.2.1

• Fixed incorrect script stack memory usage tracking for some new Chronicle opcodes.
• Removed an assert in blocktxn message processing that could be triggered by a malicious peer sending a carefully crafted duplicate blocktxn message.
• Fixed the handling of malformed coinbase transactions with bad minerID miner info.
• Fixed inconsistent handling of an invalid minerID document during a reorg.
• Fixed a bug in REST API handling that didn't correctly parse negative ranges.
• Fixed libevent related issues that could cause out of memory in the node if a webhook endpoint sent excessively large payloads or headers.
• Fixed incorrect hashing of a dsdetected P2P message.

Other items

• Improved the reliability of a number of functional tests.
• Migrated the functional test framework from asyncore to selectors module.
• Dead code removal.
• General minor code fixes and improvements.

New or modified configuration options

• -minerid enable option is now off by default.
• -dsnotifylevel option is now 0 by default.
• -rpcwebhookclientmaxresponsebodysize sets the maximum response body size that the node will accept from a webhook client.
• -rpcwebhookclientmaxresponseheadersize sets the maximum response header size that the node will accept from a webhook client.
• -importsync is a new debug option that forces the node to load all data from disk synchronously, which can be useful for testing and debugging.

Bitcoin SV Version 1.2.0 Release Notes

This release is a hard fork which includes changes to the BSV protocol. 

The scheduled TestNet activation height is 1,713,168 (Target is 12:00 midday 14-Jan-2026)

The scheduled MainNet activation height is 943,816 (Target is 12:00 midday 07-Apr-2026)

Release Summary

The Chronicle release is a follow-up of the Genesis upgrade in 2020 which
restored many aspects of the original Bitcoin protocol and removed many
previously imposed limitations. The Chronicle release continues this
process and incorporates the following main features:

• Restoration of Bitcoin's Original Protocol: The Chronicle release
  re-introduces several opcodes that were previously disabled or removed
  from the script language.
• Transaction Digest Algorithms: The BSV Blockchain will now support the
  Original Transaction Digest Algorithm (OTDA), in addition to the current BIP143
  digest algorithm. Usage of the OTDA will require setting the new CHRONICLE
  [0x20] sighash flag.
• Selective Malleability Restrictions: The Chronicle Release removes
  restrictions that were put in place to prevent transaction malleability.
  To address concerns about the re-introduction of sources of transaction
  malleability, the application of malleability restrictions will depend on
  the transaction version field. Transactions signed with with a version number
  higher than 1 [0x01000000] will allow relaxed rules, removing strict
  enforcement of malleability-related constraints. The relevant restrictions
  are:
  • Minimal Encoding Requirement
  • Low S Requirement for Signatures
  • NULLFAIL and NULLDUMMY check for OP_CHECKSIG and OP_CHECKMULTISIG
  • MINIMALIF Requirement for OP_IF and OP_NOTIF
  • Clean Stack Requirement
  • Data Only in Unlocking Script Requirement

Transaction Digest Algorithms

As mentioned above, in the Chronicle Release, the Original Transaction Digest
Algorithm (OTDA) is being reinstated for use.

This change will depend on the usage of the new CHRONICLE [0x20] Sighash
bit. By default, users who do nothing will retain the current behaviour (with
CHRONICLE disabled).

Increase the Limit on the Size of Script Numbers

The consensus limit for the maximum size of script numbers will be increased
from 750KB to 32MB. Node operators can continue to set their policy limit for
the size of script numbers using the maxscriptnumlengthpolicy configuration
parameter.

Selective Malleability Restrictions

The Chronicle Release will remove malleability-related restrictions during
script evaluation. For any transactions signed with a version field greater
than 1 [0x01000000], the restrictions below will no longer apply to the
transaction. This behaviour requires users and developers to "opt-in", as any
transactions that continue to use a version field of 1 [0x01000000] will
keep these restrictions. The malleability-related restrictions being removed
are:

• Minimal Encoding Requirement: The requirement that data elements on
  the stack are required to be expressed using the minimum number of bytes.
• Low S Signatures: The requirement that the signature must be the low
  "S" value. See BIP-146.
• NULLFAIL Checks: The requirement that all signatures passed to an
  OP_CHECKSIG or OP_CHECKMULTISIG must be empty byte arrays if the result
  of the signature check is FALSE.
• NULLDUMMY Checks: The requirement that the dummy value consumed by an
  OP_CHECKMULTISIG is equal to zero.
• MINIMALIF Requirement: The input argument to the OP_IF and OP_NOTIF
  opcodes is no longer required to be exactly 1 (the one-byte vector with value 1)
  to be evaluated as TRUE. Similarly, the input argument to the OP_IF and
  OP_NOTIF opcodes is no longer required to be exactly 0 (the empty vector) to
  be evaluated as FALSE.
• Clean Stack Policy: The requirement that the stack has only a single
  element on it on completion of the execution of a script.
• Data Only in Unlocking Scripts Requirement: The requirement that unlocking
  scripts only include data and associated pushdata op codes. Note that the
  script-code that forms part of the hash pre-image for signature verification by
  an OP_CHECKSIG or OP_CHECKMULTISIG within an unlocking script is defined
  to be everything from the opcode after the last OP_CODESEPARATOR (or the start
  of the script if there has not been an OP_CODESEPARATOR) to the end of the
  unlocking script, plus the entire concatenated locking script.

Script OpCodes

The following opcodes are restored:

• OP_VER – pushes the transaction version (4 byte array) onto the top of the stack.
• OP_VERIF, OP_VERNOTIF – provides conditional logic based on the transaction version.
• OP_SUBSTR – creates an arbitrary substring of the string on top of the stack.
• OP_LEFT, OP_RIGHT – creates the left/right most substring of specific length from the string on the top of the stack respectively.
• OP_2MUL – doubles the number on top of the stack.
• OP_2DIV – halves the number on top of the stack.

The following new opcodes are introduced:

• OP_LSHIFTNUM - numerically left shifts a value by the specified number of bits.
• OP_RSHIFTNUM - numerically right shifts a value by the specified number of bits.

Chronicle Protocol Specification

Please refer to the Chronicle Protocol Restoration
specification for further details on all of the above.

Performance Improvements

Memory Usage

TCMalloc is now the default memory allocator used when building bitcoind. In
testing, this change results in peak memory usage of the node dropping by nearly
a half.

Initial Block Download (IBD)

By tuning some existing leveldb configuration parameters, introducing some new
configuration options and optimising the code, the time taken to perform a
complete IBD has been reduced. See the section below for details on the new
config options.

Config Variables

Mempool Synchronisation

A new feature has been introduced to allow nodes to be configured to periodically
update their mempools with missing transactions from other specified peers. Note
that peers that wish to synchronise mempools must be configured symmetrically, i.e.
both peers must be configured to sync' with each other.

The options to configure this are:

• mempoolsyncpeer - Specify IPs or subnets of peers with which we want to
  periodically synchronise mempools. Can be used more than once to specify
  multiple peers / networks.
• mempoolsyncage - Only transactions older than this age will be included
  in synchronisation.
• mempoolsyncperiod - How often synchronisation takes place.

Other New Options

• preferredblockfilesize - Preferred size (in bytes) of a single block datafile.
• maxcoinsdbfilesize - Set maximum file size used by the coins database.
• maxconnections - Maintain at most the given number of connections to peers.
• maxchroniclegracefulperiod - The number of blocks either side of the Chronicle
  activation height that we will give peers some grace if they are not yet fully
  activated before banning them.

Removed Options

• maxsendbuffermult

Changes to Existing Defaults

• dbcache - The default database cache size is now 2GB.

Other Items

• STN Reset - includes an updated chain height block hash.
• Various minor bug fixes, intermittent test failure fixes and code quality improvements.
• Update to version 0.5.1 of libsecp256k1.

Bitcoin SV Version 1.1.1 Release Notes

Overview

This is an optional minor patch release to the Bitcoin SV Node Software version 1.1.0. It includes a change to allow node operators to run the software with both the 'txindex' and 'prune' options enabled.

Transaction Index with Pruning

The restriction that prevented the use of both 'txindex' and 'prune' options together has been removed. If you attempt to request the details for a transaction that is in a block that has been pruned, then the node will simply return an error indicating that the transaction cannot be found.

Bitcoin SV Version 1.1.0 Release Notes

Overview

Security enhancements and peer management features for node operators are the main features included in this release.

The 1.1.0 node release is a recommended upgrade from version 1.0.16.

Security Enhancements

• Network peer connection management.
  • Configurable numbers of:
    • pending p2p message response queue management.
    • connections from the same IP address.
    • connections to both inbound and outbound peers.
• General code security enhancements.

Security Dependency Updates

• Updated secp256k1 library version.
• Updated OpenSSL library version in build system.

Alert System

Version 1.1.0 reintroduces the Alert System. The Alert System, originally implemented in the v0.3.10 Bitcoin release, enables the BSV Association to send signed messages to the network. Messages can be of an informational or directive nature. This release also contains native support for Digital Asset Recovery alerts.

Node operators are required to run the Alert System in conjunction with the BSV Node. Node operators who do not interact with the Alert System risk being banned and/or having their blocks rejected by node operators who do.

Detailed instructions on how to run the Alert System are available here: node.bitcoinsv.io/sv-node/alert-system.

Network Access Rules

The BSV Association is also releasing the BSV Blockchain Network Access Rules. The Network Access Rules formalize the terms and conditions for operating a node on the BSV Blockchain. Read more about the Network access rules here: bsvblockchain.org/network-access-rules.

Updated Open BSV License

The Open BSV License has been updated to version 5 and is available here: github.com/bitcoin-sv/bitcoin-sv/blob/v1.1.0/LICENSE.

Other items

• STN Reset - includes an updated chain height block hash.
• Include GitHub workflows configuration file structure.

Specific Configuration Details

Inbound and Outbound Connection Management

Max Connections gives node operators flexibility in how to manage peers they interact with on the network.

Configuration parameter	Default value	Description
maxconnections	125	Maintain at most n connections to peers
maxconnectionsfromaddr	0	Maximum number of inbound connections from a single address. Not applicable to whitelisted peers. A value of 0 = unrestricted
maxpendingresponses_getheaders	0	Maximum allowed number of pending responses in the sending queue for received GETHEADERS P2P requests before the connection is closed. Not applicable to whitelisted peers. The main purpose of this setting is to limit memory usage. The specified value should be small (e.g. ~50) since in practice connected peers do not need to send many GETHEADERS requests in parallel. A value of 0 = unrestricted.
maxpendingresponses_gethdrsen	0	Maximum allowed number of pending responses in the sending queue for received GETHDRSEN P2P requests before the connection is closed. Not applicable to whitelisted peers. The main purpose of this setting is to limit memory usage. The specified value should be small (e.g. ~10) since in practice connected peers do not need to send many GETHDRSEN requests in parallel. A value of 0 = unrestricted.

Bitcoin SV Version 1.0.16 Release Notes

The 1.0.16 node release is a recommended upgrade from version 1.0.15.1.

Features in 1.0.16

• SAST scan updates to improve code safety.
• Tuned compiler configuration parameters.
• Tuned build benchmark configuration parameters.
• Fixed core dump in shutdown routine occasionally encountered while running the functional tests framework.
• Address sanitizer bug fixes.
• Guards against a potential race condition.
• Thread management optimisation.
• Ecosystem improvement proposal.

Other items

• STN Reset - includes an updated chain height block hash.

Bitcoin SV version 1.0.15.1 Release Notes

Overview

The 1.0.15.1 node release is a recommended upgrade from version 1.0.15.

Features in 1.0.15.1

• Refactor to remove possible exploit in p2p layer.
• Ecosystem improvement proposal.

Other items

• Additional functional tests.

New or modified configuration options

• None

Bitcoin SV version 1.0.15 Release Notes

Overview

The 1.0.15 node release is a recommended upgrade from version 1.0.14.

Headline Items in 1.0.15

1. Memory usage optimisations.
2. Build updates:
   1. C++ v20.
   2. Ubuntu 20.04 LTS.
   3. CentOS 9.
3. STN Network reset.

Detailed features of 1.0.15

Memory Usage Optimisations

In this release we have updated the software to reduce peak memory consumption during the receipt of large p2p messages - specifically block, blocktxn and cmpctblock messages.

Build Updates

In this release we have updated the tooling used to build the node software and the target operating systems supported by the pre-built node binaries. This has the following main consequences:

Pre-built binaries

The pre-built binaries will run on the following supported platforms:

• Ubuntu 20.04 LTS (or later).
• Debian 11 bullseye (or later).
• Centos 9 (or later).

Running the node on different or older versions of Linux is still possible but will require manually building from source.

This release has also been updated to use the latest upstream version 0.3.1 of the secp256k1 library.

Building from source

Building the node software from source requires at least version 10.2 of the GCC compiler and at least version 1.74 of the Boost libraries.

See the instructions in build-unix.md for a detailed description on how to build from source, or alternatively see the provided docker images here of suitable build environments already setup (scripts to generate the docker images can be found here).

Other items:

• The Scaling Test Network (STN) has been reset at block height eight. This block has hash 0000000074230d332b2ed9d87af3ad817b6f2616c154372311c9b2e4f386c24c.

Other new or modified configuration options

• -maxconnections has been removed.
• -maxoutboundconnections has been added (default=8).

Bitcoin SV version 1.0.14 Release Notes

Overview

The 1.0.14 node release is a recommended upgrade from version 1.0.13.

Headline Item in 1.0.14

1. Node Freezing issue resolution (increased responsiveness)

Detailed features of 1.0.14

• Parallel transaction validation (PTV) during block validation.

Other items:

• Fixes to unit / functional tests.
• A fix to reduce the memory used by the node when responding to getblocktxn requests and to better track the memory usage across P2P message queues.
• An improvement to how the node handles prioritising an existing transaction via the sendrawtransaction RPC which may have unnecessarily resulted in the next block template returned from the journaling block assembler containing fewer transactions than it could.
• The log message if the node runs out of disk space has been extended to give more information.
• Some build warnings and failures on newer platforms and compilers have been fixed.
• Bump OpenSSL version used by the Gitian build to 1.1.1t.
• Make the maximum number of P2P addnode peers configurable.
• Optimise locking code related to rollingMinimumFeeRate.

Community contribution submitted to Github:

• RPC REST requests to fetch a binary block now have basic HTTP range header request support. For example; Range: bytes=1024-2048
• Log message clarification around free RAM

PTV during block validation

This change allows the node to fully take advantage of all available cores during block validation. Tests on 8, 16 and 32 core machines have shown it reduces block validation times, makes the node more responsive, and improves scalability. It also helps slightly reduce initial block download times.

Most users will not need to do anything to do anything to take full advantage of this change, however the following configuration options have been added to control the behaviour:

• -blockvalidationtxbatchsize: Sets the minimum batch size for groups of transactions to be validated in parallel. For example; if this is set to 100 on an 8 core machine, and an incoming block contains 500 transactions then those transactions will be validated in 5 parallel batches of 100. A 1000 transaction block would be validated in 8 parallel batches of 125.
• -txnthreadsperblock: Sets the number of transaction validation threads used to validate a single bock. Defaults to the number of cores available on the machine, but can be raised or lowered if required.

Other new or modified configuration options

An addition to any previously mentioned changes, the following node configuration options have either been introduced or changed:

• -blockdownloadlowerwindow: A new option to further limit the block download window size during IBD in order to help the node hit any configured pruning target. If pruning is not enabled then this will default to the same as the standard block download window size. An operator may choose to reduce this value even if pruning is not enabled which will result in the node using less disk space during IBD but at the possible cost of a longer IBD time. Conversely, an operator of a pruned node may choose to increase this value to reduce the time it takes to perform IBD but at the possible cost of exceeding the pruning target at times.
• -pruneminblockstokeep: An advanced option to override the minimum number of last blocks a node will keep on disk. Normally this should not be changed, but this option allows an operator to temporarily reduce this from the default value of 288 blocks in combination with the -prune option if they need to really restrict the amount of space taken up by block data.
• -maxaddnodeconnections: A new option to set the maximum number of peers that can be connected to with the addnode configuration option or RPC command. This limit was previously hard-coded to 8.

Bitcoin SV version 1.0.13 Release Notes

Overview

The 1.0.13 node release is a recommended upgrade from version 1.0.11.

Main features of this upgrade are

• Miner ID specification v1.0 support.
• Authenticated Connections handshake.
• Enhanced P2P hdrsen message.
• The Data Asset Recovery Alert support (DARA).

To take full advantage of Miner ID features, this release should be run in conjunction with Miner ID Generator 1.0.

The changes to NOMP are not available from the official NOMP website.

Miner ID

Miner ID is a cryptographic way for miners to declare that they created a particular block on the blockchain by adding information to the coinbase transaction in the block header.

The miner ID information can include data such as server endpoints and contact details, information which users need to be able to trust. It is important that a 3rd party who mines a block cannot pretend to be another miner.

The specification can be found at 'https://github.com/bitcoin-sv-specs/brfc-minerid'. 1.0.13 supports Miner ID specification v1.0 as well as earlier versions.

Security Features

It is possible that the miner ID private key can become compromised (e.g. a disgruntled employee passes it onto a 3rd party). In this case, the miner ID specification provides a mechanism for rolling miner ID keys (private and public), or the complete revocation of miner ID keys (private and public). I.e. operations include

• Roll miner ID to a new value.
• Forcibly roll miner ID to a new value using the revocation key (used for example if the miner ID key was already compromised and rolled away to a value not controlled by the legitimate owner of the miner ID)
• Forcibly revoke all miner ID keys.

The user is directed to https://github.com/bitcoin-sv/minerid-reference for other operations and further details.

Miner ID Key Storage

• No private key information is stored in the node.
• The Miner ID private key is read/written and stored locally by the Miner ID Generator. Miners who have security concerns should use file permissions to restrict access to local Miner ID Generator files.
• The Miner ID revocation key should be stored off-line so that it is not available to developers, and only supplied and used when it is needed.

New RPCs

The following RPCs have been introduced to the node as part of Miner ID work.

RPCs intended to be used by the Generator are:

1. revokeminerid - revokes minerId public key specified in the request and sends out the P2P revokemid message to known peers.
2. getmineridinfo - checks if the requested minerId public key is present in the Miner ID DB and returns its state along with related revocation public keys.

RPCs used by the Mining Software to communicate with Nodes from the mining pool:

1. createminerinfotx - creates a miner-info transaction containing a miner-info output script specified in the request.
2. replaceminerinfotx - replaces in-mempool miner-info transaction by a new one containing a new miner-info output script specified in the request.
3. getminerinfotxid - returns in-mempool miner-info txid.
4. createdatareftx - creates a data-ref transaction containing a dataRefs output script(s) specified in the request.
5. getdatareftxid - returns in-mempool data-ref txid.

RPCs used by a mining node's operator:

1. rebuildminerids - forces a rebuild of the Miner ID DB and synchronises it to the blockchain.
2. dumpminerids - returns details for all currently known miner IDs.
3. makeminerinfotxsigningkey - creates a private BIP32 key used to sign miner-info and data-ref transactions.
4. getminerinfotxfundingaddress - returns Base58 encoded BSV address generated from the private key and used to fund miner-info and data-ref transactions.
5. setminerinfotxfundingoutpoint - sets miner-info funding outpoint to be used by miner-info and data-ref transactions.
6. datarefindexdump - returns details for all currently stored miner-info and data-ref transactions from the dataRef index.
7. datareftxndelete - deletes the specified miner-info or data-ref transaction from the dataRef index.

Configuration Options

Parameters to control the miner ID database are:

• -minerid - Enable or disable the miner ID database (default: true).
• -mineridcachesize - Cache size to use for the miner ID database (default: 1MB).
• -mineridreputation_m - Miners who identify themselves using miner ID can accumulate certain privileges over time by gaining a good reputation. A good reputation is gained by having mined M of the last N blocks on the current chain. This parameter sets the M value for that test. (default: 28).
• -mineridreputation_n - This parameter sets the N value for the above test. (default: 2016)
• -mineridreputation_mscale - Miners who lose their good reputation can in some circumstances recover that reputation, but at the cost of a temporarily increased M of N block target. This parameter determines how much to scale the base M value in such cases. (default: 1.5).

revokemid P2P message format

A revokemid P2P message is used to notify other nodes that a miner ID has been revoked. The message means that a miner does not have to wait until it wins another block before it can notify other nodes.

Field Size	Name	Data Type	Description
4	version	uint32_t	Identifies MinerID protocol version
33	revocationKey	uint8_t[33]	The current revocation key ECDSA (secp256k1) public key represented in compressed form as a 33 byte hex string. It is required to verify the first signature defined in the revocationMessageSig field.
33	minerId	uint8_t[33]	The miner's current minerId ECDSA (secp256k1) public key represented in compressed form as a 33 byte hex string. It is required to verify the second signature defined in the revocationMessageSig field.
33	revocationMessage	uint8_t[33]	Revocation message to be signed to certify the legitimate miner who wants to revoke past reputation The field contains the compromised minerId public key (in the case of complete revocation it is the minerId public key defined by the initial Miner ID document).
variable	revocationMessageSig	uint8_t[]	The field defines two different signatures on theHash256(revocationMessage)message digest. sig1 := Sign(Hash256(revocationMessage), priv_revocationKey), where_priv_revocationKey_is the private key associated with the_revocationKey_public key sig2 := Sign(Hash256(revocationMessage), priv_minerId), where_priv_minerId_is the private key associated with the miner's current_minerId_public key sig1andsig2are 70-73 byte hex strings sig1_length := sig1.length() sig2_length := sig2.length() msgsig_part1 :=concat(sig1_length, sig1) msgsig_part2 :=concat(sig2_length, sig2) revocationMessageSig := concat(msgsig_part1, msgsig_part2), where the data layout is:sig1_length|sig1|sig2_length|sig2 The above concatenations are done on the hex encoded bytes.

gethdrsen and hdrsen P2P messages

Remote peers can use P2P message_gethdrsen_to request block headers together with contents of coinbase transaction and its proof of inclusion plus any referenced miner-info transaction and its proof of inclusion. Headers with those transactions and proofs of inclusion are returned to the requesting peer in P2P message_hdrsen_. Peers can also request to receive block announcements in form of_hdrsen_P2P message. Primary users of this P2P message are SPV clients which may require simplified access to MinerID provided in coinbase transaction.

Field Size	Name	Data Type	Description
1+	count	var_int	Number of enriched block headers May be 0 if no header matches parameters specified in gethdrsen message. No more than 2000 enriched block headers are returned in a single message. Since the contents of coinbase transactions can be large, maximum size of hdrsen message is limited to maximum packet size that was agreed on in protoconf message with maxRecvPayloadLength parameter (value is specified in peer configuration). The number of returned enriched block headers is reduced as needed to stay below this limit, but not below 1. This is so that one header requested by gethdrsen message can be returned even if limit imposed by maxRecvPayloadLength parameter is exceeded. This limit is always honored if message is sent to announce new blocks (i.e. new blocks will not be announced with this message if the size of the message would exceed the limit).
Varies	enriched block headers	block_header_en[]	Enriched block headers (specified below)

Enriched block header is serialized in the format described below.

Field Size	Name	Data Type	Description
81+	block header fields (please see block header definition)	various	Same fields as in block header returned by headers message. See: https://wiki.bitcoinsv.io/index.php/Peer-To-Peer_Protocol#headers Note: Value of field txn_count (transaction count) in block header is typically set to 0 if header is not sent as part of block message (e.g. in headers message). Here the value of this field is set to actual transaction count if that inf...