You can view markdown formatted release notes <a href="https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.0.15.1" target="_blank" rel="noopener nofollow">here</a>.



<h2 class="wp-block-heading" id="h-overview">Overview</h2>



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



<ul>
<li>Features in 1.0.15.1
<ul>
<li>Refactor to remove possible exploit in p2p layer.</li>



<li>Ecosystem improvement proposal.</li>
</ul>
</li>



<li>Other items:
<ul>
<li>Additional functional tests.</li>
</ul>
</li>



<li>New or modified configuration options
<ul>
<li>None</li>
</ul>
</li>
</ul>



<h2 class="wp-block-heading">Headline Items in 1.0.15.1</h2>



<ol>
<li>Memory usage optimisations.</li>



<li>Build updates:</li>
</ol>



a. C++ v20. b. Ubuntu 20.04 LTS. c. CentOS 9.



<ol start="3">

<li>STN Network reset.</li>

</ol>



<h2 class="wp-block-heading">Detailed features of 1.0.15.1</h2>



<h3 class="wp-block-heading">Memory Usage Optimisations</h3>



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



<h3 class="wp-block-heading">Build Updates</h3>



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:



<h4 class="wp-block-heading">Pre-built binaries</h4>



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



<ul>
<li>Ubuntu 20.04 LTS (or later).</li>



<li>Debian 11 bullseye (or later).</li>



<li>Centos 9 (or later).</li>
</ul>



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.



<h4 class="wp-block-heading">Building from source</h4>



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 <a href="https://github.com/bitcoin-sv/bitcoin-sv/blob/master/doc/build-unix.md" target="_blank" rel="noopener nofollow">doc/build-unix.md</a> for a detailed description on how to build from source, or alternatively see the provided docker images <a href="https://hub.docker.com/r/bitcoinsv/bitcoin-sv-src/" target="_blank" rel="noopener nofollow">here</a> of suitable build environments already setup (scripts to generate the docker images can be found <a href="https://github.com/bitcoin-sv/docker-sv-src" target="_blank" rel="noopener nofollow">here</a>).



<h3 class="wp-block-heading">Other items:</h3>



<ul>
<li>The Scaling Test Network (STN) has been reset at block height eight. This block has hash 0000000074230d332b2ed9d87af3ad817b6f2616c154372311c9b2e4f386c24c.</li>
</ul>



<h3 class="wp-block-heading">Other new or modified configuration options</h3>



<ul>
<li>-maxconnections has been removed.</li>



<li>-maxoutboundconnections has been added (default=8)</li>
</ul>



Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/" target="_blank" rel="noopener nofollow">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport" target="_blank" rel="noopener nofollow">https://t.me/bitcoinsvsupport</a>

Bitcoin SV Node software – Upgrade to v1.0.15.1 Release Notes

You can view markdown formatted release notes <a href="https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.0.14" target="_blank" rel="noopener nofollow">here</a>.



<h2 class="wp-block-heading" id="h-overview">Overview</h2>



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



<h2 class="wp-block-heading" id="h-headline-item-in-1-0-14">Headline Item in 1.0.14</h2>



<ol>
<li>Node Freezing issue resolution (increased responsiveness)</li>
</ol>



<h2 class="wp-block-heading" id="h-detailed-features-of-1-0-14">Detailed features of 1.0.14</h2>



<ul>
<li>Parallel transaction validation (PTV) during block validation.</li>
</ul>



Other items:



<ul>
<li>Fixes to unit / functional tests.</li>



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



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



<li>The log message if the node runs out of disk space has been extended to give more information.</li>



<li>Some build warnings and failures on newer platforms and compilers have been fixed.</li>



<li>Bump OpenSSL version used by the Gitian build to 1.1.1t.</li>



<li>Make the maximum number of P2P addnode peers configurable.</li>



<li>Optimise locking code related to rollingMinimumFeeRate.</li>
</ul>



Community contribution submitted to Github:



<ul>
<li>RPC REST requests to fetch a binary block now have basic HTTP range header request support. For example; Range: bytes=1024-2048</li>



<li>Log message clarification around free RAM</li>
</ul>



<h2 class="wp-block-heading" id="h-ptv-during-block-validation">PTV during block validation</h2>



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:



<ul>
<li>-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.</li>



<li>-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.</li>
</ul>



<h2 class="wp-block-heading" id="h-other-new-or-modified-configuration-options">Other new or modified configuration options</h2>



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



<ul>
<li>-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.</li>



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



<li>-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.</li>
</ul>



Binaries&nbsp;and source code can be downloaded here:



URL:&nbsp;<a href="https://download.bitcoinsv.io/bitcoinsv/" target="_blank" rel="noopener nofollow">&gt;https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via&nbsp;<a href="mailto:support@bitcoinsv.io" target="_blank" rel="noopener">support@bitcoinsv.io</a>&nbsp;or via telegram at&nbsp;<a href="https://t.me/bitcoinsvsupport" target="_blank" rel="noopener nofollow">https://t.me/bitcoinsvsupport</a>.

Bitcoin SV Node software – Upgrade to v1.0.14 Release Notes

Bitcoin SV Node software – Upgrade to v1.0.13 Release

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.



Content details listed below:&nbsp;&nbsp;



<ul><li>Changed Option Name -blockmintxfee</li><li>Bloom Filters Disabled by Default</li><li>Removed options<ul><li>–dustrelayfee</li></ul><ul><li>-dustlimitfactor</li></ul><ul><li>-minrelaytxfee</li></ul></li></ul>



<h2 class="wp-block-heading">Changed option name -blockmintxfee to -minminingtxfee</h2>



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 &#8211;minminingtxfee=0.00000500&nbsp;(i.e. 500 Satoshis).



<h2 class="wp-block-heading">Bloom Filters Disabled by Default</h2>



Support for filtering transactions based on bloom filters on the P2P interface has been disabled by default. This technique is inconsistent with scalability and should not be used.



To re-enable the feature set the option -peerbloomfilters.



<h2 class="wp-block-heading">Removed options -dustrelayfee, -dustlimitfactor</h2>



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.



<h2 class="wp-block-heading">Removed option -minrelaytxfee</h2>



This option has been removed.&nbsp;The mempool will reject incoming low fee transactions based on its dynamic rejection fee algorithm.



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



Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

Bitcoin SV Node software – Upgrade to  v1.0.11 Release

The Bitcoin SV team are releasing 2 upgrades simultaneously.



These are:



<ol type="1"><li>Bitcoin SV Node software – Upgrade to v1.0.10 Release</li><li>mAPI v1.4.0 Release</li></ol>



<h1 class="wp-block-heading">Bitcoin SV Node software – Upgrade to v1.0.10 Release</h1>



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.



<h3 class="wp-block-heading">Content details listed below:&nbsp;&nbsp;</h3>



<ul><li>Parallel Transaction Validation (PTV) scheduler improvements</li><li>Modification to processing of User Agent strings</li><li>Update default maxscriptsizepolicy, maxscriptnumlengthpolicy</li><li>P2P Header Update<ul><li>Versioning</li><li>&nbsp;Change Description</li></ul></li><li>sendrawtransactions – option to skip some policy checks</li><li>New ZMQ Topics<ul><li>Original rawtx, hashtx, rawblock, hashblock topicstx notifications:</li><li>New rawtx2, hashtx2, rawblock2, hashblock2 topicstx notifications:</li></ul></li><li>Configurable Timeouts</li></ul>



<h3 class="wp-block-heading">Parallel Transaction Validation (PTV) scheduler improvements</h3>



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



<h3 class="wp-block-heading">Modification to processing of User Agent strings</h3>



Currently it is possible that a node may connect to BCH nodes (There is advice on how to avoid this on <a href="https://github.com/bitcoin-sv/bitcoin-sv">bitcoin-sv github</a>). This does not cause any major issues but leads to wasted bandwidth and processing of invalid blocks. Invalid blocks generate error messages which pollute 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.



<ul><li>banclientua&nbsp;– contains the list of banned User Agent substrings (the node will ban any peer that returns one of these User Agent strings).&nbsp; The default list is set to: “abc”, “cash”, “bch”</li><li>allowclientua&nbsp;– a newly introduced config option that contains a list of allowed User Agent substrings that overrides&nbsp;banclientua.&nbsp; The default list is empty.</li></ul>



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



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



This will allow/disallow the following User Agent strings:



‘ThisAbcClient’ &nbsp; # banned, matches&nbsp;ABC ‘ThisBchClient’ &nbsp; # allowed because the default has been cleared, so connections to node that return “cash” or “bch” nodes ‘I-cant-believe-its-not-ABC’ &nbsp; # allowed,&nbsp;ABC&nbsp;matches but&nbsp;its-not-abc&nbsp;also matches and has precedence



<h3 class="wp-block-heading">Update default maxscriptsizepolicy, maxscriptnumlengthpolicy</h3>



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



<ul><li>Default value for&nbsp;maxscriptsizepolicy&nbsp;= 500,000 (up from 10,000)</li><li>Default value&nbsp;maxscriptnumlengthpolicy&nbsp;= 10,000 (down from 250000)</li></ul>



<h3 class="wp-block-heading">P2P Header Update</h3>



Every P2P message on the network has the same basic structure; a 24 byte&nbsp;header followed by some payload data. &nbsp;One of the fields within the header describes the length of that payload, and is currently encoded as a&nbsp;uint32_t. &nbsp;This therefore limits the maximum size of any message payload&nbsp;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.



<h4 class="wp-block-heading">Versioning</h4>



As of this release the P2P protocol version number has been bumped from&nbsp;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.



<h4 class="wp-block-heading">Change Description</h4>



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:



<figure class="wp-block-table"><table><thead><tr><td>Field Size</td><td>Name</td><td>Data Type</td><td>Description</td></tr></thead><tbody><tr><td>4</td><td>magic</td><td>uint32_t</td><td>Existing network magic value. Unchanged here.</td></tr><tr><td>12</td><td>command</td><td>char[12]</td><td>Existing network message type identifier (NULL terminated). For new extended messages this would take the value&nbsp;extmsg.</td></tr><tr><td>4</td><td>length</td><td>uint32_t</td><td>Existing payload length field. Currently limited to a maximum payload size of 4GB. For new extended messages this will be set to the value&nbsp;0xFFFFFFFF. The real payload length will be read from the extended payload length field below.</td></tr><tr><td>4</td><td>checksum</td><td>uint32_t</td><td>Checksum over the payload. For extended format messages this will be set to&nbsp;0x00000000&nbsp;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.</td></tr><tr><td>12</td><td>ext_command</td><td>char[12]</td><td>The extended message type identifier (NULL terminated). The real contained message type, for example&nbsp;block&nbsp;for a &gt; 4GB block, or could also conceivably be&nbsp;tx&nbsp;if we decide in future to support &gt; 4GB transactions, or any other message type we need to be large.</td></tr><tr><td>8</td><td>ext_length</td><td>uint64_t</td><td>The extended payload length. The real length of the following message payload.</td></tr><tr><td>variable</td><td>payload</td><td>uint8_t[]</td><td>The actual message payload.</td></tr></tbody></table></figure>



<h3 class="wp-block-heading">sendrawtransactions – option to skip some policy checks</h3>



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&nbsp;sendrawtransactions&nbsp;RPC.&nbsp; These parameters do not override consensus rules.&nbsp;



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



Example1:&nbsp;Override policy for transactions individually sendrawtransactions([{‘hex’: signed_tx,&nbsp;‘dontcheckfee’: True,&nbsp;‘config’: {“maxtxsizepolicy”: 10000000,&nbsp;“minconfconsolidationinput”: 200,&nbsp;“skipscriptflags”: [“CLEANSTACK”,&nbsp;“DERSIG”]}…])



Example2:&nbsp;Override policy for all transactions in the batch sendrawtransactions([{‘hex’: signed_tx,&nbsp;‘dontcheckfee’: True}, …], {“maxtxsizepolicy”: 10000000,&nbsp;“minconfconsolidationinput”: 200,&nbsp;“skipscriptflags”: [“CLEANSTACK”,&nbsp;“DERSIG”]})



<h3 class="wp-block-heading">New ZMQ Topics</h3>



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



<h4 class="wp-block-heading">Original rawtx, hashtx, rawblock, hashblock topics <ins>tx notifications:</ins></h4>



<ul><li>publish transaction when it is accepted to mempool</li><li>publish transaction when block containing it is connected</li><li>publish transaction when block containing it is disconnected</li></ul>



<h4 class="wp-block-heading"><ins>block notifications:</ins></h4>



<ul><li>publish block when it’s connected</li><li>on reorg only publish the new tip</li></ul>



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



<ul><li>on block disconnect</li><li>when the transaction is accepted to mempool</li><li>when the new block, the transaction is added to, is connected</li></ul>



<h4 class="wp-block-heading">New rawtx2, hashtx2, rawblock2, hashblock2 topics <ins>tx notifications:</ins></h4>



<ul><li>publish transaction when it is first seen:</li><li>accepted to mempool, or</li><li>received in a block if we didn’t have it in mempool yet</li><li>when we mine (connect) a block, we publish transactions that weren’t published before (usually only coinbase)</li><li>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)</li><li>we don’t publish the transaction when block containing it is disconnected</li></ul>



