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...

Bitcoin SV version 1.0.11 Release Notes

Overview

Version 1.0.11 release is a recommended upgrade from version 1.0.10. This new version introduces changes to fee configuration options and various bug fixes.

Changed option name -blockmintxfee to -minminingtxfee

Note that setting -minminingtxfee is a mandatory setting. The option -blockmintxfee has been removed. Setting it will emit a warning in the bitcoin logs. To repeat the default setting from the last release a miner needs to configure -minminingtxfee=0.00000500 (.i.e 500 Satoshis).

Removed options -dustrelayfee, -dustlimitfactor

These options have been removed. The dust threshold is now hard coded to one Satoshi per transaction output.

Note that blocks containing transactions with dust outputs (i.e. outputs with a zero Satoshi amount)  will still be accepted.

Attempting to set these options will have no effect other than a warning message in the bitcoin logs.

Removed option -minrelaytxfee

This option has been removed. The mempool will reject incoming low fee transactions based on its dynamic rejection fee as in the original implementation of bitcoin.

Attempting to set this option will have no effect other than a warning message in the bitcoin logs.

Bug fixes

1. Node stops responding to RPCs, including getminingcandidate

2. Dropped connections due to "Timeout downloading block"

3. Pruning target is now matched as closely as possible during initial block download

4. Disable a Bloom filtered connection by default

Bitcoin SV version 1.0.10 Release Notes

Bitcoin SV Node software – Upgrade to v1.0.10 Release

Overview

Version 1.0.10 release is a recommended upgrade from version 1.0.9; This new version brings a number of improvements to both functionality and performance.

Parallel Transaction Validation (PTV) Scheduler Improvements

Performance improvements have been made to the processing of long complex transaction graphs where transactions arrive out of order.

Modification to processing of user agent strings

Currently it is possible that a node may connect to BCH nodes (There is advice on how to avoid this on bitcoin-sv github). Connecting to a non-BSV node is not fatal to the operation of the node but leads to wasted bandwidth and unnecessary block processing. Invalid blocks generate error messages which pollute the log files and make it difficult to see what is going on. The following steps have been taken to make it more likely that a node only connects to other BSV nodes.

• banclientua - contains the list of banned user agent substrings (the node will ban any peer that returns one of these user agent strings).  The default list is set to: "abc", "cash", "bch"
• allowclientua - a newly introduced config option that contains a list of allowed user agent substrings that overrides banclientua.  The default list is empty.

Matching is case insensitive. Note that the default list is cleared if a single banclientua parameter is set in the bitcoin config file or command line.

Example config setting: 

banclientua=XYZ
banclientua=ABC
allowclientua=its-not-abc

This will allow/disallow the following user agent strings:

'ThisAbcClient'   # banned, matches ABC
'ThisBchClient'   # allowed because the default has been cleared, so connections to nodes that return "cash" or "bch" are allowed
'I-cant-believe-its-not-ABC'   # allowed, ABC matches but its-not-abc also matches and has precedence

Update default maxscriptsizepolicy, maxscriptnumlengthpolicy

The default values for maxscriptsizepolicy, maxscriptnumlengthpolicy config options have been updated.

• Default value for maxscriptsizepolicy = 500,000 (up from 10,000)
• Default value maxscriptnumlengthpolicy = 10,000 (down from 250000)

P2P Header Update

Every P2P message on the network has the same basic structure; a 24 byte header followed by some payload data. One of the fields within the header describes the length of that payload, and is currently encoded as a uint32_t. This therefore limits the maximum size of any message payload to 4GB. In order to support block sizes greater than 4GB, a change has been made to the P2P message structure to overcome this limitation.

Versioning

As of this release the P2P protocol version number has been bumped from 70015 to 70016. Doing this allows a node to know in advance whether a connected peer will understand the new extended message format and therefore avoid sending such messages to that peer. Conforming nodes must not send messages in the extended format to peers with a version number lower than 70016, or they will be banned.