<h4 class="wp-block-heading"><ins>block notifications:</ins></h4>



<ul><li>we publish every connected block</li></ul>



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



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



<h3 class="wp-block-heading">Configurable Timeouts</h3>



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



<ul><li>blockdownloadtimeoutbasepercent&nbsp;(default=100% = 10 minutes)</li><li>blockdownloadtimeoutbaseibdpercent&nbsp;(default=600% = 60 minutes)</li><li>blockdownloadtimeoutbaseperpeerpercent&nbsp;(default=50% = 5 minutes)</li></ul>



<h4 class="wp-block-heading">Block Download Timeout Calculation</h4>



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



base-timeout&nbsp;=&nbsp;blockdownloadtimeoutbaseibdpercent,



otherwise



base-timeout&nbsp;= lockdownloadtimeoutbasepercent.



The timeout is calculated as follows



Max. download timeout = 10 minutes x (base-timeout&nbsp;+ no-of-peers x&nbsp;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.



Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



<h1 class="wp-block-heading">mAPI software – Upgrade to v1.4.0 Release</h1>



Version 1.4.0 release is a recommended upgrade from version 1.3.0 release; With this release of mAPI we are introducing miner Policy Quotes. These enable the merchant to obtain information on miner policies, including the IP address needed to build a DSNT transaction output (see below), and the ability to skip some policy checks when transactions are submitted to node, such as:



“maxtxsizepolicy”: 999999,



“datacarriersize”: 100000,



“maxscriptsizepolicy”: 100000,



“maxscriptnumlengthpolicy”: 100000,



“maxstackmemoryusagepolicy”: 100000,



“limitancestorcount”: 100000,



“limitcpfpgroupmemberscount”: 10,



“acceptnonstdoutputs”: true,



“datacarrier”: true,



“dustrelayfee”: 150,



“maxstdtxvalidationduration”: 99,



“maxnonstdtxvalidationduration”: 100,



“dustlimitfactor”: 10,



“skipscriptflags”: [“CLEANSTACK”, “DERSIG”]



<h3 class="wp-block-heading">Content details listed below:&nbsp;&nbsp;</h3>



<ul><li>Supports policyQuote as well as feeQuote</li><li>Provides DSNT information for transaction builder</li><li>Administrator may configure accounts to specify Node&nbsp;options to skip some policy checks&nbsp;when transactions are submitted</li><li>Made ready for blocks greater than 4 GB</li><li>Performance Optimization</li></ul>



Specification:&nbsp;<a href="https://github.com/bitcoin-sv-specs/brfc-merchantapi">https://github.com/bitcoin-sv-specs/brfc-merchantapi</a>



<h3 class="wp-block-heading">Miner Policy Quotes</h3>



This release of mAPI specification introduces support for obtaining policy quotes from miners.



These are a superset of the mAPI v1.3.0 fee quotes, which are maintained for backward compatibility.



Policies are configured by the mAPI Administrator for each account and include Node&nbsp;options to skip some policy checks&nbsp;when transactions are submitted.



<h3 class="wp-block-heading">Double-spend Processing</h3>



In addition to mAPI using ZMQ subscriptions for local node double-spend detection, any remote node in the BSV network that detects a double spend of a transaction which contains a DSNT output (a double spend notification record), will notify the specified DSNT servers (such as mAPI) about the detected double spend through a HTTP callback and handshake.



Please refer to&nbsp;<a href="https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/double-spend-notifications.md">https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/double-spend-notifications.md</a>&nbsp;for further details.



Binaries and source code can be downloaded here:



URL:&nbsp; <a href="https://github.com/bitcoin-sv/merchantapi-reference">https://github.com/bitcoin-sv/merchantapi-reference</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

2 upgrades released simultaneously; BSV v1.0.10 & mAPI v1.4.0

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.



<h3 class="wp-block-heading">Content details listed below:&nbsp;</h3>



<ol type="1"><li>New block double spend P2P notification message. *</li><li>Improved safe mode processing including new RPCs to manually control safe mode. *</li><li>Webhook notification of competing chains and double spends.</li><li>Possibility to freeze transaction outputs. *</li><li>Performance improvements to transaction chain processing.</li></ol>



<h2 class="wp-block-heading">Response to Block Withholding Attacks</h2>



<h3 class="wp-block-heading">Background</h3>



In the past few months, there have been several attempted attacks on the BSV network. &nbsp;The attacks involve mining a hidden alternate chain (in at least one case &gt; 80 blocks in length) and then posting it to the blockchain at once so it became the new main chain. The new&nbsp;chain&nbsp;replaces some of the transactions in the original&nbsp;chain&nbsp;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,&nbsp;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:



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



<h3 class="wp-block-heading">Notification of change of safe mode (competing chains)</h3>



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.



<h3 class="wp-block-heading">Notification of double spends</h3>



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).&nbsp; Notifications are via webhooks.



<h3 class="wp-block-heading">Freezing of double spends</h3>



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.



<h2 class="wp-block-heading">Specific Changes</h2>



<h3 class="wp-block-heading">Interface with DS Detector</h3>



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.&nbsp;



<h4 class="wp-block-heading">DSD P2P message</h4>



The format of the new DSD P2P message is



<figure class="wp-block-table is-style-stripes ctable"><table><tbody><tr><td>Field size</td><td>Description </td><td>Data Type </td><td>Comments </td></tr><tr><td>2</td><td>version </td><td>uint16_t </td><td>Versioning information for this message. Currently can only contain the value 0x0001. </td></tr><tr><td>1+</td><td>block count </td><td>varint </td><td>The number of blocks containing a double spend transaction this message is reporting. Must be &gt;= 2. </td></tr><tr><td>variable</td><td>block list </td><td>block_details </td><td>An array of details for blocks containing double spend transactions.</td></tr></tbody></table></figure>



block_details:



<figure class="wp-block-table is-style-stripes ctable"><table><tbody><tr><td>Size</td><td>Description</td><td>Data Type</td><td>Comments</td></tr><tr><td>1+ </td><td>header count </td><td>varint </td><td>The number of following block headers (may not be 0).</td></tr><tr><td>variable</td><td>header list</td><td>block_header</td><td>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&nbsp;hashPrevBlock&nbsp;field from the last block header will be the same for all the blocks reported in this message.</td></tr><tr><td>variable</td><td>merkle proof</td><td>merkle_proof</td><td>The transaction contents and a proof that the transaction exists in this block. Follows TSC standard.</td></tr></tbody></table></figure>



block_header:



<figure class="wp-block-table is-style-stripes ctable"><table><thead><tr><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td>Field size </td><td>Description</td><td>Data Type</td><td>Comments</td></tr><tr><td>4</td><td>version</td><td>int32_t</td><td>Block version information.</td></tr><tr><td>32</td><td>hash previous block</td><td>char[32]</td><td>Hash of the previous block in the fork.</td></tr><tr><td>32</td><td>hash merkle root</td><td>char[32]</td><td>The merkle root for this block.</td></tr><tr><td> 4</td><td>time</td><td>uint32_t</td><td>Timestamp for when this block was created.</td></tr><tr><td> 4</td><td>bits</td><td>uint32_t</td><td>Difficulty target for this block.</td></tr><tr><td> 4</td><td>nonce</td><td>uint32_t</td><td>Nonce used when hashing this block.</td></tr></tbody></table></figure>



The DSD P2P message specification can be found at&nbsp;<a href="https://github.com/bitcoin-sv-specs/protocol/blob/master/p2p/DSD_P2P.md" target="_blank" rel="noreferrer noopener">https://github.com/bitcoin-sv-specs/protocol/blob/master/p2p/DSD_P2P.md</a>



<h2 class="wp-block-heading">Webhook DSD notification message</h2>



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



The DSD notification message template is shown below



<pre class="wp-block-code"><code>{
 “version” : number,
 “blocks : &#91;
 {
 
 “divergentBlockHash” : string,
 “headers” : &#91;
 {
 “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” : &#91; “hash”, … ]
 }
 },
 …
 ]
}</code></pre>



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



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



<h2 class="wp-block-heading">Update of Safe-Mode Trigger Methodology</h2>



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



<ol type="1"><li>safemodemaxforkdistance, Default =&nbsp;1000&nbsp;(7 days of mining)</li><li>safemodeminforklength, Default = 3</li><li>safemodeminblockdifference, Default = -72&nbsp;(12 hours of mining below current tip)</li></ol>



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



<ul><li>The distance between the current tip and the last common block header of the fork is smaller than the&nbsp;safemodemaxforkdistance.</li><li>The length of the fork is greater than&nbsp;safemodeminforklength.</li><li>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:&nbsp;&lt;total-proof-of-work-active-chain&gt; +&nbsp;safemodeminblockdifference&nbsp;* &lt;proof-of-work-of-the-active-tip&gt;.&nbsp;In reality, it boils down to: activate safe mode if the fork height is bigger than &lt;height-active-chain-tip&gt; +&nbsp;safemodeminblockdifference.&nbsp;Note that the negative value of&nbsp;safemodeminblockdifference&nbsp;means that it will activate the safe mode for forks with tips below active chain tip.</li></ul>



The first condition from the current implementation is retained, but triggering occurs before the competing fork surpasses the active chain. Safe mode is activated whenever the competing chain tip approaches the main chain tip closer than&nbsp;safemodeminforklength&nbsp;or it is ahead of the main chain tip.



<h3 class="wp-block-heading">Webhook DSD notification message</h3>



The node will use webhooks to notify listeners if the node enters or leaves safe-mode or one of the following events occur while in safe mode.



<ul><li>the non-main chain is extended</li><li>a block is fetched for the tip of non-main chain.</li><li>a change in the validity of a chain (e.g. triggered by calls to&nbsp;invalidateblock)</li><li>a blockchain reorganisation</li></ul>



Notifications will not occur during initial block download or reindex even if safe mode conditions exist.



A users who is only interested in the current safe mode state can check the&nbsp;safemodeenabled&nbsp;field in the notification message (see below).



The&nbsp;recipient&nbsp;of the webhook message can be configured using the new command line parameter&nbsp;safemodewebhookurl.



The safe mode notification message template is shown below.



<pre class="wp-block-code"><code>{
 “safemodeenabled”: boolean, // Is the node in the safe mode.
 “activetip”: { // Tip of the main chain.
 “hash”: string, // Block hash.
 “height”: number, // Block height.
 “blocktime”: string, // Human readable, UTC, block time.
 “firstseentime”: string, // Human readable, UTC, time when the node first received header.
 “status”: “active” // Status of the block. Possible values: active, invalid
 // headers-only, valid-fork, and valid-headers.
 },
 “timeutc”: string, // Human readable, UTC, time of creation of this message.
 “reorg”: { // Information about possible reorg.
 “happened”: bool, // Indicates if an reorg happened.
 “numberofdisconnectedblocks”: number, // Number of blocks disconnected in reorg.
 “oldtip”: { // Information about old active tip, “null” if an reorg did not happened.
 “hash”: string, 
 “height”: number,
 “blocktime”: string,
 “firstseentime”: string,
 “status”: string
 }
 },
 “forks”: &#91; // List of forks that are triggering the safe mode.
 {
 “forkfirstblock”: { // Root of the fork, this block’s parent is on the main chain.
 “hash”: string,
 “height”: number,
 “blocktime”: string,
 “firstseentime”: string,
 “status”: string
 },
 “tips”: &#91; // List of tips of this fork.
 {
 “hash”: string,
 “height”: number,
 “blocktime”: string,
 “firstseentime”: string,
 “status”: string
 },
 …
 ],
 “lastcommonblock”: { // Block on the main chain which is parent of the “forkfirstblock”
 “hash”: string,
 “height”: number,
 “blocktime”: string,
 “firstseentime”: string,
 “status”: string
 },
 “activechainfirstblock”: { // Block on the main chain which is child of the “lastcommonblock”
 “hash”: string,
 “height”: number,
 “blocktime”: string,
 “firstseentime”: string,
 “status”: string
 },
 },
 …
 ]
}</code></pre>



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



<h2 class="wp-block-heading">New RPC functions to enable/disable Safe-Mode</h2>



The RPC function allows a user to manually override safe-mode&nbsp;without restarting the node.&nbsp;



This release introduces 3 new RPCs.



<ol type="1"><li>ignoresafemodeforblock &lt;block_hash&gt;&nbsp;– The specified block and all its descendants will be ignored when calculating criteria for entering the safe mode.</li><li>reconsidersafemodeforblock &lt;block_hash&gt;&nbsp;– The specified block and all its descendants will be considered when calculating criteria for entering the safe mode.</li><li>getsafemodeinfo&nbsp;–&nbsp;Detailed information on the safe mode status.</li></ol>



The effect of the RPCs is not preserved across node restarts.



<h2 class="wp-block-heading">Support for Transaction Output Freezes</h2>



A node can now “freeze” specific transaction outputs (TXOs). A freeze can be applied to both spent and unspent TXOs, and can be used to ensure that a node does not process a known double spend.



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



This release introduces new RPCs.



<ol type="1"><li>addToPolicyBlacklist&nbsp;&lt;funds : object&gt;&nbsp;– add TXO to policy blacklist (i.e. do not accept transactions that accesses this TXO, blocks containing transaction may be accepted if not in the consensus blacklist)</li><li>removeFromPolicyBlacklist &lt;funds : object&gt;– remove TXO from policy blacklist</li><li>queryBlacklist&nbsp;– Returns all frozen TXOs from the DB.</li><li>clearBlacklists &lt;removeAllEntries : boolean, default=true&gt;&nbsp;– Removes entries from the blacklist.</li></ol>



<h2 class="wp-block-heading">Performance Improvements</h2>



The release contains optimisation to the processing of long, complex chains of transactions under extreme loads.



<h3 class="wp-block-heading">Binaries and source code can be downloaded here:</h3>



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/" target="_blank" rel="noreferrer noopener">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

Bitcoin SV Node software – Upgrade to v1.0.9 Release

The Bitcoin SV team are happy to announce the release of&nbsp;three exciting&nbsp;open-source&nbsp;projects&nbsp;as part of their&nbsp;LiteClient Toolbox&nbsp;programme.&nbsp;&nbsp;



<h1 class="wp-block-heading">BitcoinJ-SV – v1.0.1&nbsp;Release&nbsp;</h1>



BitcoinJ-SV is a highly optimised and lightweight version of the legacy&nbsp;BitcoinJ&nbsp;library&nbsp;that has been&nbsp;tuned for use on the massively scalable original Bitcoin&nbsp;(BSV)&nbsp;blockchain. This is a Community Edition (CE) release, with an Enterprise Edition&nbsp;being&nbsp;planned.&nbsp;



<h3 class="wp-block-heading">Main features&nbsp;</h3>



<ul><li>Domain, serialization, hashing,&nbsp;merkle&nbsp;proofs and cryptography classes&nbsp;</li><li>Storage functionality for headers/ transactions&nbsp;</li><li>An in-memory block store maintains&nbsp;a full block header history&nbsp;&nbsp;</li><li>Refactoring&nbsp;of some&nbsp;legacy&nbsp;BitcoinJ&nbsp;code&nbsp;</li></ul>



Source code can be downloaded here:



URL: <a href="https://github.com/bitcoin-sv/bitcoinj-sv" target="_blank" rel="noreferrer noopener">https://github.com/bitcoin-sv/bitcoinj-sv</a>



<h1 class="wp-block-heading">BSV&nbsp;Java&nbsp;Components Library&nbsp;(JCL)&nbsp;– v1.0.5&nbsp;Release&nbsp;</h1>



The BSV Components Library is a suite of Java libraries providing the services required by Java developers who wish to write Bitcoin-based applications.&nbsp;&nbsp;



Combining the various&nbsp;libraries&nbsp;components provides a&nbsp;high-speed&nbsp;toolkit for handling the large transaction volumes we&nbsp;witness&nbsp;on the original Bitcoin (BSV) network.&nbsp;



<h3 class="wp-block-heading">Main features&nbsp;</h3>



<ul><li>Base library&nbsp;</li><li>Provides representative base classes including Transactions and Blocks, and facilitates the management of their Serialization&nbsp;</li><li>Network library&nbsp;</li><li>Provides connection and streaming capabilities&nbsp;</li><li>Allows applications to connect to and ‘listen’ for incoming&nbsp;blockchain&nbsp;network messages&nbsp;&nbsp;</li><li>Supports commonly used “send/ broadcast” message operations.&nbsp;</li><li>Persistence library&nbsp;</li><li>Operations to save or retrieve&nbsp;blockchain&nbsp;information to and from a database/ repository&nbsp;</li><li>A&nbsp;LevelDB&nbsp;(Key/Value store) reference implementation&nbsp;</li></ul>



Source code can be downloaded here:



URL: <a href="https://github.com/bitcoin-sv/bsv-components-library" target="_blank" rel="noreferrer noopener">https://github.com/bitcoin-sv/bsv-components-library</a>



<h1 class="wp-block-heading">Block Headers Client – v1.0.2&nbsp;Release&nbsp;</h1>



The Block Headers Client provides a super-lightweight application that can be used to&nbsp;independently&nbsp;verify block hashes and on the original Bitcoin (BSV)&nbsp;Blockchain. The client can be deployed on the user’s premises via a convenient&nbsp;docker&nbsp;image or&nbsp;built from source.&nbsp;



<h3 class="wp-block-heading">Main features&nbsp;</h3>



<ul><li>Connects to the BSV network to synchronise block headers&nbsp;</li><li>Whitelists and blacklists internal management&nbsp;</li><li>Maintains a customisable minimum number of peer connections&nbsp;</li><li>A REST API is provided to enable rapid lookups of chain and network state, including:&nbsp;</li><li>Query Chain Tips&nbsp;</li><li>Prune Fork&nbsp;</li><li>Query Headers&nbsp;</li><li>Query Headers State&nbsp;</li><li>Query Network&nbsp;</li><li>Supports BSV&nbsp;Mainnet,&nbsp;Testnet,&nbsp;Regtest&nbsp;and&nbsp;STNnet.&nbsp;&nbsp;</li><li>Additional networks can be added with ease.&nbsp;</li></ul>



Binaries and Source code can be downloaded here:



URL: <a href="https://github.com/bitcoin-sv/block-headers-client" target="_blank" rel="noreferrer noopener">https://github.com/bitcoin-sv/block-headers-client</a>



URL: <a href="https://hub.docker.com/repository/docker/bitcoinsv/block-headers-client" target="_blank" rel="noreferrer noopener">https://hub.docker.com/repository/docker/bitcoinsv/block-headers-client</a>



<h3 class="wp-block-heading">Known issues&nbsp;</h3>



<ul><li>Occasionally a race condition&nbsp;can&nbsp;occur, causing a runtime exception&nbsp;since the Headers Client cannot access&nbsp;a level-db&nbsp;database file on&nbsp;the runtime&nbsp;filesystem.&nbsp;If this does occur,&nbsp;simply&nbsp;restarting the headers client resolves&nbsp;the&nbsp;issue.&nbsp;A more graceful preventative measure will be released in a&nbsp;patch-release&nbsp;soon.&nbsp;</li><li>There is a known issue where an unclean shutdown can cause the headers client to fail to read the level-db&nbsp;file store. To fix this issue, delete the level-db&nbsp;database folder, as&nbsp;displayed&nbsp;in the&nbsp;runtime filesystem&nbsp;path in the console log. Once done,&nbsp;restart&nbsp;the Headers Client. &nbsp;</li></ul>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

LiteClient Toolbox; Open-source project releases

Version 1.1.0&nbsp;release&nbsp;is a recommended&nbsp;upgrade from version 1.0.0&nbsp;release;&nbsp;With&nbsp;this release of SPV Channels we support push notifications to iOS and Android devices via mobile SDKs. This is facilitated by the Firebase Cloud messaging (FCM) service.



Updates to SPV Channels on the server side include FCM token persistence.



Mobile app developers can utilise the SDK specific to their preferred mobile operating system, be that iOS and/ or Android.



Content details listed below:



<ol type="1">
<li>Push notification from channels server</li>



<li>Firebase FCM token persistence on channels server</li>



<li>Android SDK Reference implementation</li>



<li>iOS SDK Reference implementation</li>



<li>Unsubscribe from mobile push notifications</li>



<li>Foreground notification handling</li>



<li>Generate and Revoke API access tokens</li>
</ol>



Binaries and source code can be downloaded here:&nbsp;



SPV Channels API Specification v1.1.0 – <a href="https://github.com/bitcoin-sv-specs/brfc-spvchannels" target="_blank" rel="noreferrer noopener nofollow">https://github.com/bitcoin-sv-specs/brfc-spvchannels</a>



SPV Channels CE version 1.1.0 – <a href="https://github.com/bitcoin-sv/spvchannels-reference" target="_blank" rel="noreferrer noopener nofollow">https://github.com/bitcoin-sv/spvchannels-reference</a>



SPV Channels CE Android SDK version 1.0.0 – <a href="https://github.com/bitcoin-sv/spvchannels-android-reference" target="_blank" rel="noreferrer noopener nofollow">https://github.com/bitcoin-sv/spvchannels-android-reference</a>



SPV Channels CE iOS SDK version 1.0.0 – <a href="https://github.com/bitcoin-sv/spvchannels-ios-reference" target="_blank" rel="noreferrer noopener nofollow">https://github.com/bitcoin-sv/spvchannels-ios-reference</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport" target="_blank" rel="noreferrer noopener nofollow">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

SPV Channels – Upgrade to v1.1.0 Release

The Bitcoin SV team are releasing 2 upgrades simultaneously.



These are:



<ol type="1"><li>Bitcoin SV Node software – Upgrade to v1.0.8 Release</li><li>mAPI v1.3.0 Release</li></ol>



Bitcoin SV Node software – Upgrade to v1.0.8 Release



Version 1.0.8 release is a recommended upgrade from version 1.0.8 (beta release); This new version brings support for reporting double spend attempts towards the remote endpoints such as mAPI or custom applications. It also contains performance improvements, most notably in relation to the processing of complex graphs of dependant transactions.



Content details listed below:&nbsp;&nbsp;



<ol type="1"><li>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 <a href="https://github.com/bitcoin-sv-specs/protocol">https://github.com/bitcoin-sv-specs/protocol</a> for further details)</li><li>New getorphaninfo RPC.</li><li>New verifyScript RPC.</li><li>New getmerkleproof2 RPC consistent with latest TSC.</li><li>maxstackmemoryusageconsensus parameter added to output of getsettings RPC.</li><li>sendrawtransaction and sendrawtransactions RPC can be used with dontCheckFees even when a transaction is already known.</li><li>sendrawtransaction and sendrawtransactions RPC modified to optionally return list of unconfirmed parents.</li><li>New configuration parameter dustlimitfactor available to define dust. *</li><li>Free consolidation transaction can be used to avoid dusting attack. *</li><li>Adjusted default maximum validation duration for async tasks to better handle chains and long graphs.</li><li>Change algorithm for using ancestor height rather than ancestor count.</li><li>Improve release rate from Orphan pool.</li><li>Better performance due to improvements in cs_main processing.</li><li>Improved validation of chains.</li><li>Transactions will not be accepted if the result is an in-mempool ancestor chain of height 10,000 or more. Previously this figure was 1,000 transactions.</li><li>The default value for the maxorphantxsize configuration parameter has been changed to 1GB</li><li>The maxcollectedoutpoints configuration parameter is no longer used and has been removed.</li><li>The STN is being reset.</li></ol>



*Additional Notes:



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



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



d = 300



s = 34



r = 250



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:



Consequently, with the default parameter settings in 1.0.8, a typical transaction output needs to be worth 135 Satoshis at least to be not 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.



9. 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&nbsp;return&nbsp;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&nbsp;return&nbsp;transaction if the following conditions are met:



<ul><li>The transaction has a single output of zero value (zero amount).</li><li>the scriptPubKey is as follows:</li></ul>



 OP_FALSE OP_RETURN n ‘dust’.



where n = length of the protocol ID, i.e. string size of ‘dust’.



<ul><li>either all inputs are standard or configuration following parameter is set: &nbsp;&nbsp;&nbsp; -acceptnonstdconsolidationinput=1 (default: 0)</li><li>non standard transactions must be allowed, i.e. following configuration must be set: &nbsp;&nbsp;&nbsp; -acceptnonstdtx=1 (default: 1)</li></ul>



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



<ul><li>-acceptnonstdconsolidationinput (default: false)</li><li>-minconsolidationfactor (default: not zero. Setting consolidation factor to 0 disables consolidation transactions and dust return transactions as well)</li></ul>



Example Dust Return Transaction:



{ &nbsp; ‘txid’: ‘7a234eaa8615858e7b59cc46820fb71940fa9b1fd2cbac6c4ca3efc33767c6dc’, &nbsp; ‘hash’: ‘7a234eaa8615858e7b59cc46820fb71940fa9b1fd2cbac6c4ca3efc33767c6dc’, &nbsp; ‘version’: 1, &nbsp; ‘size’: 226, &nbsp; ‘locktime’: 0, &nbsp; ‘vin’: [ &nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘txid’: ‘471e1070d48faf20b599b2291c5c7550f9152d6e3549987d85dae82f2e96e93f’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘vout’: 0, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘scriptSig’: { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘asm’: ‘61616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161c2’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘hex’: ‘4c9561616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161c2’ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘sequence’: 0 &nbsp;&nbsp;&nbsp; } &nbsp; ], &nbsp; ‘vout’: [ &nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘value’: Decimal(‘0.00’), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘n’: 0, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘scriptPubKey’: { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘asm’: ‘0 OP_RETURN 1953723748’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;‘hex’: ‘006a0464757374’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘type’: ‘nulldata’ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } &nbsp; ], &nbsp; ‘blockhash’: ‘380fe8631752b75ee3ce027bdf80e22f3445f4b620a9585b369fb9a0c3f2677e’, &nbsp; ‘confirmations’: 1, &nbsp; ‘time’: 1620224004, &nbsp; ‘blocktime’: 1620224004, &nbsp; ‘blockheight’: 208, } Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



mAPI software – Upgrade to v1.3.0 Release



Version 1.3.0 release is a recommended upgrade from version 1.3.0 beta release; With this release of mAPI we are introducing support for receiving double spend notifications from remote nodes.



In addition to local nodes, that are connected directly to mAPI through ZMQ subscription, any remote node in the BSV network that detects a double spend of a transaction, that contains a double spend notification address, can now notify mAPI about detected double spend through HTTP callback. Please refer to <a href="https://github.com/bitcoin-sv-specs/protocol">https://github.com/bitcoin-sv-specs/protocol</a> for further details.



Double spend notifications have also been improved with detection of double spends on unconfirmed parents. mAPI will notify merchants should it detect double spends, not only for their transaction, but also if the double spend is detected on one of its unconfirmed parents.



Merkle proof notifications can now use standard TSC format which returns hex encoded block header in callback notifications.



Additional improvements include, support for callback reason parameters in callback URLs, support for custom database server deployment and additional configuration options for better integration.



Content details listed below:&nbsp;&nbsp;



<ul><li>Double spend notification for unconfirmed parents.</li><li>Support for callback endpoint for double spend notifications from a remote node.</li><li>Add support for TSC merkle proof format.</li><li>Enable support for callback reason parameter in callback URL.</li><li>Support custom database server deployment.</li><li>Configuration option to disable fee check.</li><li>Option to supply ZMQ endpoint when registering node with mAPI.</li><li>Option to run mAPI over HTTP for development purposes.</li></ul>



Binaries and source code can be downloaded here:



URL:&nbsp;<a href="https://github.com/bitcoin-sv/merchantapi-reference">https://github.com/bitcoin-sv/merchantapi-reference</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

2 upgrades released simultaneously; BSV v1.0.8 & mAPI v1.3.0

The Bitcoin SV team are releasing 2 upgrades simultaneously.



These are:



<ol type="1">
<li>Bitcoin SV Node software – Upgrade to v1.0.8 Beta Release</li>



<li>mAPI v1.3.0 Beta Release</li>
</ol>



Bitcoin SV Node software – Upgrade to v1.0.8 (Beta Release)



Version 1.0.8 (beta release) is a recommended upgrade from version 1.0.7.1; This new version brings support for reporting double spend attempts towards the remote endpoints such as mAPI or custom applications. It also contains performance improvements, most notably in relation to the processing of complex graphs of dependant transactions.



Content details listed below:&nbsp;&nbsp;