Change Description

In summary, the changes to the P2P message involve the use of special values of fields within the existing P2P header as flags that can be recognised by a peer that supports such changes to indicate that this is a message with a large payload. These special values also allow a peer that doesn't understand them to reject such a message and fail cleanly if it were to come across one.

The existing P2P header contains a 12 byte message type field. We introduce a new message type in this field extmsg (short for extended message) that when seen will indicate to the receiver that following this message header are a series of new extended message header fields before the real payload begins.

The proposed full extended message format is shown below:

Field_Size	Name	Data_Type	Description
4	magic	uint32_t	Existing network magic value. Unchanged here.
12	command	char[12]	Existing network message type identifier (NULL terminated). For new extended messages this would take the value extmsg.
4	length	uint32_t	Existing payload length field. Currently limited to a maximum payload size of 4GB. For new extended messages this will be set to the value 0xFFFFFFFF. The real payload length will be read from the extended payload length field below.
4	checksum	uint32_t	Checksum over the payload. For extended format messages this will be set to 0x00000000 and not checked by receivers. This is due to the long time required to calculate and verify the checksum for very large data sets, and the limited utility of such a checksum.
12	ext_command	char[12]	The extended message type identifier (NULL terminated). The real contained message type, for example block for a > 4GB block, or could also conceivably be tx if we decide in future to support > 4GB transactions, or any other message type we need to be large.
8	ext_length	uint64_t	The extended payload length. The real length of the following message payload.
?	payload	uint8_t[]	The actual message payload.

sendrawtransactions - option to skip some policy checks

It is now possible to override policy checks per transaction or per whole batch (transaction specific overrides have precedence over batch specific overrides) when using sendrawtransactions RPC. 
These parameters do not override consensus rules. 

The following configuration parameters can be overridden: maxtxsizepolicy, datacarriersize, maxscriptsizepolicy, maxscriptnumlengthpolicy, maxstackmemoryusagepolicy, limitancestorcount, limitcpfpgroupmemberscount, acceptnonstdoutputs, datacarrier, dustrelayfee, maxstdtxvalidationduration, maxnonstdtxvalidationduration, minconsolidationfactor, maxconsolidationinputscriptsize, minconfconsolidationinput, acceptnonstdconsolidationinput, dustlimitfactor, skipscriptflags

Example1: Override policy for transactions individually
sendrawtransactions([{'hex': signed_tx, 'dontcheckfee': True, 'config': {"maxtxsizepolicy": 10000000, "minconfconsolidationinput": 200, "skipscriptflags": ["CLEANSTACK", "DERSIG"]}...])

Example2: Override policy for all transactions in the batch
sendrawtransactions([{'hex': signed_tx, 'dontcheckfee': True}, ...], {"maxtxsizepolicy": 10000000, "minconfconsolidationinput": 200, "skipscriptflags": ["CLEANSTACK", "DERSIG"]})

New ZMQ Topics

New ZMQ topics have been added to the node. The differences between original and new ZMQ topics are shown below.

Original rawtx, hashtx, rawblock, hashblock topics

tx notifications:

• publish transaction when it is accepted to mempool
• publish transaction when block containing it is connected
• publish transaction when block containing it is disconnected

block notifications:

• publish block when it's connected
• on reorg only publish the new tip

When a reorg happens, we get notified 3 times for the same transaction (from a disconnected block):

• on block disconnect
• when the transaction is accepted to mempool
• when the new block, the transaction is added to, is connected

New rawtx2, hashtx2, rawblock2, hashblock2 topics

tx notifications:

• publish transaction when it is first seen:
• accepted to mempool, or
• received in a block if we didn't have it in mempool yet
• when we mine (connect) a block, we publish transactions that weren't published before (usually only coinbase)
• when we receive a valid block, we publish all the transactions that weren't published before (the ones in block and not in our mempool)
• we don't publish the transaction when block containing it is disconnected

block notifications:

• we publish every connected block

When a reorg happens, we get notified once for each transaction and connected block:

• when transaction from a disconnected block is accepted to mempool, or
• when the new block from the longer chain that contains the transaction is connected
• we publish each connected block from the new, longer chain, not only the tip
• ! coinbases from the disconnected blocks are also not published !

Configurable Timeouts

New configuration options are available to address potential issues with download timeouts.

• blockdownloadtimeoutbasepercent (default=100% = 10 minutes)
• blockdownloadtimeoutbaseibdpercent (default=600% = 60 minutes)
• blockdownloadtimeoutbaseperpeerpercent (default=50% = 5 minutes)

Block Download Timeout Calculation

If the block is being downloaded as part of an initial block download (IBD), then the

base-timeout = blockdownloadtimeoutbaseibdpercent,

otherwise

base-timeout = lockdownloadtimeoutbasepercent.

The timeout is calculated as follows

Max. download timeout = 10 minutes x (base-timeout + no-of-peers x blockdownloadtimeoutbaseperpeerpercent)

For example, if there are a 3 connected peers, the default IBD timeout will be 10 minutes x (600 + 3 x 50)% = 10 minutes x (750%) = 75 minutes.

Bitcoin SV version 1.0.9 Release Notes

Public

Bitcoin SV Node software – Upgrade to v1.0.9 Release

Version 1.0.9 release is a recommended upgrade from version 1.0.8; This new version brings improved safe mode processing, webhook notifications, block double spend P2P notification messages and the possibility to freeze transaction outputs that are the target of double spends.

Content details listed below:

1. New block double spend P2P notification message.
2. Improved safe mode processing including new RPCs to manually control safe mode.
3. Webhook notification of competing chains and double spends.
4. Possibility to freeze transaction outputs.
5. Performance improvements to transaction chain processing.
6. STN Reset

Response to Block Withholding Attacks

Background

In the past few months, there have been several attempted attacks on the BSV network. The attacks involve mining a hidden alternate chain (in at least one case > 80 blocks in length) and then posting it to the blockchain at once so it became the new main chain. The new chain replaces some of the transactions in the original chain with double spends. Exchanges typically require a certain number of block confirmations (say 50 blocks have been built on the attempted transactions) before coin deposits or withdrawals into their exchange are valid, for example, to prevent an attacker from depositing double-spent BSV coins and immediately trade or cash out his position in the hidden chain after previously doing the same thing on the main chain.

The BSV blockchain and other PoW blockchains are vulnerable to these types of attacks because of the large amounts of roaming hash-power available that can be used on competing networks.

Our response to these attacks has included steps to:

1. Put global 24 hour/7 day a week monitoring in position and:
   • notify miners of long, competing chains when they appear.
   • notify exchanges and application providers of double spends in the new chain.
2. Enable honest miners to invalidate the block at the base of the hidden chain using invalidateblock, and then mine on the original honest chain until it is restored as the main chain.

Notification of change of safe mode (competing chains)

Exchanges and miners will be notified if a suspicious event (most likely an attack) occurs. The trigger is the existence of recent, long, competing chains.

Notification about a block reorganisation is part of the safe mode notification.

The Bitcoin SV Node software currently contains “safe-mode” logic to detect competing chains and de-activate wallet RPC calls (put into safe-mode). The safe-mode logic has been updated so that chain detection is configurable (allowing for users to customise their sensitivity to suspicious events) and triggers notifications via webhooks to exchanges/miners/application providers.

Notification of double spends

Exchanges and miners will be notified of recent double spends in competing chains of the BSV network.

Blockchain monitoring applications may send a DSD P2P notifications message to a BSV node (meaning a mining node), which will then relay the message to other nodes. The message contains a double spend proof (Merkle proof of the inclusion of transactions in a block). Notifications are via webhooks.

Freezing of double spends.
A BSV node (meaning a mining node) can now "freeze" specific TXOs (e.g. used by double spends).

If a policy freeze is applied to the TXO, the node will not accept transactions into their block templates that spend the TXO, but it will accept external blocks containing transactions that spend the TXO.

Specific Changes

Interface with DS Detector

The node will receive DSD P2P notification message that a double spend has been detected. On receipt of a DSD message, (a) the DSD message is verified/validated (to ensure that is not a malicious fake), (b) the DSD message is relayed to other nodes, and (c) webhooks are used to notify users.

Note that there is no need to inform peers about every double-spend contained in every block, it is sufficient for a notification to just contain the details of a single transaction from each block containing a conflict.

DSD P2P message

The format of the new DSD P2P message is

Field size	Description	Data Type	Comments
2	version	uint16_t	Versioning information for this message. Currently can only contain the value 0x0001.
1+	block count	varint	The number of blocks containing a double spend transaction this message is reporting. Must be >= 2.
variable	block list	block_details[]	An array of details for blocks containing double spend transactions

block_details:

Field size	Description	Data Type	Comments
1+	header count	varint	The number of following block headers (may not be 0).
variable	header list	block_header[]	An array of unique block headers containing details for all the blocks from the one containing the conflicting transaction back to the last common ancestor of all blocks reported in this message. Note that we don't actually need the last common ancestor in this list, it is sufficient for the last header in this list to be for the block where this fork begins, i.e.; the hashPrevBlock field from the last block header will be the same for all the blocks reported in this message.
variable	merkle proof	merkle_proof	The transaction contents and a proof that the transaction exists in this block. Follows TSC standard.

block_header:

Field size	Description	Data Type	Comments
4	version	int32_t	Block version information.
32	hash previous block	char[32]	Hash of the previous block in the fork.
32	hash merkle root	char[32]	The merkle root for this block.
4	time	uint32_t	Timestamp for when this block was created.
4	bits	uint32_t	Difficulty target for this block.
4	nonce	uint32_t	Nonce used when hashing this block.

The DSD P2P message specification can be found at https://github.com/bitcoin-sv-specs/protocol/blob/master/p2p/DSD_P2P.md

Webhook DSD notification message.

The node will use webhooks to notify listeners that new double spends has been detected on alternate chains on the blockchain. The recipient of the webhook message can be configured using the new command line parameter, *dsdetectedwebhookurl*.

The DSD notification message template is shown below

{
    "version": number,
    "blocks : [
        {
            "divergentBlockHash" : string,
            "headers" : [
                {
                    "version" : number,
                    "hashPrevBlock" : string,
                    "hashMerkleRoot" : string,
                    "time" : number,
                    "bits" : number,
                    "nonce" : number
                }
            ],
            "merkleProof" : {
                "index" : number,
                "txOrId" : string,   // Full transaction, serialised, hex-encoded
                "targetType": "merkleRoot",
                "target" : string,   // Merkle-root
                "nodes" : [ "hash", ... ]
            }
        },
        ...
    ]
}