<ol type="1">
<li>Support for double-spend-notify enabled transactions; if a double-spend of an input is seen, a HTTP notification will be sent to a specified endpoint. (Please refer to <a href="https://github.com/bitcoin-sv-specs/protocol">https://github.com/bitcoin-sv-specs/protocol</a> for further details)</li>



<li>New getorphaninfo RPC.</li>



<li>New verifyScript RPC.</li>



<li>New getmerkleproof2 RPC consistent with latest TSC.</li>



<li>maxstackmemoryusageconsensus parameter added to output of getsettings RPC.</li>



<li>sendrawtransaction and sendrawtransactions RPC can be used with dontCheckFees even when a transaction is already known.</li>



<li>sendrawtransaction and sendrawtransactions RPC modified to optionally return list of unconfirmed parents.</li>



<li>New configuration parameter dustlimitfactor available to define dust. *</li>



<li>Dust return transactions. *</li>



<li>Adjusted default maximum validation duration for async tasks to better handle chains and long graphs.</li>



<li>Change algorithm for using ancestor height rather than ancestor count.</li>



<li>Improve release rate from Orphan pool.</li>



<li>Better performance due to improvements in cs_main processing.</li>



<li>Improved validation of chains.</li>



<li>Transactions will not be accepted if the result is an in-mempool ancestor chain of height 10,000 or more. Previously this figure was 1,000 transactions.</li>



<li>The default value for the maxorphantxsize configuration parameter has been changed to 1GB</li>



<li>The maxcollectedoutpoints configuration parameter is no longer used and has been removed.</li>



<li>The STN is being reset.</li>
</ol>



*Additional Notes:



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



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



d = 300



s = 34



r = 250



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:



Consequently, with the default parameter settings in 1.0.8, a typical transaction output needs to be worth 135 Satoshis at least to be not 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.



9. Dust return transactions.



Transaction validation has now been relaxed to allow a new kind of transaction, the dust&nbsp;return&nbsp;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&nbsp;return&nbsp;transaction if the following conditions are met:



<ul>
<li>The transaction has a single output of zero value (zero amount).</li>



<li>the scriptPubKey is as follows:</li>
</ul>



 OP_FALSE OP_RETURN n ‘dust’.



where n = length of the protocol ID, i.e. string size of ‘dust’.



<ul>
<li>either all inputs are standard or configuration following parameter is set: &nbsp;&nbsp;&nbsp; -acceptnonstdconsolidationinput=1 (default: 0)</li>



<li>non standard transactions must be allowed, i.e. following configuration must be set: &nbsp;&nbsp;&nbsp; -acceptnonstdtx=1&nbsp; (default: 1)</li>
</ul>



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



<ul>
<li>-acceptnonstdconsolidationinput (default: false)</li>



<li>-minconsolidationfactor (default: not zero. Setting consolidation factor to 0 disables consolidation transactions and dust return transactions as well)</li>
</ul>



Example Dust Return Transaction:



{ &nbsp; ‘txid’: ‘7a234eaa8615858e7b59cc46820fb71940fa9b1fd2cbac6c4ca3efc33767c6dc’, &nbsp; ‘hash’: ‘7a234eaa8615858e7b59cc46820fb71940fa9b1fd2cbac6c4ca3efc33767c6dc’, &nbsp; ‘version’: 1, &nbsp; ‘size’: 226, &nbsp; ‘locktime’: 0, &nbsp; ‘vin’: [ &nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘txid’: ‘471e1070d48faf20b599b2291c5c7550f9152d6e3549987d85dae82f2e96e93f’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘vout’: 0, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘scriptSig’: { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘asm’: ‘61616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161c2’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘hex’: ‘4c9561616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161c2’ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘sequence’: 0 &nbsp;&nbsp;&nbsp; } &nbsp; ], &nbsp; ‘vout’: [ &nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘value’: Decimal(‘0.00’), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘n’: 0, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘scriptPubKey’: { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;‘asm’: ‘0 OP_RETURN 1953723748’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;‘hex’: ‘006a0464757374’, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ‘type’: ‘nulldata’ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } &nbsp; ], &nbsp; ‘blockhash’: ‘380fe8631752b75ee3ce027bdf80e22f3445f4b620a9585b369fb9a0c3f2677e’, &nbsp; ‘confirmations’: 1, &nbsp; ‘time’: 1620224004, &nbsp; ‘blocktime’: 1620224004, &nbsp; ‘blockheight’: 208, } Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



mAPI software – Upgrade to v1.3.0 (Beta Release)



Version 1.3.0 (Beta release) is a recommended upgrade from version 1.2.0; With this release of mAPI we are introducing support for receiving double spend notifications from remote nodes.



In addition to local nodes, that are connected directly to mAPI through ZMQ subscription, any remote node in the BSV network that detects a double spend of a transaction, that contains a double spend notification address, can now notify mAPI about detected double spend through HTTP callback. Please refer to <a href="https://github.com/bitcoin-sv-specs/protocol">https://github.com/bitcoin-sv-specs/protocol</a> for further details.



Double spend notifications have also been improved with detection of double spends on unconfirmed parents. mAPI will notify merchants should it detect double spends, not only for their transaction, but also if the double spend is detected on one of its unconfirmed parents.



Merkle proof notifications can now use standard TSC format which returns hex encoded block header in callback notifications.



Additional improvements include, support for callback reason parameters in callback URLs, support for custom database server deployment and additional configuration options for better integration.



Content details listed below:&nbsp;&nbsp;



<ul>
<li>Double spend notification for unconfirmed parents.</li>



<li>Support for callback endpoint for double spend notifications from a remote node.</li>



<li>Add support for TSC merkle proof format.</li>



<li>Enable support for callback reason parameter in callback URL.</li>



<li>Support custom database server deployment.</li>



<li>Configuration option to disable fee check.</li>



<li>Option to supply ZMQ endpoint when registering node with mAPI.</li>



<li>Option to run mAPI over HTTP for development purposes.</li>
</ul>



Binaries and source code can be downloaded here:



URL:&nbsp; <a href="https://github.com/bitcoin-sv-specs/brfc-merchantapi">https://github.com/bitcoin-sv-specs/brfc-merchantapi</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

2 upgrades released simultaneously; BSV v1.0.8 (Beta) & mAPI v1.3.0 (Beta)

Version 1.0.7.1 is a critical upgrade from version 1.0.7;&nbsp;This upgrade is recommended but not required for nodes running 1.0.6 or below.



Content details listed below:&nbsp;&nbsp;



<ul><li>Performance hardening changes to ensure performance remains stable under adverse network conditions.</li><li>Fix node crash under specific network conditions.</li></ul>



Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via email to <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a> &nbsp;or via telegram at <a href="https://t.me/bitcoinsvsupport">https://t.me/bitcoinsvsupport</a>



Thank you for your continued support of Bitcoin SV.

Bitcoin SV Node software – Critical Upgrade to v1.0.7.1 Release

Version 1.0.7 is the finalised release from version 1.0.7 (beta release). It brings increased performance and support for long chains of unconfirmed transactions, which enables new use cases, for applications that require high transaction throughput.



Content details listed below:&nbsp;&nbsp;



<ul><li>CPFP and ancestor limit extended from 25 to 1000 transactions.</li><li>Legacy block assembler removed; support for low priority /free transactions removed.</li><li>Refactoring of CCoinView</li><li>P2P improvements</li><li>Packaged Diagnostic Service – allows for remote gathering of diagnostic information from a node.</li><li>The default value for maxcoinsprovidercachesize = 1GB and must be at least 1MB.</li><li>The mempoolminfee (rolling fee) is prevented from becoming greater than blockminfee while there are secondary mempool transactions.</li></ul>



*Note: Should you have previously set, limitancestorcount in your configurations, make sure to increase this to a larger value (the new default value is 1000) or alternatively, remove it.



To learn more about CPFP/long chains, you might like to read the following blog post from Steve Shadders, Technical Director of the Bitcoin SV Infrastructure team:



Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a>



Thank you for your continued support of Bitcoin SV.

Bitcoin SV Node software – Upgrade to v1.0.7 Release

Version 1.0.7 upgrade is a beta release from version 1.0.6.&nbsp; It brings increased performance and support for long chains of unconfirmed transactions, which enables new use cases, for applications that require high transaction throughput.



Content details listed below:&nbsp;&nbsp;



<ul><li>CPFP and ancestor limit extended from 25 to 1000 transactions.</li><li>Legacy block assembler removed; support for low priority /free transactions removed.</li><li>Refactoring of CCoinView</li><li>P2P improvements</li></ul>



*Note: Should you have previously set, limitancestorcount in your configurations, make sure to increase this to a larger value (the new default value is 1000) or alternatively, remove it.



To learn more about CPFP/long chains, you might like to read the following blog post from Steve Shadders, Technical Director of the Bitcoin SV Infrastructure team:



Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a>



Thank you for your continued support of Bitcoin SV.

Bitcoin SV Node software – Upgrade to v1.0.7 (Beta Release)

The Bitcoin SV team are releasing 3 products simultaneously that, along with several other services, provide all the tools required to implement the client-side peer to peer and SPV workflows.&nbsp; These are:



<ol type="1"><li>Bitcoin SV Node software – Upgrade to v1.0.6 Release</li><li>mAPI v1.2.0 Release</li><li>SPV Channels CE v1.0.0 Release</li></ol>



This combination of products is designed to help finally realise the “peer to peer” part of Satoshi Nakamoto’s vision for Bitcoin and the network’s scaling.&nbsp;



To learn more about the practical impact of these 3 products, please read this blog post from Steve Shadders, Technical Director of the Bitcoin SV Infrastructure team: <a href="https://bitcoinsv.io/2020/09/30/realising-finally-satoshis-peer-to-peer-vision-for-bitcoin/">https://bitcoinsv.io/2020/09/30/realising-finally-satoshis-peer-to-peer-vision-for-bitcoin/</a>



<h1 class="wp-block-heading">Bitcoin SV Node software – Upgrade to v1.0.6 Release</h1>



Version 1.0.6 upgrade is the finalised release from version 1.0.6 (beta release), it is a demonstration of upcoming features made available for early testing.&nbsp; It primarily focusses on event notification capabilities, making the process of monitoring transaction confirmation progress more efficient and improving merchant assurance of transactions.



Content details listed below:&nbsp;&nbsp;



<ul><li>ZMQ topic zmqpubremovedfrommempool renamed to zmqpubdiscardedfrommempool</li><li>STN NOVEMBER2020 RESET</li><li>Fix: clearinvalidtransactions RPC returned the number of bytes freed as zero.</li><li>Fix: Node started even if initialisation error (invalidtxsink parameter was not set to ZMQ when zmqpubinvalidtx is defined)</li><li>Fix: Validation published transactions with rejection reason txn-already-in-mempool or txn-already-known.</li><li>ZMQ: Push information (blockhash) in which block transaction we collided with arrived.</li><li>Do not use deprecated boost bind features.</li><li>#include &lt;limits&gt; added to script_num.cpp to fix build issues with later compilers.</li><li>Remove logging from consensus.</li><li>isCorruptionPossible removed from invalid transaction notification.</li><li>ThreadSanitiser reports issues in thread safe queue tests.</li><li>ThreadSanitiser reported heap-use-after-free.</li><li>Fix: gettxouts parameters CLI type mismatch.</li><li>Fix: CheckTxInputExists should not be used.</li><li>Remove assert and fix shutdown after unsuccessful startup.</li><li>Unconditionally log P2P stall messages if denugp2pthreadstalls is specified.</li></ul>



Binaries and source code can be downloaded here:



URL: <a href="https://download.bitcoinsv.io/bitcoinsv/">https://download.bitcoinsv.io/bitcoinsv/</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a>



<h1 class="wp-block-heading">2. mAPI v1.2.0 Release</h1>



This release of mAPI (formerly called Merchant API) introduces a number of changes to further enhance miner services to network users. In particular, we confirm mAPI’s capabilities to improve SIT (Safe Instant Transactions) by identifying double spend scenarios and introducing callback notification features.



On transaction submission, the merchant or intermediary can optionally request merkle proofs to be delivered through a designated callback channel. mAPI 1.2.0 implements the first use case for the newly released CE (Community Edition) of SPV Channels, offering end-to-end encryption of messages to connected or partially connected clients.



In addition, the v1.2.0 upgrade includes improvements on administering node connections, fee quotes and quote authorisation through a revamped token issuer. The new feature of an API gateway, with REST Admin Interface, provides the additional usability, security and robustness required to administer a fully functional mAPI service.



Content details listed below:



<ul><li>Add new parameters on submit transaction for:</li><li>Notifications of double spends</li><li>Requesting merkle proof callback</li><li>Callback URL</li><li>Message encryption parameter</li><li>Application of SPV Channels for secure and reliable message exchange on callbacks</li><li>API gateway implementation for processing of submit transaction, query transaction status and fee quotes</li><li>API gateway REST Admin Interface</li><li>Revamped token issuer functionality</li><li>Revamped Create Fee Quote functionality</li><li>Revamped node connections configuration</li></ul>



To download mAPI version 1.2.0 <a href="https://github.com/bitcoin-sv-specs/brfc-merchantapi" target="_blank" rel="noreferrer noopener">click here</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a>



<h1 class="wp-block-heading">3. SPV Channels CE v1.0.0 Release</h1>



The SPV Channels specification defines lightweight HTTP APIs and describes appropriate client-side cryptography that together enable&nbsp;applications to asynchronously exchange messages confidentially, with mutual authentication and message integrity guarantees. SPV Channels are designed to enable parties to exchange messages even when no direct connection between them is available, such as when parties are behind NAT, or when one party is offline.



Channels are configured to receive messages. Individual channels have owners, and owners may configure channel read/write permissions for unauthenticated connections and distinct read/write permissions for those to whom they issue revocable API keys.



The security model is established by prescribing an application-level end-to-end encryption protocol, which protects transported messages.



SPV Channels CE is a self-hosted implementation of the service and client with the following features:



Content details listed below:&nbsp;&nbsp;



<ul><li>Channel APIs<ul><li>Create Channel</li><li>List Channels</li><li>Delete Channel</li><li>Get Channel Info</li><li>Get Token</li><li>Get Channel Tokens</li><li>Amend Channel</li><li>Generate Channel API Token</li><li>Revoke Channel API Token</li></ul></li><li>Message APIs<ul><li>Write message to channel</li><li>Get message in channel</li><li>Mark message as read or unread</li><li>Get all unread messages in channel</li><li>Delete message in channel</li></ul></li><li>Notifications<ul><li>Push notifications, alerting users of new message in channel</li></ul></li><li>Encryption<ul><li>End-to-end encryption libraries using libsodium</li></ul></li></ul>



To download SPV Channels CE version 1.0.0 <a href="https://github.com/bitcoin-sv-specs/brfc-spvchannels" target="_blank" rel="noreferrer noopener">click here</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a>



Thank you for your continued support of Bitcoin SV.

Bitcoin SV Infrastructure team provides release of 3 products to realise Satoshi’s peer to peer vision for Bitcoin

On September 30, the Bitcoin SV Infrastructure team are simultaneously releasing 3 beta products that, along with several other services, provide all the tools required to implement the client side peer to peer and Simplified Payment Verification (SPV) workflows.&nbsp; &nbsp;&nbsp;



These are:



<ol type="1"><li>Bitcoin SV Node software – upgrade to v1.0.6 (Beta Release)</li><li>mAPI v1.2.0 (Beta) Release</li><li>SPV Channels CE v1.0.0 (Beta) Release</li></ol>



This combination of products is designed to help finally realise the “peer to peer” part of Satoshi Nakamoto’s vision for Bitcoin and the network’s scaling.&nbsp;



To learn more about the practical impact of these 3 products, please read this blog post from Steve Shadders, Technical Director of the Bitcoin SV Infrastructure team:&nbsp; <a href="https://bitcoinsv.io/2020/09/30/realising-finally-satoshis-peer-to-peer-vision-for-bitcoin/" target="_blank" rel="noreferrer noopener">https://bitcoinsv.io/2020/09/30/realising-finally-satoshis-peer-to-peer-vision-for-bitcoin/</a>



1. Bitcoin SV Node software – Upgrade to v1.0.6 (Beta) Release



Version 1.0.6 is a beta release for an upgrade from version 1.0.5; it provides a demonstration of upcoming features made available now for early testing.&nbsp; It primarily focusses on event notification capabilities, making the process of monitoring transaction confirmation progress more efficient and improving merchant assurance of transactions.



Content details listed below:&nbsp;&nbsp;



<ul><li>New gettxouts RPC to retrieve UTXOs.</li><li>sendrawtransactions returns double spend transaction IDs.</li><li>Refactor code so HTTP client requests can be made from bitcoind.</li><li>New RPC to list ZMQ notifications and endpoints.</li><li>ZMQ notifications for transaction mempool removal.</li><li>Insecure function (sprintf) no longer used.</li><li>Make ZMQ interface thread safe.</li><li>getmerkleproof and verifymerkleproof RPC to provide/verify Merkle proofs for transaction inclusion in blocks.</li><li>Invalid transactions stored in repository.</li><li>Ensure the fallback path for packages (bitcoinsv.io) in the Gitian build contains all required packages.</li><li>Fix to Gitian build.</li><li>Fix: Accessing memory after std::move.</li></ul>



Binaries and source code can be downloaded here: URL: <a href="https://download.bitcoinsv.io/bitcoinsv/" target="_blank" rel="noreferrer noopener">https://download.bitcoinsv.io/bitcoinsv/</a>



<h2 class="wp-block-heading">2. mAPI v1.2.0 (Beta) Release</h2>



This release of mAPI (formerly called Merchant API) introduces a number of changes to further enhance miner services to network users. In particular, we confirm mAPI’s capabilities to improve SIT (Safe Instant Transactions) by identifying double spend scenarios and introducing callback notification features.



On transaction submission, the merchant or intermediary can optionally request merkle proofs to be delivered through a designated callback channel. mAPI 1.2.0 implements the first use case for the newly released CE (Community Edition) of SPV Channels, offering end-to-end encryption of messages to connected or partially connected clients.



In addition, the v1.2.0 upgrade includes improvements on administering fee quotes and quote authorisation through a revamped token issuer. The new feature of an API gateway, with Admin Interface, provides the additional usability, security and robustness required to administer a fully functional mAPI service.



Content details listed below:



<ul><li>Add new parameters on submit transaction for:</li><li>Notifications of double spends</li><li>Requesting merkle proof callback</li><li>Callback URL</li><li>Message encryption parameter</li><li>Application of SPV Channels for secure message exchange on callbacks</li><li>API gateway implementation for processing of submit transaction, query transaction status and fee quotes</li><li>API gateway Admin Interface</li><li>Revamped token issuer functionality</li><li>Revamped Create Fee Quote functionality</li></ul>



To download mAPI version 1.2.0 (Beta), <a href="https://github.com/bitcoin-sv-specs/brfc-merchantapi" target="_blank" rel="noreferrer noopener">click here</a>



<h2 class="wp-block-heading">3. SPV Channels CE v1.0.0 (Beta) Release</h2>



The SPV Channels specification defines lightweight HTTP APIs and describes appropriate client-side cryptography that together enable&nbsp;applications to asynchronously exchange messages confidentially, with mutual authentication and message integrity guarantees. SPV Channels are designed to enable parties to exchange messages even when no direct connection between them is available, such as when parties are behind NAT, or when one party is offline.



Channels are configured to receive messages. Individual channels have owners, and owners may configure channel read/write permissions for unauthenticated connections and distinct read/write permissions for those to whom they issue revocable API keys.



The security model is established by prescribing an application-level end-to-end encryption protocol, which protects transported messages.



SPV Channels CE is a self-hosted implementation of the service and client with the following features:



Content details listed below:&nbsp;&nbsp;



<ul><li>Channel APIs<ul><li>Create Channel</li><li>List Channels</li><li>Delete Channel</li><li>Get Channel Info</li><li>Get Token</li><li>Get Channel Tokens</li><li>Amend Channel</li><li>Generate Channel API Token</li><li>Revoke Channel API Token</li></ul></li><li>Message APIs<ul><li>Write message to channel</li><li>Get message in channel</li><li>Mark message as read or unread</li><li>Get all unread messages in channel</li><li>Delete message in channel</li></ul></li><li>Notifications<ul><li>Push notifications, alerting users of new message in channel</li></ul></li><li>Encryption<ul><li>End-to-end encryption libraries using libsodium</li></ul></li></ul>



To download SPV Channels CE version 1.0.0 (Beta) <a href="https://github.com/bitcoin-sv-specs/brfc-spvchannels" target="_blank" rel="noreferrer noopener">click here</a>



Should you have any support questions, please direct them via <a href="mailto:support@bitcoinsv.io" target="_blank" rel="noreferrer noopener">support@bitcoinsv.io</a>



Thank you for your continued support of Bitcoin SV.

Bitcoin SV Infrastructure team provides beta release of 3 products to realise Satoshi’s peer to peer vision for Bitcoin

Version 1.0.5 is an important upgrade from version 1.0.4; it contains performance hardening changes to improve stability under high network load conditions.



Here is a full list of v1.0.5 changes:



<ul><li>Journaling block assembler has been modified so that it now only includes a transaction if the supplied fees are greater than, or equal to minblocktxfee. It is also now the default.*</li><li>Free consolidation transactions.&nbsp;Multiple transactions can, under some circumstances, be consolidated into a single transaction at no cost, to minimise&nbsp;the size of the UTXO set. &nbsp;Free consolidation transactions cannot be used with CPFP.</li><li>sendrawtransaction – The node now supports the submission of multiple transactions in a single RPC call. I.e. there is a new RPC call sendrawtransactions.</li><li>The default dust relay fee has been updated to follow the default mininum relay fee. These two values are named “dustrelayfee” and “minrelaytxfee” in the bitcoin configuration file. In v1.0.5 both values default to 250 Satoshis/kb but can be set independently in the bitcoin configuration file. With the dust relay fee set to 250 Satoshis any transaction output paying less than 135 Satoshis will be considered dust. Setting the dustrelayfee to 1000 Satoshis via the configuration file will calculate a dustthreshold of 546 Satoshis instead of 135. 546 Satoshis was also the threshold for the previous version of BitcoinSV.</li></ul>



Below is an example of how to calculate the dust threshold using the Python console:



<pre class="wp-block-code"><code>$ python3
Python 3.8.5 (default, Jul 28 2020, 12:59:40)
&#91;GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
&gt;&gt;&gt;
&gt;&gt;&gt; def h(dust_relay_fee_per_kb):
… return 3 * int(182 * dust_relay_fee_per_kb / 1000)
…
&gt;&gt;&gt; print (h(250))
135
&gt;&gt;&gt;</code></pre>



*Note you will need to use the config option -blockassembler=legacy if you wish to continue to use the legacy block assembler for mining.



<a href="https://download.bitcoinsv.io/bitcoinsv/1.0.5/" target="_blank" rel="noreferrer noopener">To download v1.0.5 click here</a>

Bitcoin SV Node software – important upgrade to v1.0.5

mAPI v1.1 Release



The latest release of mAPI introduces a number of changes in preparation for further scaling. A feature of particular interest to high volume mAPI users is the ability to more efficiently batch transaction submissions together in one request.



This upgrade also includes numerous improvements and service hardening. These include decoupling mAPI from bitcoind, where possible, so that even when the Bitcoin node is overloaded (during a stress test for example), mAPI will continue functioning smoothly without any hiccups.&nbsp;



Changes detailed:



– Add new API endpoint to submit multiple txs&nbsp; (<a href="https://github.com/bitcoin-sv-specs/brfc-merchantapi#Submit-multiple-transactions" target="_blank" rel="noreferrer noopener">https://github.com/bitcoin-sv-specs/brfc-merchantapi#Submit-multiple-transactions</a>)



– Add functionality to listen on a node’s ZMQ



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; –&nbsp;avoid querying the node over RPC on every API call&nbsp;



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; – add&nbsp;new blockchaintracker package



– Return the txid in queryTransactionStatus response



– Service hardening, refactoring, and dependency upgrades



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; – inject the git tagged version into the binary dynamically (also in docker image)



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; – more detailed input validation on different types of txs (with new version of libsv in SubmitTransaction.go)



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; – bug fix should a tx be supplied with an invalid previous tx index



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; – move server into own file in the handle package



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; – add more comments to exported types



To download mAPI version 1.1 click <a href="https://github.com/bitcoin-sv/merchantapi-reference" target="_blank" rel="noreferrer noopener">here</a>

mAPI v1.1 Release

Version 1.0.4 is a recommended upgrade to version 1.0.3; it contains performance hardening changes to improve stability under high network load conditions.



Note: that if the minimum mempool size is now less than 30% of the default mempool size, the node will not start.



Here is a full list of v1.0.4 changes:



<ul>
<li>Increase default script cache size to improve performance with large blocks</li>



<li>Optimise frequent malloc calls in GetOp2</li>



<li>Reduce the number of orphan transactions during PTV processing.</li>



<li>Minimum mempool size must be at least 30% of default mempool size.</li>



<li>Windows build; Separate running tests from C++ build.</li>



<li>Fix: P2P stops sending data under some circumstances</li>



<li>Fix: formatting of floating point number in log messages</li>



<li>Fix: Missing debug flags in CMake</li>



<li>Fix: P2P getaddr returns very polluted results</li>



<li>Gitian build fix: instruction[_iterator].h location in Makefile.am</li>



<li>Fix race condition in bsv-trigger-safe-mode-by-invalid-chain.py</li>



<li>Fix: bug in thread pool tests</li>



<li>Fix: Failing unit tests in debug on develop branch</li>



<li>Remove excess physical dependencies (#includes) on script.h</li>



<li>Implement caching invalid signatures</li>



<li>Ban nodes that violate the `maxscriptnumlengthpolicy` policy setting</li>
</ul>



<a href="https://download.bitcoinsv.io/bitcoinsv/" target="_blank" rel="noopener nofollow">To download v1.0.4 click here</a>

Bitcoin SV Node software – recommended upgrade to v1.0.4

This new release is an optional upgrade to version 1.0.2. and contains additional feature changes. Below the list of changes introduced in v1.0.3:



Operational Software upgrade The single release binary now runs on Ubuntu 18.04 and CentOS 8. Users of Ubuntu 16.04 and CentOS 7 must build the binary themselves; new build instructions for these OSes have been added to the release.



P2SH outputs Pay-to-script-hash (P2SH) outputs in coinbase transactions are now rejected on block submission.



Re-org’s Fixes related to more efficient processing of reorgs.



STN reset The STN had a chain reset this month. This reset the chain in order to reduce resource consumption in test environment. To continue to use the STN without interruption/manual intervention ensure you’re on the most up to date version of Bitcoin SV (1.0.3)



<a href="https://download.bitcoinsv.io/bitcoinsv/">Click here to download the latest version.</a>

Optional software upgrade to v1.0.3

Background



As the Bitcoin SV network continues its evolution toward the structural model described by Satoshi Nakamoto, new tools are emerging to support that change.&nbsp; As a part of the drive toward a safer instant transaction paradigm, the Miner ID and Merchant API projects have been discussed extensively.



These projects have been in private beta testing and are now being released as a public beta and entering a public review process in the form of an RFC release.



<h2 class="wp-block-heading">Services</h2>



<h3 class="wp-block-heading">Merchant API</h3>



Merchant API provides two critical services to enable application and wallet developers to use the Bitcoin network more efficiently:



<ol><li>Fee discovery: This service enables parties creating transactions to know in advance what fee levels are required to guarantee the necessary service level from miners.&nbsp; This is a critical service to enable a dynamic and floating real time fee market to emerge.</li><li>Direct transaction submission: This allows users to bypass the outer layers of the Bitcoin peer-to-peer network and submit transactions directly to miners. This avoids many of the propagation issues that arise in an environment where node policies are dynamically and competitively shifting.</li><li>User based fee policies to enable different fee structures for different use cases.</li></ol>



<h3 class="wp-block-heading">Miner ID</h3>



Miner ID is a mechanism for miners to securely take ownership of their identity and reputation backed by their own proof of work.&nbsp; It has many applications beyond the initial use cases presented in our first version and is designed to be extensible.



Initial use cases for Miner ID include:



<ol><li>Service advertising for Merchant API REST endpoints.</li><li>Provision of identities for signing Merchant API responses.</li></ol>



<h2 class="wp-block-heading">RFC phase</h2>



It is intended that standards for both Merchant API and Miner ID will be passed through the Bitcoin Association’ Technical Standards Committee (TSC) process, as soon as that is up and running.&nbsp; For expediency though, the proposed standards are being released now for public review.



Both API standards are on Github and we request that feedback be directed through the Github issue system.



<h2 class="wp-block-heading">Specifications</h2>



The draft specifications are in <a href="http://bsvalias.org/01-02-brfc-id-assignment.html">BRFC format</a> and can be found here:



<ol><li><a href="https://github.com/bitcoin-sv-specs/brfc-merchantapi">https://github.com/bitcoin-sv-specs/brfc-merchantapi</a></li><li><a href="https://github.com/bitcoin-sv-specs/brfc-minerid">https://github.com/bitcoin-sv-specs/brfc-minerid</a></li><li><a href="https://github.com/bitcoin-sv-specs/brfc-misc">https://github.com/bitcoin-sv-specs/brfc-misc</a></li></ol>



The `misc` repository is for common specifications that have use cases outside of Merchant API and Miner ID.&nbsp; For example the fee spec standard will be proposed for adoption as a general standard for describing fees and will likely be proposed to be used in BIP270.



To offer feedback, please use the Github issue system for the respective standard repositories.



<h2 class="wp-block-heading">Reference implementations</h2>



Reference implementations can be found here:



<ol><li><a href="https://github.com/bitcoin-sv/merchantapi-reference">https://github.com/bitcoin-sv/merchantapi-reference</a></li><li><a href="https://github.com/bitcoin-sv/minerid-reference">https://github.com/bitcoin-sv/minerid-reference</a></li></ol>



<h2 class="wp-block-heading">Endpoints</h2>



<h3 class="wp-block-heading">Scaling test network</h3>



For application developers that would like to test against the Merchant API a test instance is currently available.



MAPI: <a href="https://galt.bitcoinscaling.io:9004/mapi/feeQuote">https://galt.bitcoinscaling.io:9004/mapi/feeQuote</a>



Block explorer: <a href="https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstn.whatsonchain.com%2F&amp;data=02%7C01%7Cs.shadders%40nchain.com%7C61c840e357f44607b65308d7d705e983%7C6e031f8d35cc44c5b695c8d2958c0550%7C1%7C0%7C637214292701738415&amp;sdata=lp4xW1EDxGQ8hLt8b1J%2F4PNVWT2a5ENWNBFYru3%2BF9c%3D&amp;reserved=0">https://stn.whatsonchain.com/</a>



Faucet: : <a href="https://faucet.bitcoinscaling.io/">https://faucet.bitcoinscaling.io/</a>



<h3 class="wp-block-heading">Mainnet</h3>



<a href="https://www.mempool.com/">Mempool</a> have made available a mainnet instance of Merchant API for developer testing.



Documentation: <a href="https://developers.dotwallet.com/en/dev/api/merchant">https://developers.dotwallet.com/en/dev/api/merchant</a>



Example endpoint: <a href="https://www.ddpurse.com/openapi/mapi/feeQuote">https://www.ddpurse.com/openapi/mapi/feeQuote</a>



 In order to use this endpoint you will need to add the HTTP header:



<code>token: 561b756d12572020ea9a104c3441b71790acbbce95a6ddbf7e0630971af9424b</code>



More Merchant API instances on mainnet are expected to be up and running soon.



<h2 class="wp-block-heading">Contacts</h2>



For support and general discussion of both standards and reference implementations please join the following telegram group: <a href="https://t.me/joinchat/JB6ZzktqwaiJX_5lzQpQIA">https://t.me/joinchat/JB6ZzktqwaiJX_5lzQpQIA</a>



<h2 class="wp-block-heading">Roadmaps</h2>



Further features are planned for both services.



<h3 class="wp-block-heading">Merchant API</h3>



Work has already begun on phases 2 and 3 of Merchant API with a view to adding the following features:



<ol><li>Enabling callbacks for Merkle proofs and double spend notifications.<ol><li>An underlying messaging system is under development to solve the problem of offline communications which is a dependency for this feature.</li></ol></li><li>Aggregator service that can act as an intermediary between merchant and many miners to provide fee aggregations services and dedicated distribution of transactions where required.</li></ol>



<h3 class="wp-block-heading">Miner ID</h3>



Use cases for Miner ID are implemented both as extensions to the protocol defining content of the coinbase document, along with uses of the actual ID in other contexts. Some examples include:



<ol><li>Publication of further policies and default fee specifications</li><li>Miner communication where miners can communicate with each other or with the public with proof of their mining history</li><li>Certification of statements of truth by collecting statements from numerous Miner IDs and aggregating total hash power backing the statement</li><li>Double spend notifications backed by miner reputation</li><li>Authentication mechanism for access to miner exclusive services e.g. Streaming block template protocol.</li></ol>

Miner ID and Merchant API beta release

This new release is an optional upgrade to version 1.0.1. and contains some minor bug fixes and additional feature changes that were deferred until after Genesis to minimise deployment risks during the upgrade process



The full list of v1.0.2 enhancements and fixes below:



Enhancements



<ul><li>Updated exception processing during validation</li><li>Make block stalling timeout configurable</li><li>Updated orphan transaction processing</li><li>Use _fseeki64 in Windows build.</li><li>Provide option to ban peers based on their user agent</li></ul>



Fixes



<ul><li>Fix assert in ProcessHeaderMessages</li><li>Fix JSON bug</li><li>Fix bsv-genesis-large-blockfile-io.py functional test</li><li>Fix sanitiser warnings re prevector</li></ul>



<a href="https://download.bitcoinsv.io/bitcoinsv/" target="_blank" rel="noreferrer noopener">Click here</a> to download the latest version.

Optional software upgrade to v1.0.2

This new release is an optional upgrade to version 1.0.0. It is not required to upgrade to this version before the Genesis hard fork. It is required to upgrade to version 1.0.0 or higher before the Genesis hard fork. This release includes several improvements, the most important being:



<ul><li>&nbsp;reduced memory requirements for the RPC interface when responding to “getrawtransaction” and verbose versions of “getblock” for large transactions. Platforms that integrate with the Bitcoin SV Node implementation and retrieve large transactions will benefit from this improvement.</li><li>&nbsp;Upgrade the database format for storing blocks &gt; 4GB</li></ul>



<h3 class="wp-block-heading">The full list of v1.0.1 enhancements and fixes below:</h3>



<h4 class="wp-block-heading">Enhancements</h4>



<ul><li>&nbsp;Update Windows build instructions for VS 2019</li><li>&nbsp;.vscode added to .gitignore</li><li>&nbsp;Misc document changes for Genesis</li><li>&nbsp;Switch to disable replacement (non-final) transactions</li><li>&nbsp;Policy limit on size of transaction inputs</li><li>&nbsp;Change default for maxtxnvalidatorasynctasksrunduration from 60 seconds to 10 seconds</li><li>&nbsp;Orphan txn size of 10MB should also be accepted</li><li>&nbsp;Provide -invalidateblock CLI switch</li><li>&nbsp;Optimize getblock/getblockrawtransactions for large transactions</li><li>&nbsp;Upgrade database format for larger blocks (&gt; 4GB)</li></ul>



<h4 class="wp-block-heading">Fixes</h4>



<ul><li>&nbsp;Fix: BSVRD-593 – accepting headers for Block 1</li><li>&nbsp;Fix disconnect pool limit overflow</li><li>&nbsp;Fix: autotools build system uses default compiler version gen</li><li>&nbsp;Fix unit tests that are failing because of the change in JSON formatting</li><li>&nbsp;Fix: lshift_big_int and rshift_big_int failing on windows</li></ul>

Optional upgrade before the Genesis Hard Fork

The Bitcoin SV Node team has released version 1.0.0 of the Bitcoin SV Node implementation. This version implements the updates required to support the Genesis hard fork upgrade which is scheduled to activate on February 4, 2020. The specification for the updates to the Bitcoin and Consensus rules is <a href="https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md" target="_blank" rel="noopener nofollow">available here</a>.



It is important to note that all installations of Bitcoin SV Node implementation must be upgraded to this release by February 4, 2020. Prior versions of the Bitcoin SV node software are incompatible with the updated rules and will fail after February 4.



<h2 class="wp-block-heading" id="h-highlighted-changes">Highlighted Changes</h2>



<h3 class="wp-block-heading" id="h-mandatory-consensus-parameters">Mandatory Consensus Parameters</h3>



Mandatory consensus parameters must be configured by the system administrator. The software will terminate immediately if these parameters are not configured. More information about the mandatory consensus parameters is available on the <a href="https://bitcoinsv.io/choosing-consensus-settings/" target="_blank" rel="noopener">bitcoinsv.io website</a>.



<h4 class="wp-block-heading" id="h-hard-limit-on-the-block-size">Hard limit on the block size</h4>



The hard limit on the block size is a configuration parameter that specifies the maximum size that a block can be in order for it to be validated by the software. Blocks that are larger than this maximum will not be retrieved by the software or validated.



Maximum Stack Memory Usage During Script Evaluation



This mandatory consensus parameter defines the maximum amount of memory that can be used on the stack by a script during evaluation. If a script attempts to use more stack memory than defined in this consensus parameter, then the evaluation of the script will be terminated and the script fails.



<h3 class="wp-block-heading" id="h-consensus-changes">Consensus Changes</h3>



<h4 class="wp-block-heading" id="h-restore-the-functionality-of-op-return">Restore the functionality of OP_RETURN</h4>



This change restores the function of OP_RETURN to its original design, enabling Script developers to terminate Scripts early and easily, with the possibility of the result of executing the script being valid.



<h4 class="wp-block-heading" id="h-change-the-script-numeric-type-from-32-bit-numbers-to-big-numbers">Change the script numeric type from 32 bit numbers to big numbers</h4>



This change will dramatically increase the mathematical capabilities of the Bitcoin Script language. 32-bit numbers are very limited in size which makes it very complicated and inefficient to do complex mathematical operations such as signature verification. This change will restore the original design, enhancing the efficiency of complex mathematical operations and enable complex Scripts that provide all kinds of advanced functionality.



<h4 class="wp-block-heading" id="h-sunset-p2sh-for-new-transactions">Sunset P2SH for new transactions</h4>



Pay-to-script-hash (or P2SH) is a mechanism introduced to Bitcoin to enable hiding of output scripts at the time they are created.&nbsp; This is counter to the philosophy of Bitcoin as an honest record of events. Additionally, P2SH use has encouraged wide use of poor privacy practices and divergence from the peer 2 peer workflow practices that are integral to the scaling proposition of Bitcoin. Existing P2SH coins will be unaffected so there is no need to sweep old wallets.&nbsp; This change prevents any new P2SH outputs from being made.



<h4 class="wp-block-heading" id="h-restore-satoshi-style-handling-of-nlocktime-nsequence">Restore Satoshi style handling of nLockTime &amp; nSequence</h4>



These two data fields are integral to the mechanism of payment channels that Satoshi describes as a fundamental mechanism for allowing high speed micropayments on Bitcoin.&nbsp; They have been since repurposed by BTC Core developers for two new op codes. Along with removing those op codes the original usage of nLockTime and nSequence are being restored.



<h3 class="wp-block-heading" id="h-other-required-change">Other Required Change</h3>



<h4 class="wp-block-heading" id="h-p2p-relay-of-transactions-with-complex-scripts">P2P Relay of transactions with complex scripts</h4>



This change will enable the use of complex transactions by all participants of the network. Prior to Genesis, only transactions that were of a standard type, such as payment transactions or plain data transactions, would be distributed across the peer-to-peer network and therefore reach a miner. This meant that if a participant needed to use complex transactions, they would have to find a miner and reach an agreement to confirm the transactions in a block. After Genesis, all transaction types will be relayed across the peer-to-peer network, enabling anyone to use complex transaction types.



<h2 class="wp-block-heading" id="h-additional-consensus-changes">Additional Consensus Changes</h2>



<ul>
<li>Genesis Upgrade block height activation mechanism</li>



<li>UTXO age dependent rules</li>



<li>Formal Script Grammar</li>



<li>scriptSig can only contain OP_PUSHDATA operations</li>



<li>Sunset OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY for new transactions</li>



<li>Add a policy limit on max_script_memory_usage with a default of 100MB</li>



<li>Add a consensus limit on max_script_memory_usage</li>



<li>Remove the consensus limit on the number of signature operations per MB of block space</li>



<li>Remove the consensus limit on the maximum number of signature operations per transaction</li>



<li>Remove the consensus limit on the number of op codes per script</li>



<li>Remove the consensus limit on the maximum script element size</li>



<li>Remove the consensus limit on the maximum number of elements in a script</li>



<li>Remove the consensus limit on the maximum number of public keys per multisig</li>



<li>Increase the consensus limit on the maximum transaction size to 1GB.</li>
</ul>



<h2 class="wp-block-heading" id="h-software-enhancements">Software Enhancements</h2>



<ul>
<li>Parallel Block Validation</li>



<li>Separate processing of non-standard transactions in low priority queue</li>



<li>Set script evaluation timeout policies for standard and non-standard transactions</li>



<li>Tx should be included in inv messages in the order in which they are validated</li>
</ul>



<ul>
<li>Enhance tests for Parallel Block Validation.</li>



<li>Common Genesis activation code and command line option.</li>



<li>Enable validation of non-standard txns (on MainNet) when Genesis is enabled.</li>



<li>Set mempool default = 1Gb.</li>



<li>Remove block size from user agent string.</li>



<li>Change default tx fees (default txfee = 0.5 sat/byte, default minrelaytxfee = 0.25 sat/byte)</li>



<li>Update SPV bloom filters re attack mitigation.</li>



<li>Improve performance of prevector deserialization.</li>



<li>Change logging messages to be more precise.</li>
</ul>



<ul>
<li>Fix: Validating non-standard transactions can lock up a node for more than a minute.</li>



<li>Fix: Tx validation uses original reject message and ban score is used</li>



<li>Fix block send queue overflow</li>



<li>Fix undefined behaviour in bsv::deserialize</li>



<li>Fix bitcoin-cli help getblock</li>



<li>Fix build: Configure should fail when it can’t detect boost</li>



<li>Set the execute bit on all the new Genesis functional tests.</li>



<li>Fix MedianTimePast</li>



<li>Fix: Nonfinal transactions with no inputs is rejected with incorrect reason</li>



<li>Fix memory leak in asn1_integer</li>



<li>Fix boost::optional warnings</li>



<li>Fix: hexhdr.py does not get included in packaged source</li>



<li>Fix: Fundrawtransaction RPC changePosition parameter causing out of bounds access</li>



<li>Add basic –enable-tcmalloc option to the build</li>



<li>Fix: CTxnDoubleSpendDetector deletion past end of vector</li>



<li>fix lshift and rshift on data larger than 2GB</li>



<li>Update to the RDP in preparation for Genesis</li>



<li>set max duration for async validation tasks</li>
</ul>

Changes for the Genesis Upgrade

The Bitcoin SV Node team released version 1.0.0 of the Bitcoin SV Node implementation today. This upgrade implements the Genesis Upgrade which will activate on the 4th of February and is a required upgrade. This stable release has undergone extensive QA testing and has had two beta releases.



The Genesis Upgrade is scheduled to take place on the 4th of February. In preparation for this upgrade, all installations of Bitcoin SV must be upgraded to this release by the 4th of February.



An important feature in this release is that two consensus parameters must be manually configured or the software will refuse the start. These mandatory consensus parameters are:



<ul><li>excessiveblocksize – this parameter defines the maximum sized block that the software will accept. This is a consensus parameter and blocks that are larger than the value of this parameter will be considered invalid.</li><li>maxstackmemoryusageconsensus – this parameter defines the maximum amount of stack memory that a script can consume during evaluation. Scripts which use more memory than the value of this parameter will fail, causing the transaction to be considered invalid. This is a consensus parameter and is applied during block validation.</li></ul>



The values chosen for these mandatory consensus parameters will depend on the use-case for the software and it is strongly recommended that operators of this software understand the implications of these configuration parameters. Full information on these configuration parameters can be found on the <a href="https://bitcoinsv.io/choosing-consensus-settings/" target="_blank" rel="noreferrer noopener">bitcoinsv.io site</a>. These mandatory consensus parameters can be defined in the configuration file or as parameters to the bitcoind executable.



The focus of this release has been the Genesis Upgrade. For more information on this upgrade, please see the <a href="https://bitcoinsv.io/genesis-hard-fork/" target="_blank" rel="noreferrer noopener">Genesis Upgrade pages</a>. In order to enhance the security of the software in the context of this upgrade, there have been several improvements to the scalability of the software, including Parallel Transaction Validation and Parallel Block Validation.

Genesis – 1.0.0 Stable Release

Second beta release for the Genesis release. Testers are encouraged to upgrade to this version of the software.



<h1 class="wp-block-heading">List of changes since beta1</h1>



<h3 class="wp-block-heading">Enhancements</h3>



<ul>
<li>Parallel Block Validation.</li>



<li>Enhance tests for Parallel Block Validation.</li>



<li>Common Genesis activation code and command line option.</li>



<li>Uncomment parts of functional tests that was depended on other now complete code.</li>



<li>Enable validation of non-standard txns (on MainNet) when Genesis is enabled.</li>



<li>Set mempool default = 1Gb.</li>



<li>Remove block size from user agent string .</li>



<li>Change default tx fees (default txfee = 0.5 sat/byte, default minrelaytxfee = 0.25 sat/byte)</li>



<li>Update SPV bloom filters re attack mitigation.</li>



<li>Rename acceptp2sh to acceptp2sh_ashashpuzzle.</li>



<li>Improve performance of prevector deserialization.</li>



<li>Remove the limit on the number of CHECKSIGS per MB of block space.</li>



<li>Provide unit tests for LimitedStack/vector.</li>



<li>Change logging messages to be more precise.</li>
</ul>



<h3 class="wp-block-heading">Bug Fixes</h3>



<ul>
<li>Fix: Validating non-standard transactions can lock up a node for more than a minute.</li>



<li>Fix: Tx validation uses original reject message and ban score is used</li>



<li>Fix block send queue overflow</li>



<li>Fix undefined behaviour in bsv::deserialize</li>



<li>Fix bitcoin-cli help getblock</li>



<li>Fix build: Configure should fail when it can’t detect boost</li>



<li>Set the execute bit on all the new Genesis functional tests.</li>



<li>Fix MedianTimePast</li>



<li>Fix: Nonfinal transactions with no inputs is rejected with incorrect reason.</li>



<li>Fix memory leak in asn1_integer</li>



<li>Fix boost::optional warnings</li>



<li>Fix: When validating mempool transactions, a reject message is sent if the high priority queue times out.</li>



<li>Fix: hexhdr.py does not get included in packaged source</li>
</ul>

The Genesis second beta version – released

The Bitcoin SV Node team released version 0.2.2 of the Bitcoin SV Node implementation today. This version is an optional beta release for use on the BSV mainnet; however it is a required release for the Scaling Test Network. We encourage node operators to upgrade to this version but advise caution and careful monitoring, especially for miners. We also recommend that miners maintain an instance of version 0.2.1 as a precaution.



The key features of this version are an increased transaction throughput capacity; this version is able to process more transactions per second and produce blocks with higher numbers of transactions. Preliminary testing on the Scaling Test Network show an increase from a sustained 200 transactions per second for version 0.2.1 to about 400 transactions per second with this version.



The key features in this release are:



<ul>
<li>Parallel Transaction Validation – the capability to validate multiple transactions simultaneously </li>



<li>Incremental Block Assembly – the capability for miners to continually build bigger blocks </li>



<li>Internal Block Streaming – internal changes that reduce the memory requirements for processing large blocks, decoupling the memory requirements from the block size </li>



<li>Scaling Test Network Reset – the scaling test network blockchain is rapidly approaching 2 terabytes of data. In order to simplify testing the Scaling Test Network is being reset. </li>
</ul>



These features bring substantial improvements to the capacity of the Bitcoin SV blockchain and also pave the way for future capacity improvements within the software.



The improvements included in this version have required extensive changes to the software and due to the complexity of these changes, we are designating this release as a “beta” version. We encourage node operators to upgrade to this version but advise caution and careful monitoring, especially for miners. We also recommend that miners maintain an instance of version 0.2.1 as a precaution.



Source code is available on the <a href="https://github.com/bitcoin-sv/bitcoin-sv" target="_blank" rel="noopener nofollow">bitcoin-sv github</a> and the signed binaries are available <a href="https://download.bitcoinsv.io/bitcoinsv/0.2.2.beta/" target="_blank" rel="noopener nofollow">here</a>.

Bitcoin SV Node v0.2.2 Beta Release

The Bitcoin SV Node team released version 0.2.1 of the Bitcoin SV Node implementation today. This version is an optional release; it adds certain improvements but it is not required for the Quasar protocol upgrade which is scheduled for July 24.



The primary feature of this release is an improvement which substantially decreases the time it takes to produce blocks with many transactions, enabling miners to produce even larger blocks than are already common on the Bitcoin SV blockchain.



Another important feature is the expansion of the RPC getblock function to enable the inclusion of transaction details. This is particularly important for large blocks as it means system integrators can retrieve all the details of a block and the transactions confirmed by the block with just one RPC call.



Changes of note include:



<ul>
<li>Optional preloading of the UTXO set into file system cache – this results in performance improvements when validating transactions</li>



<li>Calls to TestBlockValidity() call are now configurable using -blockcandidatevaliditytest option – this substantially reduces the time it takes for the node to assemble a block for mining</li>



<li>Transaction details in RPC getblock – this is an improvement for integrating other systems with the node</li>



<li>Support for OP_FALSE OP_RETURN as a standard transactions – this is a preparatory step before OP_RETURN is repaired to its original function in the Genesis upgrade early next year</li>



<li>Remove Bitcoin ABC cashaddr address format – the Bitcoin SV Node implementation will no longer support the BCH cashaddr format addresses</li>



<li>Various minor refactoring and other improvements</li>
</ul>



Source code is available on the <a href="https://download.bitcoinsv.io/bitcoinsv/0.2.1/" target="_blank" rel="noopener nofollow">bitcoin-sv github</a> and the signed binaries are available <a href="https://download.bitcoinsv.io/bitcoinsv/0.2.1/" target="_blank" rel="noopener nofollow">here</a>.

Bitcoin SV Node v0.2.1 released

The Bitcoin SV Node team released version 0.2.0 of the Bitcoin SV Node implementation today. This update to the software continues the Bitcoin SV focus on massive scaling, delivering a new API to support mining massive blocks and including support for the Quasar Bitcoin SV protocol upgrade that is scheduled for July 24th 2019. The Quasar Bitcoin SV protocol upgrade will increase the maximum acceptable block size from 128MB to 2GB.



The release has been managed using the team’s enterprise-class development, release, and quality assurance processes, providing additional assurance on the quality of the software delivered.



The new mining API is a big step forwards towards mining massive blocks on the Bitcoin SV network. This API is based on the work of Andrew Stone and Johan van der Hoeven and was subsequently collaboratively updated by nChain with input from mining professionals. The API removes the impact of the size of the block on mining operations, providing a fixed size header to the mining equipment regardless of block size. The design also removes the need for wallet capabilities to be included in the Bitcoin SV node implementation, which will enable significant performance improvements. This API will form the foundation of future improvements to the mining functions of the Bitcoin SV Node implementation while maintaining a stable API which miners can integrate into their systems.



Changes of note include:



<ul>
<li>new mining API</li>



<li>support for Quasar upgrade</li>



<li>change of the license to Open BSV license</li>



<li>default maximum OP_RETURN size to 100kb</li>



<li>default transaction relay delay to 150ms</li>



<li>upgrade to C++17</li>



<li>removal of support for 32-bit and ARM architectures</li>



<li>cleanup of defunct code – magnetic upgrade activation, ABC forced obsolescence</li>
</ul>



Source code is available on the <a href="https://github.com/bitcoin-sv/bitcoin-sv">bitcoin-sv github</a> and the signed binaries are available <a href="https://download.bitcoinsv.io/">here</a>.

Bitcoin SV Node v0.2.0 released

The Bitcoin SV Node team released <a href="https://download.bitcoinsv.io/bitcoinsv/0.1.1/">version 0.1.1</a> of the Bitcoin SV Node implementation today. This update to the software continues the Bitcoin SV focus on massive scaling, delivering crucial capacity and performance increases to transaction propagation. Such improvements include faster relaying of transactions to enhance the security of Instant Transactions, larger network messages to handle higher volumes of transactions, and increased parallelization of network communication.



The scaling-focused changes in the release have all been researched and tested in the private Gigablock Testnet which is now being relaunched publicly under the new name: Scaling Testnet (STN). More information on the STN can be found at <a href="https://bitcoinscaling.io/">https://bitcoinscaling.io/</a> .



Opening up the global Scaling Test Network to other participants in the Bitcoin SV ecosystem provides an environment for verifying the scaling capabilities of existing solutions and researching scaling technologies. It features a continuous flow of transactions with rates reaching 700 transactions per second. The advances included in the new release of the Bitcoin SV Node have been used on this network to achieve <a href="https://bitcoinsv.io/2019/01/23/warming-up-the-scaling-test-network-for-bitcoin-sv-24-hours-of-sustained-64-mb-blocks/">consistent 64MB blocks</a>, delivering sustained rates of over 300 transactions per second measured over a period of 24 hours.



The release has been managed using the team’s enterprise-class development, release, and quality assurance processes, providing additional assurance on the quality of the software delivered.



Some changes of note include:



<ul><li>Transaction propagation over P2P network<ul><li>Removal of random delay</li><li>Parallelization of inventory-handling code</li><li>Increase in size of inventory messages</li><li>Increased max protocol message size – BSVRD213/1</li></ul></li><li>Addition of the Scaling Test Network</li><li>Update DNS Seed servers to exclude BCH network</li><li>Large invalid block messages cause ban instead of disconnect</li><li>Optional logging of transaction sources</li><li>Various bug-fixes</li></ul>



Source code is available on the <a href="https://github.com/bitcoin-sv/bitcoin-sv">bitcoin-sv github</a> and the signed binaries are available <a href="https://download.bitcoinsv.io/bitcoinsv/0.1.1/">here</a>.

Bitcoin SV v0.1.1 released

Leading blockchain technology research and development outfit <a href="https://coingeek.com/nchain-releases-critical-evaluation-ctor/">nChain</a>&nbsp;has rolled out the release candidate of the Bitcoin SV client on October 15 — one month ahead of the November Bitcoin Cash (BCH) network upgrade.&nbsp; BCH miners and mining pools are encouraged to begin using Bitcoin SV.



<a href="https://bitcoinsv.io">Bitcoin SV</a>, which stands for Satoshi Vision, is a new full-node implementation for <a href="https://coingeek.com/bitcoin-bch-value-proposition/">Bitcoin BCH</a> designed to fulfil the vision set out by Satoshi Nakamoto’s original Bitcoin white paper.&nbsp; Unlike other competing BCH implementations which seek to make unnecessary changes to Bitcoin, Bitcoin SV’s roadmap is to restore the original Satoshi protocol, keep it stable, enable it to massively scale, and allow major businesses to confidently build on top of BCH.



Available on&nbsp;<a href="https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v0.1.0">GitHub</a>, the Bitcoin SV 0.1 version includes support for the November BCH upgrade, including the re-enabling of these Satoshi op_codes: OP_MUL, OP_INVERT, OP_LSHIFT, and OP_RSHIFT. The default maximum size of accepted blocks has also been increased from the 32MB soft limit to 128MB.



After spending 5 weeks in public beta, this release candidate makes one significant change from the beta version:&nbsp; raising the limit on the number of op_ codes per script to 500 rather than removing it altogether. The Bitcoin SV team intends to remove the op_code limit entirely at a later time, after further testing as part of its rigorous QA framework.



This release has streamlined to focus on its core audience of business users by disabling features meant for home users such as GUI and Windows support.&nbsp; Steve Shadders, Technical Director of the SV Project, said: “It’s time for Bitcoin to professionalize.&nbsp; Therefore, Bitcoin SV is targeted at business users, primarily miners but also cryptocurrency exchanges and merchants.&nbsp; By eliminating unnecessary features, we can keep the development focused on what really matters to our core user base.”



Additionally, the automatic replay feature and the activation logic for the&nbsp;<a href="https://coingeek.com/bitcoin-upgrade-done-32mb-blocks-smart-contracts-now-open-business/">May 2018 upgrade</a>&nbsp;have been removed. The release version also introduced protections against malicious peer behaviour, notably the so-called “infinite block attack”.



Going forward, Bitcoin SV will focus more on scalability of BCH.&nbsp; Daniel Connolly, lead developer for the SV project, explains: “For this initial release candidate, we focused on stability for the protocol by minimizing the change set.&nbsp; For future releases, we plan updates to enable massive scaling of the BCH network so that it can support major enterprise usage globally.”



Considered one of the most promising Bitcoin BCH node implementations, Bitcoin SV is born out of the desire to empower miners to direct the future of Bitcoin and also to ensure BCH miners remain profitable. &nbsp;Miners will have a choice and a voice to drive the process of restoring Bitcoin to its optimal state – that of unbounded blocks, original OP_Codes, and no artificial limits imposed on the protocol.



But why now? The reason, according to nChain Group CEO Jimmy Nguyen is simple:&nbsp;<a href="https://coingeek.com/bitcoin-sv-vision-give-miners-choice/">There’s a direct economic need for miners</a>.



At the recently held&nbsp;<a href="https://www.thefutureofbitcoin.cash/">The Future of Bitcoin Summit Bangkok 2018</a> in Thailand, Nguyen explained why it is important for the block size to begin scaling now —and scale fast:&nbsp; “In two years the block reward will be split in half again to 6.25 BCH. So anyone who’s mining now will in two years receive half of what they’re receiving today. In order to maintain even current profitability, what that means is in two years they have to make up that 6.25 coins worth of value in something else, which has to come in transaction fees and which has to come in higher transaction volume.”&nbsp;&nbsp; In fact, the BCH network needs to reach gigabyte size blocks by the year 2020 to keep miners profitable, so the road to massive scaling must begin now.



Explore the features of Bitcoin SV version 0.1&nbsp;<a href="https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v0.1.0">here</a>, and be part of the&nbsp;<a href="https://coingeek.com/vemund-skygazer-miners-choice-initiative-miners-every-right-autonomy/">Miner’s Choice</a>&nbsp;movement for Bitcoin BCH.



The <a href="https://bitcoinsv.io">Bitcoin SV</a> project was created at the request of and sponsored by Antiguan-based CoinGeek Mining, with development work initiated by nChain. The project is also owned by the Antiguan-based <a href="https://bcommassociation.com/">bComm Association</a> on behalf of the global BCH community, and the Bitcoin SV code is made available under the open source <a href="https://opensource.org/licenses/MIT">MIT license</a>.



NOTES TO EDITORS



For media enquiries, please email <a href="mailto:media@nChain.com">media@nChain.com</a>



or contact Infinite Global at:



Matthew Gilleard (Infinite Global, EMEA)



+44 (0)207 269 1430



Jamie Diaferia (Infinite Global, US/ASIA)



+1.212.838.0220

Releases