This notification message is documented in docs/web_hooks.md in the distribution.

The getblockheader RPC has been updated to report on the valid/invalidated status of the block.

Update of Safe-Mode Trigger Methodology

Safe-mode disables node wallet functionality so that users cannot spend coins. Safe-mode is triggered when a long competing (parallel) block chain is detected. i.e. an attack chain is found. Webhooks are used to notify users when safe-mode status has been changed.
This update also modifies the logic that triggers safe-mode.

This release introduces 3 new command line parameters

1. safemodemaxforkdistance, Default = 1000 (7 days of mining)
2. safemodeminforklength, Default = 3
3. safemodeminblockdifference, Default = -72 (12 hours of mining below current tip)

Safe mode is automatically triggered if all of these criteria are satisfied:

• The distance between the current tip and the last common block header of the fork is smaller than the safemodemaxforkdistance.
• The length of the fork is greater than safemodeminforklength.
• The total proof of work of the fork tip is greater than the minimum fork proof of work (POW). The minimum fork POW is calculated relative to the active chain tip using this formula: + safemodeminblockdifference * . Safe mode is activated if the fork height is bigger than + safemodeminblockdifference. Note that the negative value of safemodeminblockdifference means that it will activate the safe mode for forks with tips below active chain tip.
  The first condition from the current implementation is retained, but triggering occurs before the competing fork surpasses the active chain. Safe mode is activated whenev...

Bitcoin SV version 1.0.8 Release Notes

Headline changes since 1.0.7

• Support for creating double-spend enabled transactions; if a double-spend of an input is seen, a HTTP notification will be sent to a specified endpoint. (Please refer to here for further details)
• New getorphaninfo RPC.
• New verifyScript RPC.
• New getmerkleproof2 RPC consistent with latest TSC.
• maxstackmemoryusageconsensus parameter added to output of getsettings RPC.
• sendrawtransaction and sendrawtransactions RPC can be used with dontCheckFees even when a transaction is already known.
• sendrawtransaction and sendrawtransactions RPC modified to optionally return list of unconfirmed parents.
• New configuration parameter -dustlimitfactor available to define dust.
• Free consolidation transaction can be used to avoid dusting attack.
• Adjusted default maximum validation duration for async tasks to better handle chains and long graphs.
• Change algorithm for using ancestor height rather than ancestor count.
• Improve release rate from Oprhan pool.
• Better performance as a result of improvements to cs_main processing.
• Improved validation of chains.
• Transactions will not be accepted if the result is an in-mempool ancestor chain of height 10,000 or more. Previously this figure was 1000 transactions.
• The default value for the maxorphantxsize configuration parameter has been changed to 1GB
• The maxcollectedoutpoints configuration parameter is no longer used and has been removed.
• The STN is being reset.

Changes since 1.0.8.beta

• Fixed the dust return script condition in IsDustReturnScript. The previous version incorrectly contained an OP_4.
• Fixed a bug that caused double spend notifications to be skipped for previously detected but unreported double-spends.
• Fixed an issue that could cause mempool and journal inconsistencies during a reorg.

Other technical changes

• Remove all support for Tor.
• Configure docker images so that core dump is preserved.
• Include header files in CMAKE build.
• Make CBlockIndex thread safe to remove cs_main dependency.
• Encapsulate mapBlockIndex and remove cs_main dependency.
• Create leaky bucket for tracking peer suspension score.
• Remove non-ctor init function in networkprocessing.
• Soft block orphaning support (not used).
• Refactor NET logging category.
• Move lNodesAnnouncingHeaderAndIDs into BlockDownloadTracker.
• Replace rand with the facilities in .
• Allow parallel downloads of the same block from several peers.
• Error message can be of 'txid' instead of 'hash' at the beginning for incorrect txid value while executing getmerkleproof RPC as like verifymerkleproof RPC.
• GlobalConfig class is not thread safe.
• dev branch clang warning -Wdefaulted-function-deleted.
• Initialize class members where clang requires.
• Fix: P2P Messages In Multiple TCP Segments.
• Improve detection of longer chains.
• Improved orphan transaction processing.
• Reduce Logging Cost.
• Fix runtime errors in unit test (Windows os).
• Global thread-local interferes with address sanitizer.
• Remove libatomic dependency.
• Undefined behaviour sanitiser reporting vector out of bounds access in CBlockFileInfoStore::FlushBlockFile.
• Fix: St16invalid_argument displays many times on startup.
• Falsely logged error opening rev.dat in logs.
• Fix: coredump at shutdown within logging.
• Fix: failure in CTxMemPool::GetMemPoolChildrenNL.
• Fix: a possible false negative result during querying the PTV processing queue.
• Remove maxcollectedoutpoints configuration parameter.
• Improved stability when accepting transactions during the reorg.

Functional tests

• Fix: import-rescan.py - possible race condition during tip update signaling.
• Fix: bsv-factorMaxSendQueueBytes functional test fails on Windows.
• Remove test/test_bitcoin_fuzzy.cpp.
• Fix: failing functional test bsv-getdata.py.
• Add a new FT to test long chains of CPFP txs.
• Fix: bsv-magicbytes.py functional test failed.
• Fix: internittent failure in bsv-block-propagation-priority.py.
• Fix: Random failures of bsv_pbv_firstvalidactive.py functional test.
• Fix: Failing util tests on Windows.
• Fix for issue detected by bsv-dsreport.py and bsv-ds-bad-callback-service.py on Windows.
• Wait_for_getdata method is misused in functional tests.

Security

• Remove warnings from source code.
• Update out-of-date dependencies with known security issues.
• Lock consistency violations in WPUSMutex.
• CReeRate calculation of CPFP groups allows invalid amounts.
• Incorect usage of cs_main.

Scaling Test Network (STN) Reset

The Scaling Test Network has been reset at block height 5. This block has hash
00000000e9222ebe623bf53f6ec774619703c113242327bdc24ac830787873d6.

Additional notes

New command line option -dustlimitfactor available to define dust.

Until now, the minimum ratio between a transaction output amount and its corresponding fee is 3/1.
If this condition was not met, the transaction was considered “dust” and was rejected during validation.

This factor can now be configured via the new “-dustlimitfactor” option in percent, which still defaults
to 300% but can be set to any value between 300% and 0%.

If the -dustlimitfactor is set to zero, then no transaction output is regarded as dust.

The formula for calculating the dust threshold is as follows (integer arithmetic):

s = serialized size of transaction output
d = dustlimitfactor, percent value between 300 and 0, default: 300
r = dustrelayfee, default: default-minrelaytxfee, 250 as of v1.0.8
m = 148, minimum bytes of spendable input

d * (r * (s + m)/1000)) / 100

Note that the division by 100 as the dustlimitfactor specifies a percentage value.

A transaction exactly at the threshold passes. If one output is below the threshold, the transaction is rejected.

Example: For a typical transaction with an output of 34 bytes in size, the formula yields a threshold of 135 Satoshis.

s = 34
d = 300
r = 250
m = 148

Threshold = (300 * (250 * (34 + 148)/1000)) / 100 = 135

Note the same formula would give a threshold of 136.5 Satoshis if floating point arithmetic is used.

A typical transaction output, with the default parameter settings in 1.0.8, needs to be worth 135
Satoshis not to be considered dust. Note that due to rounding, the calculated dust threshold for the
example transaction becomes 0 if the dustlimitfactor and the dustrelayfee are very low.

Free consolidation transaction can be used to avoid dusting attack.

Transaction validation has now been relaxed to allow a new kind of transaction, the dust return transaction.
This new transaction type allows donating dust to miners via fees as a new way to counter wallet dusting attacks.
This is more economical for the network because it allows clearing the wallets and UTXO databases from otherwise
practically unspendable outputs, whilst completely removing the incentive to conduct dust attacks at all.

A transaction is considered a dust return transaction if the following conditions are met:

• The transaction has a single output of zero value (zero amount).

• The scriptPubKey is as follows:

    OP_FALSE OP_RETURN OP_PUSHDATA ‘dust’.
  

All inputs must be standard inputs or the following node configuration parameter must be set:

-acceptnonstdconsolidationinput=1

The node must also be configured to accept non standard transactions. I.e. following configuration option must be set:

-acceptnonstdtx=1

Note that dust return transactions share two configuration parameters with consolidation transactions:

• -acceptnonstdconsolidationinput (default: 0)
• -minconsolidationfactor (default: 20. Setting consolidation factor to 0 disables consolidation transactions and dust return transactions as well)