On the white paper view of hidden chains and double-spends

The Bitcoin SV team recently received <a href="https://github.com/bitcoin-sv/bitcoin-sv/issues/201">this request</a> on the Bitcoin SV github issue tracker.



“request to change the default script size limit from 10KB to 500KB”



The use case presented looks like a valuable one that we would like to see explored.&nbsp; However Bitcoin SV soundly rejected the model of “governance by developer decree” in favour of the original Bitcoin model where limits are determined by the competitive actions of miners. Which triggers the unseen hand of markets to define limits as emergent properties.



When Genesis activated the Bitcoin SV team made this public statement directly to miners:



“We would like to thank all of the miners that participated in the upgrade and offered assistance in various ways. The governance of Bitcoin consensus parameters is now in your hands.&nbsp; We will be available to advise but we will resist making recommendations and will no longer be making any decisions on your behalf. We know you will take this significant responsibility seriously perhaps because you care about Bitcoin but most certainly because it’s in your economic interest to do so.”



This is important to emphasise because the “governance by devs” model is what led to the strangulation of Bitcoin Core. We saw in the block size debates, a clear majority of miners in favour of raising block size but because it was established that devs made those decisions the miners submissively accepted their decision not to scale.



It is miners who collectively, but competitively, operate the Bitcoin network service and it is they that bear the risks of changing their own policy or consensus limits.&nbsp; It is not the role of the Bitcoin SV infrastructure team to impose additional risk on miners without a clear signal from miners that that is what they want.



Why have policy limits at all?



Policy limits are different to consensus limits in that they are chosen by individual miners and do not need to match a majority of other miners to avoid the risk of forking off the network.&nbsp; Many of those limits have a matching consensus limit that is set to a much more liberal value. All of those limits exist to mitigate some sort of risk to node stability in unusual or attack conditions. Without them the alternative would be to have no protection against potential crashes.



They exist in order to enable miners to make individual decisions about which risks to accept and in what quantity. Any miner is free to increase or decrease any of these limits. It is common for businesses to make decisions to accept risk if they expected reward outweighs the risk. It is also common for different businesses to have a different perception of risk and reward and make different decisions about the same risk.



How to get a policy limit raised?



The ancestor limit is a clear example of how this governance process should work, where the demand originated from the users and that translated into the miners wanting it and making that known to the Bitcoin SV team. Our customers are the miners.&nbsp; Their customers are the users of Bitcoin. The demand drivers of change flow from users -&gt; miners -&gt; infra-developers.



The right approach is to talk to the miners directly. They can change this limit right now with a config setting. So explain your use case, explain that you will generate additional transaction fees if they allow this. Once the demand is clear what usually happens is that miners talk to the Bitcoin SV Infra team and ask us to help them understand the risk profile of the change. Part of this risk profile is inevitably the increased orphan risk of accepting a transaction type that other miners might not.&nbsp;



If the risk is acceptable the miner will make the change. This usually results in more miners following suit so they can share in the transaction fees this new use case is generating.&nbsp; Eventually when enough miners adopt it, this orphan risk flips on its head and becomes a risk to the miners that haven’t adopted the new policy limit rather than the ones that have. At this point the signalling of miner demand is clear and Bitcoin SV Infra team will usually make a change to the default.



This is not the quick fix you’re looking for



Suppose, as a hypothetical, that the Bitcoin SV team decided to bypass the usual governance mechanism and attempted to impose a new limit on miners by releasing a new version of software with the default changed.&nbsp; Would it achieve the goal of increasing this limit across the board?



The short answer is ‘no’. Bitcoin miners can be broadly divided into two camps:



<ol type="1"><li>Those are that are pro-BSV</li><li>Those that aren’t very interested in BSV and are just here for the block rewards.</li></ol>



Miners like TAAL, Mempool, MatterPool and a few others are in the first camp and routinely adopt new versions of Bitcoin SV quite quickly.&nbsp; But those are also the miners that are also proactive in responding to user demand by changing policy settings to accommodate new use cases. They could put this change into effect today, whereas the Bitcoin SV team couldn’t do it until the next release at earliest.



There are quite a few in the other group as well.&nbsp; Many of them are absent right now because of the BTC price boom pushing up block reward profitability on BTC but we do expect them to return.&nbsp; This other group doesn’t tend to adopt new versions of Bitcoin SV very quickly at all. In fact we believe there are some still running v1.0.0.&nbsp; Changing the default will have no effect on them unless they upgrade to the latest version. Which they probably won’t any time soon if past behaviour is any indication..



So the end result is likely worse and slower to adopt than approaching the miners directly.&nbsp; For that reason we will not be implementing this change until we have a clear signal from enough miners that this is the new normal.



How to make this process even smoother



There are some changes coming to Bitcoin SV node that will lower the risks to early adopting miners and make the path for limit increases even easier.



The first risk we can mitigate is that whilst the particular use case that is driving the request to increase the limit might be known to be safe, we may not know what other use cases there are that might cause problems.&nbsp; In this example the request is to raise the script size limit from 10kb to 500kb.&nbsp; This allows a particular type of smart contract to be accepted.&nbsp; But it also allows every possible script that can be expressed in less than 500kb.&nbsp; And since this hasn’t been exhaustively tested we can’t be sure that doesn’t enable an attack vector.



A potential solution to this is to limit the raised limit to specific known users with known use cases. mAPI can allow this with a change to bitcoind that allows mAPI to flag a transaction to be allowed to ignore a policy limit. That mAPI operator can allow this much more easily than if they had to modify the Bitcoin SV software itself.



The second risk we can mitigate is orphan risk. Since mAPI has the ability to bypass some of the policy limits set on bitcoind, it is relatively simple for a miner to setup up a mAPI token for another miner that allows them to send them transactions that they are mining but do not meet standard policy limits.&nbsp; This allows the transaction to be kept in the other miner’s mempool and eliminates the additional cost of block propagation from that transaction.&nbsp; It’s not a perfect solution but it’s one that can be implemented relatively quickly and enables more flexibility.



Both of these mitigations will be enabled by the same feature in bitcoind which we previously mentioned.&nbsp; mAPI uses the ‘submitrawtransaction’ RPC call to send transaction to the node. It already takes an optional parameter to indicate that the node should bypass it’s fee checks.&nbsp; The feature allows an additional parameter to allow the node to bypass policy checks as well.



This feature is targeted for release in Bitcoin SV v1.0.9

On the governance of Bitcoin limits

It’s taken us a bit longer than we hoped, but the beta version of Bitcoin SV 1.0.7 (Dynastic) will be released in early January (hence the “belated” part of this article’s title).



The Dynastic release is the result of almost a year of work to untangle a particularly nasty mess we inherited from Bitcoin Core. As such, it is a huge code change which requires more than the usual level of care in testing. But I think most BSV app devs will agree it was worth it. Here’s the first hint (hey it’s Christmas, we need to unwrap this slowly!).



<figure class="wp-block-image size-large"><img loading="lazy" width="1024" height="341" src="https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1024x341.gif" alt="" class="wp-image-865" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1024x341.gif 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-300x100.gif 300w, https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-768x256.gif 768w, https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1536x512.gif 1536w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



This is an animated chart over time of submitting 2 million transactions to a Bitcoin SV node. The y-axis is the number of transactions accepted and the x-axis is seconds elapsed (sped up a bit). The orange line is the new beta version of SV, the blue is the previous 1.0.6 version. On the first chart you can see that 1.0.6 and 1.0.7 are almost identical. On the 2nd you can see a difference start to emerge and by the 3rd you can see that difference has become dramatic.



Why are there 3 charts side by side?&nbsp; The answer is at the top. The three charts show sets of transactions made of descendant chains of length 1, 50 and 1000. What you’ll notice on the blue lines is the reason why we’ve been plagued with an ancestor chain limit of 25. The performance hit is exponential as the chain length grows. We’ll explain why later in this article. The nice bit is the orange line, which shows zero degradation when chain length increases, in fact it even speeds up. Which brings us to the part where we tear open the Christmas wrapping:



The 25 chained ancestor limit is history!



In Bitcoin SV 1.0.7 beta we have raised the default limit from 25 to 1000. We have tested much longer chains and the same linear performance is observed, in fact we see no obvious reason not to remove it completely other than an abundance of caution in an adversarial environment. However, rest assured, after a few months of this 1000 limit being in the wild our intent is to get rid of it altogether. In fact we expect removing it to even result in a slight performance increase as we don’t need to do the accounting of chain lengths anymore.



So why was there a limit in the first place and why did it take so long to remove?



<h2>The history of block building</h2>



In the beginning, bitcoind v0.1.0 did it fairly simply.&nbsp; Once a second or so, it would take an in memory map of all the transactions it had received, check any new ones to ensure they met the minimum fee requirement and if so, add them to the block template which was basically an ordered list of valid transactions. It would then calculate a merkle tree from that set of transactions and build a block header to start doing proof of work upon. It could have been optimised but it was fairly efficient and didn’t do much unnecessary work.



Then along came a 1MB block size limit and ideas about a fee market. The idea was that limiting the block size would create demand for block space and drive up the transaction fees users would effectively bid to get included in a block.&nbsp; But this created a new requirement for the Bitcoin software to manage. If a miner can’t select all the available transactions due to the 1MB limit, they need to ensure they select the ones that pay the highest fee rates to maximise their revenues, leaving the less lucrative transactions for another miner to pick up later.



<h2>The consequences of limiting block size</h2>



And thus was the block building code turned into a nightmare of spaghetti accounting and other policy based limitations. Doing this job of selecting high paying transactions is not as simple as it sounds. When you have unconfirmed ancestors and child-pays-for-parent (CPFP) to account for there is a lot of graph traversal and other horrible complexity involved. Much of this involves traversing these graphs of related transactions every time you add a new one which brings with it quadratic computation cost. That is, the bigger a set gets, the more expensive every operation on that set becomes and the result is exponential degradation in speed.&nbsp; This is clearly visible in the above chart where we see that the rate we can get transactions to the mempool falls dramatically as it gets larger.



You can also observe the effects of this in the layout of blocks mined with Bitcoin Core, Bitcoin ABC and older versions of Bitcoin SV. The first transactions in blocks pay the highest fee rates and these get lower as you move toward the end of the block. This unfortunately removes the time ordering property of transactions in blocks which is a very useful feature of Bitcoin.



<h2>The solution</h2>



As is so often the case with Bitcoin, the solution to the problem was largely to just put it back the way it was. But this is easier said than done after 12 years of developer jiggery pokery on the code base.



Several releases of Bitcoin SV this year contained preparatory work that needed to be proven stable. Culminating in SV 1.0.6 where we replaced the default Legacy block assembler (LBA) module with the new Journaling block assembler (JBA) which returns to the simple model of:



<ol><li>Is the transaction valid? – yes</li><li>Does it pay our minimum fee? – yes</li><li>Append it to the transaction list</li></ol>



You see when block size is assumed to be unbounded there’s no need to worry about how high a transaction’s fee is with respect to other transactions, you simply select them all if they are above your minimum. This makes block building embarrassingly simple but also has profound effects on how Bitcoin fee markets work. It changes the dynamic from users bidding the price up, to miners competing to offer the lowest price and thus encouraging volume.



The fee selection logic we mentioned above was heavily intertwined with the LBA which meant we couldn’t remove this logic without breaking the LBA. So the sensible course was to remove the LBA entirely and in order to do that, we needed the replacement JBA to be fully stable. But the fee logic doesn’t just touch the block assembler, it touches almost everything in Bitcoin SV with tendrils that reach deep into very sensitive code.&nbsp; And some of that code affects the performance of the JBA.



And so the final step which we have achieved in the Dynastic release is to remove the LBA, clearing the path to removing the fee selection code and vastly simplifying the transaction selection logic.



Needless to say, this needed a lot of testing given the extent of the surgery it required. Our QA team is being forced to take a Christmas break this year after working through the holidays last year on Genesis (they’d probably work through the break if we let them because they’re rather a dedicated bunch). So we will have it out for beta testing in early January.



I really like this chart so I’m going to be indulgent and post it again. Not only because it solves this problem but because it demonstrates the structural principle that must be applied to solve all scaling challenges in Bitcoin:



<figure class="wp-block-image size-large"><img loading="lazy" width="1024" height="341" src="https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1-1024x341.gif" alt="" class="wp-image-866" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1-1024x341.gif 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1-300x100.gif 300w, https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1-768x256.gif 768w, https://theoffgrid.net/wp-content/uploads/2022/04/animation_1_0_6_vs_1_0_7_beta-1-1536x512.gif 1536w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



<ol><li>Don’t do work you don’t need to do</li><li>If you think you need to do it, question yourself ruthlessly</li><li>Keep the throughput/set size chart linear.</li></ol>



This particular problem is much easier to solve in Teranode than in Bitcoin SV since we don’t have to worry about surgically removing rubbish code whilst ensuring we don’t break anything. It’s simply a matter of applying such Satoshi-esque principles to the initial design. Satoshi was able to do it in alpha code.



Anyway, it’s a few weeks away so that will give app developers a bit more time to dream up ways to make use of longer chains. Like the explosion of script experimentation we saw post-Genesis I’m expecting to see a new wave of innovation with long transaction chains.



Merry Christmas from Team SV and stay safe.

A (belated) Christmas present from Bitcoin SV team.

Transaction volume on the Bitcoin SV blockchain&nbsp;approximately doubled for a few days last week – due to “<a href="https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-eu.mimecast.com%2Fs%2FktKjC7XR2Im9rLc887jk%3Fdomain%3Dtwitter.com&amp;data=04%7C01%7Cc.clark%40nchain.com%7C8a7b4c448c0b45e90ab408d88ad7befe%7C6e031f8d35cc44c5b695c8d2958c0550%7C1%7C0%7C637412006507576279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=R53iBu4nfVuOg5WmyiI2SNa29NeBbIA7zaDzdDDiy3o%3D&amp;reserved=0">multi source stamina testing</a>” on the Bitcoin SV mainnet by the <a href="https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-eu.mimecast.com%2Fs%2FuvomC8EV0ujxm9c1rxp_%3Fdomain%3Dmetastreme.com%2F&amp;data=04%7C01%7Cc.clark%40nchain.com%7C8a7b4c448c0b45e90ab408d88ad7befe%7C6e031f8d35cc44c5b695c8d2958c0550%7C1%7C0%7C637412006507586235%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=JUJC1hu9Ptx%2Fcg60r%2BOP7XJNrKGYRaTUsxszjfZqxEo%3D&amp;reserved=0">Metastreme</a> team for 5 days beginning September 28.&nbsp; This large increase in transaction volume is an opportunity to&nbsp;analyse&nbsp;the network and evaluate its performance&nbsp;under the increased load.&nbsp;



<h2>Timeline&nbsp;</h2>



The number of transactions being propagated across the network started to increase at approximately&nbsp;04:001&nbsp;on the 29th&nbsp;of September.&nbsp;The rate of transactions&nbsp;increased to around 20 transactions per second (tps) and&nbsp;has remained&nbsp;fairly constant&nbsp;since then, for at least 56 hours.&nbsp;



This is clearly visible in the chart below which shows the rate of increase of the number of transactions in the “mempool” of one of the nChain nodes. 



<figure class="wp-block-image size-full"><img loading="lazy" width="799" height="261" src="https://theoffgrid.net/wp-content/uploads/2022/04/image.png" alt="" class="wp-image-871" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image.png 799w, https://theoffgrid.net/wp-content/uploads/2022/04/image-300x98.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/image-768x251.png 768w" sizes="(max-width: 799px) 100vw, 799px" /><figcaption>Figure 1 Rate of increase of number of tx in mempool </figcaption></figure>



This analysis focuses on the period from 2020-09-29 04:00 to 2020-10-01 12:00 with reference to earlier periods for comparison purposes.&nbsp;



<h2>Blockchain Performance&nbsp;</h2>



The first area to examine is the blockchain itself. 



<figure class="wp-block-image size-full"><img loading="lazy" width="582" height="160" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-1.png" alt="" class="wp-image-872" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-1.png 582w, https://theoffgrid.net/wp-content/uploads/2022/04/image-1-300x82.png 300w" sizes="(max-width: 582px) 100vw, 582px" /><figcaption>Figure 2 Daily Transactions per Second </figcaption></figure>



Figure 2 shows the number of transactions per second averaged per day. The increase in transaction volume is clearly visible for the 29th and 30th of September. 



<figure class="wp-block-image size-full"><img loading="lazy" width="1024" height="186" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-2.png" alt="" class="wp-image-873" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-2.png 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/image-2-300x54.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/image-2-768x140.png 768w" sizes="(max-width: 1024px) 100vw, 1024px" /><figcaption>Figure 3 Transactions per day &amp; Average Block Size per day </figcaption></figure>



The two graphs in Figure 3 show similar increases in the total number of transactions per day and the average block size per day. 



<figure class="wp-block-image size-full"><img loading="lazy" width="1024" height="687" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-3.png" alt="" class="wp-image-874" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-3.png 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/image-3-300x201.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/image-3-768x515.png 768w" sizes="(max-width: 1024px) 100vw, 1024px" /><figcaption>Figure 4 Block sizes &amp; tx count </figcaption></figure>



Figure&nbsp;4&nbsp;shows&nbsp;blocks plotted against their size&nbsp;and the number of transactions, for all blocks in the time frame of interest. The&nbsp;chart shows&nbsp;many&nbsp;small blocks, with a significant number&nbsp;of blocks&nbsp;in the 10 to 30 MB range and one or two much larger blocks.&nbsp;It also shows a direct correlation between the size of the block and the number of transactions.&nbsp;There are two blocks significantly below the norm, these blocks may contain larger data transactions.&nbsp;The largest block was 58.4 MB with 199k transactions.&nbsp;



<h2>Software&nbsp;Performance&nbsp;</h2>



At nChain we manage a number of systems of various configurations and we monitor the performance of these systems. We reviewed the performance of these systems and the results are similar for all of them. The charts below are representative and have been taken from one of the smallest systems, a virtual machine with 4GB RAM and 2 virtual CPU. The charts cover about seven days, from the morning of the 25th to the morning of the 2nd of October, and are related to the performance of the node software.



<figure class="wp-block-image size-full"><img loading="lazy" width="744" height="297" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-4.png" alt="" class="wp-image-875" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-4.png 744w, https://theoffgrid.net/wp-content/uploads/2022/04/image-4-300x120.png 300w" sizes="(max-width: 744px) 100vw, 744px" /><figcaption>Figure 5 Number of connections to peers </figcaption></figure>



Figure 5 shows the number of open connections to peers, which we see remained constant over the period of interest. 



<figure class="wp-block-image size-full"><img loading="lazy" width="598" height="259" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-8.png" alt="" class="wp-image-876" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-8.png 598w, https://theoffgrid.net/wp-content/uploads/2022/04/image-8-300x130.png 300w" sizes="(max-width: 598px) 100vw, 598px" /><figcaption>Figure 6 Mempool size</figcaption></figure>



 Figure 6 shows a chart of the mempool, which is the pool of transactions that the software has received. You can see a repeating pattern where the software receives transactions and these are then removed when a block is mined. 



<figure class="wp-block-image size-full"><img loading="lazy" width="610" height="261" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-7.png" alt="" class="wp-image-877" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-7.png 610w, https://theoffgrid.net/wp-content/uploads/2022/04/image-7-300x128.png 300w" sizes="(max-width: 610px) 100vw, 610px" /><figcaption>Figure 7 Detailed view of mempool </figcaption></figure>



Figure&nbsp;7&nbsp;shows a&nbsp;more detailed view of the&nbsp;mempool, covering the period from 1st&nbsp;of October to the morning of the 2nd. The green line shows the size of the&nbsp;mempool&nbsp;in bytes, while the orange line shows the number of transactions. The lines are highly correlated as expected.&nbsp;In the early morning of&nbsp;the 1st&nbsp;of October&nbsp;the&nbsp;mempool&nbsp;grows to&nbsp;over 52 Megabytes and 194,000 transactions, and then&nbsp;a single block&nbsp;confirms&nbsp;all of the transactions&nbsp;and they are removed from the&nbsp;mempool. That was the block at height&nbsp;<a href="https://whatsonchain.com/block-height/654926" target="_blank" rel="noreferrer noopener">654926</a>.&nbsp;



<h2>System Performance&nbsp;</h2>



nChain manages a number of Bitcoin SV systems of different configurations and monitors the performance of these systems.



<figure class="wp-block-image size-full"><img loading="lazy" width="601" height="203" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-6.png" alt="" class="wp-image-878" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-6.png 601w, https://theoffgrid.net/wp-content/uploads/2022/04/image-6-300x101.png 300w" sizes="(max-width: 601px) 100vw, 601px" /><figcaption>Figure 8 Overall CPU Usage </figcaption></figure>



Figure&nbsp;8&nbsp;shows the overall CPU usage for the system.&nbsp;We can clearly see the increase in CPU use due to the increased number of&nbsp;transactions&nbsp;but CPU use is still very low.&nbsp;



The Bitcoin SV blockchain is intended to scale and the Node implementation has been heavily optimized to enhance scalability. A critical strategy has been to parallelize its functions, so that the processing load is evenly spread across processors.  



<figure class="wp-block-image size-full"><img loading="lazy" width="1024" height="251" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-9.png" alt="" class="wp-image-879" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-9.png 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/image-9-300x74.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/image-9-768x188.png 768w" sizes="(max-width: 1024px) 100vw, 1024px" /><figcaption>Figure 9 CPU usage per core </figcaption></figure>



Figure 9 shows the processor usage for each processor. It shows an even distribution of load across the processors of the machine. Although this system only had two processors, other machines with more cores showed a similarly even distribution of load across processors. 



<figure class="wp-block-image size-full"><img loading="lazy" width="1024" height="445" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-10.png" alt="" class="wp-image-880" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-10.png 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/image-10-300x130.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/image-10-768x334.png 768w" sizes="(max-width: 1024px) 100vw, 1024px" /><figcaption>Figure 10 CPU usage per core for 6 CPU system </figcaption></figure>



Figure 10 shows the same chart for a system with six processors which further demonstrates the load distribution across processors. Note that there were approximately 100 peer connections for this system, which accounts for the increased total processor usage compared to the smaller system. 



<figure class="wp-block-image size-full"><img loading="lazy" width="592" height="254" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-5.png" alt="" class="wp-image-881" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-5.png 592w, https://theoffgrid.net/wp-content/uploads/2022/04/image-5-300x129.png 300w" sizes="(max-width: 592px) 100vw, 592px" /><figcaption>Figure 11 Memory use </figcaption></figure>



Figure&nbsp;11&nbsp;shows an&nbsp;expected&nbsp;increase in memory use due to the larger number of transactions&nbsp;but the increase is modest and well within the capabilities of the system.&nbsp;



Despite the doubling in transaction volume, this small system is still easily capable of keeping up with&nbsp;the&nbsp;blockchain.&nbsp;



<h2>Conclusion&nbsp;</h2>



The doubling of transaction volume had&nbsp;no&nbsp;adverse&nbsp;impact on the Bitcoin SV blockchain. The&nbsp;blockchain,&nbsp;network,&nbsp;and&nbsp;systems&nbsp;scaled to cope with demand, easily absorbing the additional transactions.&nbsp;The capability to support large blocks enables spikes in transaction volume to&nbsp;be quickly absorbed, delivering consistent confirmation times.&nbsp;



The work in parallelizing the&nbsp;processing across multiple processors has been successful, with the&nbsp;load being equally spread across processors. As transaction volume increases, more powerful servers can be deployed as required.&nbsp;&nbsp;

Bitcoin SV Blockchain Capacity Report

“A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution… “



– Satoshi Nakamoto



This is the very first sentence of the Bitcoin whitepaper.



When Bitcoin V0.1.0 was released in 2009, it contained a proof of concept feature that is perhaps the most overlooked in its history.  It was called “IP transactions” and it demonstrated the type of peer interactions that is referenced in that sentence.  When speaking about peers in a Bitcoin context, it is common to assume it is a reference to nodes. Nodes are in fact peers to each other. However, there is more than one type of peer in Bitcoin.  We can see from the general definition of the word that a set of peers is defined by commonality.



<figure class="wp-block-image size-full"><img loading="lazy" width="909" height="416" src="https://theoffgrid.net/wp-content/uploads/2022/04/pasted-image-0.png" alt="" class="wp-image-885" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/pasted-image-0.png 909w, https://theoffgrid.net/wp-content/uploads/2022/04/pasted-image-0-300x137.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/pasted-image-0-768x351.png 768w" sizes="(max-width: 909px) 100vw, 909px" /></figure>



This doesn’t preclude there being more than one set of peers.&nbsp; The peers referenced in the first sentence of the whitepaper are the users of the Bitcoin network, not the nodes. What use is the Bitcoin network without users, preferably billions of them?



The IP Transaction feature demonstrated exactly that direct user to user interaction which, when coupled with SPV (Simplified Payment Verification – referenced in section 8 of the Bitcoin whitepaper)&nbsp; light clients, is precisely what allows Bitcoin to scale. It is a very simple scaling principle: Don’t do work that isn’t relevant to you. It is SPV that allows users to ignore every part of the Bitcoin transaction history that isn’t relevant to them whilst still obtaining the security benefits of Bitcoin.



It was however a rudimentary implementation, a proof of concept if you will. And even Satoshi acknowledged that, in its original form, the IP Transactions implementation had some real problems:



<ul><li>How peers will find each other</li><li>Insecure connections</li><li>NAT traversal</li><li>Susceptibility to man-in-the-middle attacks</li></ul>



Additionally, it didn’t complete the picture as is common for prototypes. It didn’t have any facility for obtaining, verifying or passing on SPV merkle proofs.



Today, the Bitcoin SV Infrastructure Team are releasing three beta products simultaneously that, along with several other services, provide all the tools required to reimplement the IP2IP vision and address all of these well known problems in the process.&nbsp;



Bitcoin SV v1.0.6 (release code name “Push”)



<ul><li>New functions to provide and verify Merkle proofs</li><li>ZeroMQ notifications on double spend detection</li><li>(WIP) p2p broadcast of double spend detection to enable network wide awareness.</li></ul>



mAPI v1.2



<ul><li>Push based callback notifications for merkle proofs and double spends</li></ul>



SPV Channels v1.0.0&nbsp;



<ul><li>An end to end encrypted messaging nano-service with push capability that provides an always on point of presence for a Bitcoin user and provides a unified interface for handling both online and offline messaging.</li><li>As an always on service, it solves the NAT traversal problem by enabling any two parties to communicate in a private channel via a blind intermediary such that only outbound connections are required. This is similar in principle to how services like TeamViewer, Skype and Zoom work seamlessly even between users that are behind firewalls but with full e2e encryption.</li></ul>



SPV Channels is a new offering from the Bitcoin SV Infrastructure Team.&nbsp; Think of Channels as something similar to an IMAP mail server.&nbsp; If you’re offline, it collects messages for you, but when you’re online it passes them straight through to you.&nbsp; If you and another party are both online the experience is similar to having a direct connection, but e2e encrypted by default and without any of the horrible mail header format requirements. It can integrate with Paymail but the server itself has no visibility of the content and is completely agnostic to it. Other than that, it’s not very Bitcoiny at all. But it does fill a critical gap in the workflow of a peer 2 peer Bitcoin interaction.



The uses of SPV Channels go beyond that – to almost any off-chain coordination problem in Bitcoin and even outside of Bitcoin, such as;



<ul><li>Coordinating multisig or threshold signature groups</li><li>Spend notifications for wallets</li><li>Generic notification for anything</li><li>A base layer for a new generation of self sovereign email and/or instant messaging.</li></ul>



<h2>A use case with mAPI</h2>



Early versions of mAPI (formerly known as Merchant API) solved a couple of key problems like fee discovery and direct-to-miner transaction submission. Getting responses from miners about acceptance is simple as it can come as a direct response to the submission request. But there are events that happen after that user-miner connection is closed, such as receiving an SPV proof when the transaction is mined into a block. We put in a rudimentary mechanism of getting updates by polling mAPI for transaction status. But this is inefficient and for a particular use case, learning about double spend attempts, it is time critical so a better mechanism was required.&nbsp;



Enter the “push” model. Registering for a callback on an event is a common programming paradigm. SPV Channels enables this for user-miner interaction. When registering for a callback, you typically need to provide an always-on URL for the callback to go to. This isn’t something users on a mobile phone are likely to be able to provide.&nbsp;



Enter SPV channels.&nbsp; A hosted service (or self-hosted if you like) that acts as a channel for the user to receive messages. If the user is online, they’ll receive the messages straight away. If they are offline, the messages will be stored and forwarded as soon as the user comes online.&nbsp; In fact, the first internal version of SPV Channels was unimaginatively named “Store and Forward”.



So the workflow goes something like this:



<ol><li>Customer and Merchant find each other via Paymail service discovery; and establish two way encrypted communications via SPV Channels.</li><li>Merchant finds a miner’s mAPI via MinerID.</li><li>Merchant requests a fee quote from miner via mAPI.</li><li>Merchant sends customer a transaction specification via BIP270 including the required fee, payment amount and any other requirements for the transaction.</li><li>Customer sends the transaction (possibly along with merkle proofs and other requested info) to the merchant.</li><li>Merchant submits the transaction to miner via mAPI and registers an SPV Channel URL for callbacks.</li><li>If a double spend is detected, the miner will send a message to the SPV Channel which the Merchant will receive immediately if online.</li><li>Once the transaction is mined into a block, the miner sends a merkle proof to the SPV Channel – which the merchant wallet can retrieve and store in its database.</li><li>Optionally, the merchant sends the merkle proof back to the customer via their SPV Channel.</li></ol>



<h2>Who pays for all these services?</h2>



In the early days, the costs of operating these services will likely be minimal so someone will probably offer them for free. But eventually, the cost of such hosted services will add up. Wallets, Miners and payment processors might absorb some of those costs as part of their service offering.&nbsp;&nbsp;



But there is another option. There are a number of new service offerings here, so it’s worth listing them:



<ol><li>Hosted Paymail</li><li>Hosted SPV Channels service (could be provided by paymail provider)</li><li>Merkle proof provision (not necessarily from the miner that mines the transaction)</li><li>Double spend notification (can be any or many miners monitoring for you)</li></ol>



It will be interesting to see how the Bitcoin SV ecosystem develop and what kinds of businesses decide to offer these services.



Assume for some reason that you request each of the 4 services from 4 different service providers, all of them are services provided in the context of a transaction. This is a perfect use case for adding nano-payment outputs to a transaction. One or ten satoshis to each service provider for a one off service with no implied lock-in to each which creates a strong incentive for them to provide the service well.



<h2>The future of SPV Channels</h2>



The initial implementation of SPV Channels released today provides the basic framework and is currently only optimised for desktop. Our near term priorities are to get mobile client libraries available that leverage the push capabilities of iOS and Android devices. Further integrations with Paymail are required and, of course, we need horizontally scalable implementations. We can definitely see the provision of a combined channels/paymail hosted service being in high demand and look forward to seeing who is the first to offer it.



<h2>The future of SPV workflows</h2>



In what we have presented today, we have offered solutions to the blocking issues for the complete SPV workflow. Many of these solutions can be improved upon and optimised, but the end to end use case is possible right now with these components. We expect this entire workflow to be the subject of much discussion by the business operators on Bitcoin SV and quite possibly changes or complete alternatives proposed and adopted. But for now we have a base, a starting point that developers of consumer targeted products can begin building upon right now.

Realising (Finally) Satoshi’s  Peer to Peer Vision for Bitcoin

The Rails release of Bitcoin SV (v1.0.5) introduces several game changing features that have long been in the making.



<ol><li>Activation of the Journalling Block Assembler by default</li><li>Batch transaction submission</li><li>Free consolidation transactions</li></ol>



This release is code-named RAILS because its major features are aimed to open new and innovative payment cases using the Bitcoin SV protocol and ledger, and empower Bitcoin SV companies to build more infrastructure for payments – “payment rails.”



It is the last of these that we will focus on in the post.



<h2>The dust limit</h2>



Once upon a time some BTC developers, mindful of their parental responsibilities to all participants in the Bitcoin network, introduced a protective mechanism called the Dust limit. Leaving aside the debate about the rightness or wrongness of paternalistic developer attitudes, this limit persists today as a policy enforced by default by miners. It was put in place as an attempt to prevent people from falling into a particular trap.



A typical Bitcoin transaction looks something like this:



<figure class="wp-block-image size-full"><img loading="lazy" width="616" height="386" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-11.png" alt="" class="wp-image-889" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-11.png 616w, https://theoffgrid.net/wp-content/uploads/2022/04/image-11-300x188.png 300w" sizes="(max-width: 616px) 100vw, 616px" /></figure>



The notable part of this example transaction is that values paid (in satoshis) are very large in comparison to the fee. The payment is about $11 USD in today’s money whilst the fee is a tiny fraction of a cent. This tiny fee is what makes micropayments possible. No one wants to pay a significant chunk of their transactions as fees but when they are so low payments of even 1c are very feasible.  But there is a lower limit to what makes sense economically. And if you cross that limit far enough you get into territory where you can effectively render some satoshis unusable.



<figure class="wp-block-image size-full"><img loading="lazy" width="624" height="407" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-1-1.png" alt="" class="wp-image-890" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-1-1.png 624w, https://theoffgrid.net/wp-content/uploads/2022/04/image-1-1-300x196.png 300w" sizes="(max-width: 624px) 100vw, 624px" /></figure>



In the above example, we are trying to go beyond micro-payments and into what we will call “nano-payments” by attaching a tiny 10 satoshi output to an existing transaction.&nbsp; This is where the dust limit would normally kick in to prevent the transaction going through, because under the standard fee policies that we are all accustomed to in Bitcoin, this output would require a higher fee to spend than the value of the output itself. It’s economically cheaper to just write that 10 satoshis off than it is to ever spend it.&nbsp; Unless perhaps we wait and hope that Bitcoin SV rises many orders of magnitude and fees in satoshis fall equally.



Payment channels are a well-known mechanism enabling exchanges of value incrementally in units so small that they wouldn’t be economical in a Bitcoin transaction on their own.&nbsp; But there are other ways.&nbsp;



<h2>Consolidation transactions</h2>



A Bitcoin transaction has a variable number of inputs and a variable number of outputs.&nbsp; When a transaction is accepted the previous outputs (which are referenced by the inputs) are removed from the UTXO database and the outputs are added. So the net effect on the size of the UTXO database (in terms of discrete items not bytes) after accepting a transaction can be expressed as:



<pre class="wp-block-preformatted">utxo_delta = nOutputs - nInputs.&nbsp;</pre>



From a miner’s point of view the size of the UTXO database matters because the larger it is the higher the cost of maintaining it. This is offset by the increased value of transaction fees that results but it is still in all miner’s economic interests to trim the UTXO where possible. Enter the concept of a consolidation transaction which has many inputs and few outputs such that the utxo_delta is substantially negative resulting in a shrinking of the UTXO database.  Since this is already an economic net positive for a miner it is feasible for a miner to allow such a transaction with zero fee.



<figure class="wp-block-image size-full"><img loading="lazy" width="624" height="400" src="https://theoffgrid.net/wp-content/uploads/2022/04/image-2-1.png" alt="" class="wp-image-891" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/image-2-1.png 624w, https://theoffgrid.net/wp-content/uploads/2022/04/image-2-1-300x192.png 300w" sizes="(max-width: 624px) 100vw, 624px" /></figure>



In doing so not only do we enable a lot of existing dust UTXOs to become useful again, but we also open up some powerful new use cases that are not possible with the current dust limit.



In the above example we see a normal transaction with additional 10 satoshi outputs attached. The recipient of these outputs simply collects enough of them to meet the criteria for a free consolidation transaction then converts the collective value of 1000 inputs into a single, higher-value output. The size of the UTXO database is reduced by 999 entries. One might argue that these are UTXOs that wouldn’t have been created without this model being feasible, which may well be true, however, even ignoring existing dust cleanup benefits we end with essentially a net cost in UTXO size of zero whilst enabling highly flexible new use cases.



<h2>Nano service use cases</h2>



So how might you make use of the ability to pay as low as 1 satoshi for a service?&nbsp; Well that’s for other creative minds to explore but in terms of normal operations of the Bitcoin network here’s a few examples:



<ul><li>Paying a specific miner a few satoshis to return you a Merkle proof when a transaction is mined (regardless of whether they mine it).</li><li>Paying a specific miner to watch for double spends and notify you.</li><li>Payments to a paymail host.</li><li>Paying a channels server to store and forward your messages while you’re offline (more on that later).</li><li>Paying for insurance or countersigning by a specialist multisig custodian.</li></ul>



Basically any service that is related to an economic transaction could be paid for in this way. The main caveat is there needs to be an existing transaction moving value in excess of a typical transaction fee for the nano-payment to piggy back off of.



<h2>What about payment channels?</h2>



Payment channels are a perfectly valid way to achieve nano-payments which are useful in many scenarios. A payment channel only becomes useful when the likely settled amount is in excess of a transaction fee, but it allows incremental shifts of value in similarly small amounts to a consolidation transaction. This is useful where you might want to repeatedly use the same nano-service. There are trade-offs around implementation complexity to consider.&nbsp; Where a consolidation transaction differs is that it can be used as a one-off for a particular service without establishing a payment channel-like relationship with the counterparty. Which of the two makes the most sense will come down to a use-by-use evaluation.



<h2>So how do we use them?</h2>



Much like the early days of raising of the OP_RETURN limit, there will be a few initial barriers to getting such transactions accepted. Many will recall the efforts required to find nodes that supported it and to build connection pathways between enabled nodes so that OP_RETURN transactions could propagate.&nbsp; It took some time and became more reliable over time until blanket adoption was achieved.&nbsp; This will be similar but with a key accelerator provided by the Merchant API (henceforth known as mAPI).



Firstly the creation of dust outputs themselves are still limited to some degree by the dust limit. This limit will be removed entirely by the end of the year allowing even 0 value outputs. In the meantime the 1.0.5 release of bitcoin has at least fixed the hard limit and made it a function of the relay fee set by the Miner. This means that Miners who have upgraded to 1.0.5 should accept outputs greater than 140 satoshis.&nbsp;



Until widespread deployment by Miners is achieved the dust limit will remain a barrier to getting these transactions relayed which means you shouldn’t assume the same level of zero-conf assurance as a transaction with only non-dust outputs. But for use cases where zero-conf doesn’t matter this is safe to use right now.



Secondly for non-zero conf scenarios the p2p propagation can be bypassed entirely once mAPI supports these transactions. This is a feature of the mAPI 1.2 which is targeted for release in October. Once you couple a 1.2 mAPI with a 1.0.5 Bitcoin SV you’ll be able to submit both dust output transactions and consolidation transactions directly to a Miner.



<h2>Definition of a Consolidation transaction</h2>



In order for a transaction to be classified as consolidation by the Bitcoin SV software, some strict conditions must be met. nChain and the SV team have done some exhaustive analysis to choose these criteria in order to ensure the mechanism isn’t gameable. We have erred very much on the side of caution and so there is plenty of room for the criteria to be relaxed in the future, but the current criteria enable a consolidation transaction to be constructed fairly simply.



A consolidation transaction is a transaction that reduces the number of UTXO’s by a margin that is more valuable for the network than the implied fee. Hence we allow consolidation transactions free from any fees.



The conditions for a consolidation transaction are as follows:



<ul><li>The scriptPubKey sizes from the transaction outputs spent are compared to the scriptPubKey sizes of the consolidation transaction. The sum of the former must be greater than the sum of the latter multiplied by the consolidation factor (configuration parameter: minconsolidationfactor)</li><li>The transaction input count must be greater than the transaction outputs count multiplied by minconsolidationfactor</li><li>All inputs must have a confirmation count of at least minconsolidationinputmaturity.</li><li>scriptSig sizes of the consolidation transaction have an upper limit of&nbsp; maxconsolidationinputscriptsize bytes long to prevent gaming.</li><li>Inputs spent in consolidation transactions must meet the old test of isStandard() if acceptnonstdconsolidationinput equals 0</li><li>The default value for maxconsolidationinputscriptsize is 150 bytes.</li><li>The default value for minconsolidationfactor is 20</li><li>The default value for minconsolidationinputmaturity is 6 (equivalent to one hour)</li><li>The default value for acceptnonstdconsolidationinput is 0 meaning only standard inputs allowed</li><li>Setting minconsolidationfactor to 0 disables the free consolidation transactions feature</li></ul>



The condition as the formula is:



<pre class="wp-block-preformatted">c = minconsolidationfactor m = minconsolidationinputmaturity s = maxconsolidationinputscriptsize a = acceptnonstdconsolidationinput isFree =&nbsp; nInputs &gt;= c * nOutputs &nbsp; &nbsp; &nbsp; &nbsp;&amp;&amp; confirmationCount(input) &gt;= m for all inputs&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&amp;&amp; sum(inputTxScriptPubKeyBytesLen[]) &gt;= c * sum(outputTxScripPubKeytBytesLen[]) &nbsp; &nbsp; &nbsp; &nbsp;&amp;&amp; inputTxScriptSig &lt;= s for all inputTxScriptSig &nbsp; &nbsp; &nbsp; &nbsp;&amp;&amp; isStandardInput(input) for all inputs unless a == 1</pre>



As a general rule of thumb:



<ul><li>Consolidate at least 100 inputs to one output.</li><li>Only use standard p2pkh inputs or bare multisig with no more than 2 signatures.</li><li>Only use inputs confirmed for at least 6 blocks.<ul><li>This rule can be gotten around simply by constructing the transaction using all available inputs but not broadcasting it until 6 blocks after you made it.</li></ul></li></ul>



By following these guidelines you should fall well within the strict criteria. The worst that can happen if you don’t is that the transaction will get rejected with a ‘too low fee’ message in which case you can adjust it and try again.



The available set of transaction pricing models will ultimately be determined by miners and tested by market forces. This particular model is intended as a demonstration of what’s possible when restrictions are lifted.&nbsp; The SV team looks forward to seeing in what innovative ways nano-payments can be used.

Beyond micropayments: The rise of nano-services

<h2>Background</h2>



Some users performed a public stress test of the Bitcoin SV network, beginning on May 12, 2020 and apparently continuing for a week.&nbsp; During the first day of this public stress test, approximately 2 million low fee transactions were broadcast on the Bitcoin SV network.&nbsp; The vast majority of these transactions had a fee rate just over 0.25 sats/byte which is above the default relay fee, meaning the transactions were fully propagated around the network, but below the default transaction acceptance (or mining) fee of 0.5 sats/byte, meaning that most miners would not attempt to mine them.&nbsp; This resulted in a large mempool building up consuming as much as 1.7GB of memory.&nbsp; Note that the default mempool limit in BitcoinSV Node software is 1GB; however, most mining pools/groups have set their mempool limit significantly higher.



This “mempool buildup” event occurred just one day after the BTC block reward halving (on May 11), which caused a large influx of BTC miners to BSV, diluting the effective hash rate of the pre-existing dedicated BSV miners. This was apparent because the BSV network saw many 1MB blocks being mined in the days after May 11, suggesting that these new miners on BSV had imported configurations directly from their BTC setups.&nbsp; As such, the one mining pool we previously knew was mining with a transaction acceptance fee rate of 0.25 sats/byte (Mempool) was reduced to finding less than 1% of blocks on or around May 12, and was unable to process the backlog on their own.&nbsp; The mempool buildup was eventually cleared by TAAL, when it mined a world record 309MB block later on May 12.



<h2>Network impact</h2>



The Bitcoin SV Node team runs quite a few bitcoind instances on mainnet to monitor the state of the network.&nbsp; What we saw on our bitcoin daemons, as well as what we learned from various miners, was very encouraging.&nbsp; The Bitcoin SV Node software performed well within operating limits throughout this mempool buildup event. Some instances with the default 1GB mempool limit did not keep all of the transactions but they also didn’t slow down when they reached the 1GB limit. &nbsp;Neither did those instances need to keep all of the transactions in memory. The load from this event was a fraction of what Bitcoin SV is subjected to daily on the <a href="https://bitcoinscaling.io/">BSV Scaling Test</a> Network so this is unsurprising to us.



<h2>So what happened? – Relay fee vs transaction acceptance (mining) fee</h2>



It is important to note that there are two different fee settings in Bitcoin node software:&nbsp;



<ul><li>the relay fee, which determines whether a miner will accept a transaction into its mempool and broadcast it to other miners.&nbsp; In Bitcoin SV Node software, this is set by default at 0.25 sats/byte.</li><li>the transaction acceptance (mining) fee, which is what is needed for a miner to accept the transaction and add it into a block found by the miner.&nbsp; This is set by default at 0.5 sats/byte.</li></ul>



Thus, the default relay fee (0.25 sats/byte) is lower than the default transaction acceptance (mining) fee (0.5 sats/byte). &nbsp;&nbsp;Until late last year, these different fees were both set equally at 1 sat/byte so the difference in their function was not very apparent; furthermore, it was a given that if your transaction wasn’t rejected when you sent it, then it would also be mined rapidly. This was a substantial improvement over the BTC experience but it still had a significant downside:&nbsp; it left no room for miners to compete on fees.



Let’s hypothetically say that both relay and transaction acceptance fee rates are set by most miners to 1 sat/byte, and one miner wants to offer a lower rate (on both fees) of 0.8 sats/byte. &nbsp;A miner is of course free to offer the lower rate, but to take advantage of it as a user, you have a couple of important caveats:



<ol type="1"><li>You will lose all double spend protection because other miners will ignore the lower fee transaction, will not be able to detect a later transaction is a double spend.</li><li>You will not get the transaction relayed by other miners (because your relay fee of 0.8 sats/byte is lower than the 1 sat/byte required by the other miners), so to even get the transaction to the discounting miner, you have to find that miner’s node and submit it to them directly, via the Bitcoin peer-to-peer protocol.</li></ol>



The second problem can be solved with tools like Miner ID (to find the miner API endpoints) and Merchant API (to discover fees and to submit transactions easily to the discounting miners). The first problem is more concerning because if the starting point makes competitive price cutting uncompetitive due to immediate loss of utility, it is a very strong barrier to competition happening in the first place. We have seen the effect of this on BCH where after more than two years fee rates have remained stagnant.



By separating the two fees and leaving a gap in between them, we have a starting point where competitive pricing becomes possible. Any miner can reduce transaction acceptance fee as low as the relay fee, and transactions will still be fully propagated. Any miner could reduce the relay fee at any time, but in doing so, they would fully aware that they’d be on their own accepting those transactions for mining, for which they may have a market, but they would also be aware they have to have a plan to clear them out of their own mempool. Presumably by mining them.



But what happens if no one is mining these low fee transactions? Won’t they just build up until the nodes run out of memory?



In the short term, NO because the Bitcoin SV Node software handles this scenario gracefully: once the mempool reaches the configured limit of memory usage, it will start evicting lowest fee transactions to make room for new transactions. This costs the miners nothing so they can maintain this state indefinitely whilst still taking all the transactions that meet their fee requirement. This is scenario is very different to the one you might encounter on BTC when the mempool fills up because of one critical factor: It does not push the cost of a transaction fee UP, it just puts a miner configured floor under it. In the real Bitcoin, competition is the force that drives prices down, not full mempools. And users will always have certainty that they can get a transaction accepted by using known fee rate. It CAN potentially create a fee market incentivising lower fee transactions to increase their fees though CPFP but the critical difference between this market and the BTC market is that it has a known ceiling.



This mempool memory limit exists simply because it is preferable to having no fall back option. But it is not intended to ever be reached.&nbsp; And for several reasons, this is likely to be a very rare event:



<ol type="1"><li>Miners generally have very large mempools, most are configured with at least 8GB and they can raise this limit relatively easily in real time if there is an operational need to do so.</li><li>If you are a transaction sender, it is in your interests to discover what fee is required to get your transaction mined using services like Merchant API. Otherwise, users risk having their transactions stuck in a mempool for days or weeks, and unable to access those funds during that time without using a CPFP payment to nudge it over the line.&nbsp; Once the behaviour of “fee discovery” is widely adopted and probably also automated, it is unlikely we will see this type of mempool buildup scenario again. The transactions with low fees won’t be there by mistake, they’ll be limited to users that intentionally want to test the market or who don’t care how long it takes to have their transactions mined.</li><li>The mempool has a timeout: by default it’s two weeks, so it won’t keep filling up forever.</li><li>There is always likely to be at least one miner that will intervene if the mempool gets out of hand to sweep the mempool as we saw TAAL did on May 12 – mining a world record sized 309MB block.</li><li>Miners always have the hardline option of raising their relay fee and dropping all transactions below their transaction acceptance fee. I doubt they want to do this, but if they believe someone is trying to force them to drop fees by attempting to exhaust their mempool, they might just react by doing the opposite and demonstrating that miners are entirely free to choose what they include in their block.</li></ol>



It’s important to note that it is not much of a burden for miners to hold these transactions in memory.&nbsp; They don’t cause any significant CPU overhead; the transactions just sit there waiting.&nbsp; So as long as miners have enough memory (which most of them do), they can afford to hold transactions for as long as needed. &nbsp;Nevertheless, the Bitcoin SV Node team is planning further improvements to offer more options to miners in these scenarios. The first will be the option to evict transactions to disk rather than holding them in memory.&nbsp; This will allow transactions to be kept for longer if that’s what the miner wants to do.&nbsp; The second option is more flexible eviction policies where if a transaction doesn’t meet their transaction acceptance (mining) fee, the miner can accept it and hold in mempool for a short period (perhaps one day) before evicting it.



<h2>So why did miners intervene?</h2>



Given that the Bitcoin SV Node software was handling things just fine, you may be wondering why didn’t the miners just leave the mempool buildup as is? Eventually, Mempool would have mined those transactions because it was accepting 0.25 sat/byte transactions. One reason a miner (TAAL) decided to clear the mempool was due to some BSV application services reporting problems. &nbsp;I can speculate that because we had the attention of many BTC miners at the time due to the BTC block reward halving, it was probably a good time to demonstrate that a miner COULD.



Also I think there is a recognition among miners that the process of separating the relay fee from the transaction acceptance (mining) fee, and adjusting user behaviour is one that inevitably comes with some growing pains. And until users of Bitcoin (especially producers of high transaction volumes) adjust to new ways of interacting with the network that are more in line with Satoshi’s vision, a few hiccups will happen and miners don’t want services on the network to suffer needless outages. As the ecosystem professionalizes further, I’d expect miners to take a harder stance along the lines of “if you’re maintaining a mempool, you need to make sure you can handle it because we can and it isn’t our job to look after you”.

Comments on May 12, 2020 user stress test of Bitcoin SV network

At 1:28am GMT block 620,537 was mined and Bitcoin SV nodes of v1.0.0 or greater began accepting transactions under the restored Genesis protocol.&nbsp; At 1:55am at block height 620,539 the first block containing a Genesis-only transaction was mined, locking in the change. Old node software did not accept this block and forked off onto a legacy chain as intended.



The transaction that triggered the chains to hard fork was <a href="https://whatsonchain.com/tx/4ec3b63d764558303eda720e8e51f69bbcfe81376075657313fb587306f8a9b0">https://whatsonchain.com/tx/4ec3b63d764558303eda720e8e51f69bbcfe81376075657313fb587306f8a9b0</a>



This transaction was prepared in advance by the Bitcoin SV team and broadcast as soon as block 620,537 was mined. The transaction violated the old limitation for arithmetic inputs of 32 bits and was deemed invalid by old nodes whilst being valid under the Genesis rules which mirror those of the original protocol implemented by Satoshi Nakamoto. It contained the following message:



“On February 4th, 2020 The Return to Genesis was activated to restore the Satoshi Vision for Bitcoin. It is locked in irrevocably by this transaction. Bitcoin can finally be Bitcoin again and the miners can continue to write the Chronicle of everything. Thank you and goodnight from team SV.”



The transaction did not get mined into block 620,538 which was mined by an unknown miner, hence old nodes continued to follow the majority chain for one block longer than expected. There may have been other transactions with similar properties in the same block (620,539) however as this transaction was prepared specifically for the purpose of forcing legacy software to fork off we are referring to it as the “lock-in transaction”.



What is also notable about this transaction is that the above message was embedded twice. Once in the well known form of an OP_RETURN output but also embedded in a spendable output using Satoshi’s original pay-to-public-key script template.&nbsp; We believe this may be the first ever transaction that embeds data in a spendable output using this technique.&nbsp; To preserve this piece of history, the private key for this output has been destroyed and as such it will remain a permanent part of the UTXO set for as long as ECDSA remains secure.



The forking block (620,539) was mined by Taal.com and contained the coinbase string: “taal.com on behalf of Satoshi Nakamoto” which the Bitcoin SV node team feels is a fitting tribute to the proof of work displayed by Satoshi in creating the Bitcoin protocol and the efforts of miners to restore to his original design.



The legacy chain has been extended by an unknown miner by one block since the fork.&nbsp; This is most likely due to a small miner not upgrading their node to v1.0.0 or greater before the fork.&nbsp; We will continue to monitor the state of both chains however at the time of writing the Genesis chain is 75 blocks ahead of the legacy chain and widely supported across the ecosystem.



We note reports of up to 100 nodes remaining on older versions of the software.&nbsp; The Bitcoin SV team does not regard this as problematic as there is no evidence of a significant amount of hashing power backing this legacy chain and it is expected to cease being extended. Older versions of node software that are not mining are not contributing anything useful to the network and their removal is beneficial to the Bitcoin network by making propagation amongst upgraded nodes more efficient.



This is, without question, the largest set of consensus changes ever attempted in the history of Bitcoin and no change of such magnitude is done without some level of risk. &nbsp;However, given that the Genesis hard fork of Bitcoin is now 75 blocks ahead of the legacy chain and in the absence of any notable problems, the Bitcoin SV team considers the Genesis upgrade to have been successfully activated.



We would like to thank all of the miners that participated in the upgrade and offered assistance in various ways. The governance of Bitcoin consensus parameters is now in your hands.&nbsp; We will be available to advise but we will resist making recommendations and will no longer be making any decisions on your behalf. We know you will take this significant responsibility seriously perhaps because you care about Bitcoin but most certainly because it’s in your economic interest to do so.



Now that full capabilities of Bitcoin script have been unlocked we look forward very much to seeing what application developers will begin to do with that capability.&nbsp; This is the beginning of Bitcoin becoming what it was always meant to be.



Lastly we would like to offer our heartfelt thanks to Mr Calvin Ayre who made the formation of the Bitcoin SV team possible in 2018 and whose ongoing support has enabled it to grow to become the largest and most highly skilled engineering team in the history of Bitcoin.&nbsp; Without Calvin Ayre’s support Bitcoin would have died 14 months ago but because of his support it has been now restored to the state that Satoshi Nakamoto intended.



Thankyou.



On behalf of the entire Bitcoin SV team,



Steve Shadders and Daniel Connolly

Genesis activation successful

The draft Genesis specification was published in December 2019 in order to elicit feedback from Bitcoin SV miners and other ecosystem participants.&nbsp; This process has resulted in much valuable feedback and discussions between the Bitcoin SV team and other actors in the Bitcoin SV ecosystem.&nbsp; As a result we are now ready to update the specification and designate it as stable.



As <a href="https://bitcoinsv.io/2019/12/23/bitcoin-sv-blocking-potential-p2sh-replay-attack-after-genesis-hard-fork/">previously indicated</a> the prohibition on the P2SH (pay-to-script-hash) script pattern has been upgraded from a default local miner policy to a consensus rule.&nbsp; Following further feedback from miners and other actors it has been decided that the change to enable use of the original sighash algorithm is premature and to revert that change with a view to implementing it at a later time.&nbsp;



Whilst not part of the Genesis specification an additional change has been introduced to ensure the Bitcoin SV Node software cannot be started without explicitly setting the config parameters: “excessiveblocksize”, otherwise known as the block size “hard cap”, and “maxstackmemoryusageconsensus”.&nbsp; It will still be possible to set these values to unlimited however the user of the software will be required to actively make this decision in order to start the node.



The Genesis specification has been updated and is available <a href="http://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md">here</a>.&nbsp; Bitcoin SV node software has now entered code freeze and internal QA and we anticipate a stable release incorporating all of the above changes to be released on Tuesday 14th January 2020.&nbsp; Following this release we urge anyone running the Bitcoin SV node software to upgrade as soon as practical in anticipation of the Genesis activation on February 4th 2020.

Genesis specification finalized

The Bitcoin SV Node team notes the recent public disclosure on Reddit by Gregory Maxwell (a.k.a. /u/nullc) from the Bitcoin Core (BTC) of a potential replay attack vector on Bitcoin SV after the “Genesis” hard fork in February 2020 which will be deprecating the P2SH (pay-to-script-hash) feature that is not part of the Bitcoin design described by Satoshi Nakamoto.



The post describes a possible theft via replay attack of P2SH (pay-to-script-hash) transactions from the BTC chain that could be executed to steal unsplit funds of BTC users on the Bitcoin SV chain. The Bitcoin SV mission is to return Bitcoin to the vision described in Satoshi’s whitepaper which uses the word “honest” no less than 15 times and we emphatically reject the notion that obvious theft of coins by miners can fall within the definition of “honest” behaviour.



&nbsp;We note that Mr. Maxwell’s public disclosure in no way fits the broadly accepted definition of “responsible disclosure” and by describing in detail the steps required to exploit and potentially cause loss of funds to BTC users, we would deem it both irresponsible to BTC users and poor security practice.&nbsp; Had the disclosure been made responsibly according the guidelines set out in the Bitcoin SV <a href="https://bitcoinsv.io/security/">Responsible Disclosure Policy</a>, it likely would have been eligible for a substantial bug bounty.&nbsp; It is particularly puzzling to the BSV Node team that the disclosure was made in this public way by a BTC core developer given the users most likely put at greater risk by the disclosure are not those actively engaged with BSV, but primarily those that are BTC users who may not even be interested in BSV.



We note for the record that the Bitcoin SV Node team has previously made <a href="https://bitcoinsv.io/2019/03/01/bitcoin-sv-security-audit-helps-resolve-multiple-vulnerabilities-across-different-bitcoin-blockchains/">responsible disclosures</a> to the Bitcoin Core and Bitcoin Cash development teams and intend to continuing to do so as part of our commitment to professionalizing Bitcoin software development.



The Bitcoin SV team had been previously aware of variations of this attack vector and did in fact have a plan in place to mitigate it, in part involving a coalition of honest miners forcibly rejecting blocks that contain obvious theft attempts in order to protect the integrity of the chain. We note that this mechanism has subtle but important differences to an explicit consensus rule although has a similar effect. However, due to this public disclosure and explicit description of the method, we believe there is now a significantly higher risk of a dishonest miner attempting to execute this theft attack with a large amount of hashpower and consequently the economic cost to honest miners of implementing the proposed mitigation method is likely to be substantially higher as well. As such the Bitcoin SV team has determined that a stronger mitigation is now required.



We note for the record that Mr. Maxwell’s post did bring to our attention some aspects of this issue that the Bitcoin SV team had not yet fully considered.&nbsp; So we thank him for the technical review and shedding some new light on the matter. &nbsp;&nbsp;



In fact, this event demonstrates that the public review process implemented by the Bitcoin SV team, in advance of finalizing the code in early January, is achieving the intended goal of improving security outcomes for the ecosystem.



<h2>Mitigation</h2>



In response, the Bitcoin SV Node team will update the “Genesis” hard fork specification by upgrading the rule rejecting the P2SH script pattern from a policy rule to a consensus rule.&nbsp; That is the specific script template “OP_HASH160 &lt;hash&gt; OP_EQUAL” will not be allowed in new outputs and this rule will be directly implemented in the Bitcoin SV Node software.&nbsp; Whilst unfortunate to restrict the usage of a particular script pattern, we note that the same effect can be achieved using variations of the script pattern e.g. “OP_SHA256 OP_RIPEMD160 &lt;hash&gt; OP_EQUAL”.



This change closes the attack vector and mitigates the need for honest miners to forcibly reject blocks containing theft transactions.&nbsp; Whilst this could have triggered a valuable demonstration of the principle of honest miners acting punitively against dishonest miners, the public disclosure by Mr. Maxwell raises the potential cost to those miners to an unacceptable level.



<h3>Segwit script pattern</h3>



To address an additional but unrelated issue related to native Segwit transaction replay an additional measure will be taken. This will be detailed in a later post.



An update to the Genesis hard fork specification will be published shortly and the code changes included in the next beta release of Bitcoin SV.&nbsp; Release notification will occur through the usual channels noted here: <a href="https://bitcoinsv.io/genesis-hard-fork/">https://bitcoinsv.io/genesis-hard-fork/</a>



<h2>Bug Bounty</h2>



We take this opportunity to remind the security research community of the substantial <a href="https://bitcoinsv.io/security/">bug bounty program</a> offered by Bitcoin SV with a maximum reward of up to $100,000 USD (payable in BSV), rivalling the largest bug bounty programs in the world offered by multinational technology giants.



We offer a top-tier bug bounty program in order to encourage further scrutiny, review and responsible disclosures from all parties.&nbsp; Gregory Maxwell is of course eligible to participate so long as he adheres to principles of Responsible Disclosure in the future.

Bitcoin SV – Blocking potential P2SH replay attack after Genesis hard fork

On February 4, 2020, the Bitcoin SV network will undergo its “Genesis” hard forking upgrade.&nbsp; This hard fork represents a significant milestone in Bitcoin SV’s journey to restore the original Bitcoin protocol.&nbsp; To allow the Bitcoin SV ecosystem adequate time to prepare for the hard fork, the Bitcoin SV Node team would like to communicate the rollout and testing plan for the Genesis upgrade.&nbsp; The team has been hard at work for several months specifying and coding the changes required and will shortly be releasing a beta version of Bitcoin SV Node software that is compatible with the Genesis hard fork. To ensure a seamless upgrade and guide you through the Bitcoin SV hard fork we’ve created a dedicated technical support page containing all the information you might need: <a href="http://www.bitcoinsv.io/genesis">www.bitcoinsv.io/genesis</a>



<h3>Public Testnets</h3>



In preparation, two public testnets have been created.&nbsp; The first, “Genesis Testnet” or “GT”, is set to post-Genesis activation. That means all the changes due to activate on mainnet on February 4, 2020 will be already activated on this testnet.&nbsp; The second, “Genesis Reset” or “GR” will follow a 48 hour reset cycle beginning 24 hours before activation, activating Genesis, then continuing for a further 24 hours until being reset again.&nbsp; This will allow repeated testing of the transition that is due to occur on mainnet on February 4.&nbsp; Technical details for these testnets along with a support channel where you can reach members of the Bitcoin SV Node team are available at <a href="http://www.bitcoinsv.io/genesis#config" target="_blank" rel="noreferrer noopener">the Genesis Hard Fork Support Page</a>



<h3>Timeline of Events</h3>



We’d like to outline the timeline between now and February 4, 2020.&nbsp;



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2019/12/timeline_eng-1024x357.png" alt="" class="wp-image-3327"/></figure>



<h3>Beta Release and Testing – December 2019</h3>



Extensive QA testing of the beta software will already have been completed when the beta software is released.&nbsp; At this time, we recommend running this beta version ONLY on GT, GR, or on the Bitcoin SV <a href="https://bitcoinscaling.io/" target="_blank" rel="noreferrer noopener">Scaling Test Network (STN</a>).&nbsp; We DO NOT RECOMMEND running this beta version of the Bitcoin SV Node software on the production mainnet.



Over the next week, we anticipate publishing a fully detailed specification of all Genesis changes for public scrutiny.



Further functional testing by the Bitcoin SV QA team will then commence on the public test networks.&nbsp; We also encourage any users of Bitcoin SV to begin testing their own applications using the Bitcoin SV Node beta software, and to further participate in the testing of the Bitcoin SV Node itself.&nbsp; This applies to operators of mining nodes, in addition to “blockchain listeners” – wallets, exchanges, applications and others running instances of the Bitcoin SV Node software that do not write transactions to the blockchain.



During December, a second phase of security auditing of the code will also be completed, with phase one having been completed in November. &nbsp;Any identified issues will be fixed and incorporated into further beta releases.



Following the beta release, the Bitcoin SV Node team may make further beta releases if bugs are identified and further fixes put in place.&nbsp; We will be communicating any further beta releases via the <a href="http://www.bitcoinsv.io/genesis" target="_blank" rel="noreferrer noopener">Genesis Hard Fork Support Page</a>, but we also encourage you to join our <a href="https://t.me/joinchat/JB6ZzlUctDaG7DrEaNRR2A" target="_blank" rel="noreferrer noopener">Telegram Support Group</a> to get more real-time communication.&nbsp; It is important to stay up to date during this testing phase.



<h3>Stable Release – early January 2020</h3>



Pending the results of QA testing, the Bitcoin SV Node team will designate the most recent beta release “stable” no earlier than January 1,, 2020 and no later than 2nd week of January 2020.&nbsp; We anticipate achieving a stable release earlier than this, but out of caution, the QA team will insist on a minimum stable period to enable soak testing and give the highest level of confidence.&nbsp; At this point, we will recommend upgrading all nodes on the Bitcoin SV production network (mainnet) as soon as possible in preparation for the hard fork activation anticipated around 12pm GMT on February 4, 2020.



<h3>STN activation – January 21, 2020</h3>



The Scaling test network (STN) will activate the Genesis hard fork two weeks prior to mainnet on January 21, 2020 at block height 14896.



<h3>Hard Fork Activation – February 4, 2020</h3>



The time for activation of the Genesis hard fork cannot be guaranteed precisely. &nbsp;This is because the block height for the activation needs to be determined prior to the release of the first Bitcoin SV beta code. &nbsp;If the network happens to find blocks faster or slower than average in the intervening period, it will cause the activation block to be mined slightly earlier or later than the targeted time.&nbsp; The Bitcoin SV Node team will be monitoring the progress of the network and will provide updates to the expected activation time as we approach February 4, 2020. The Genesis hard fork will activate on mainnet at block height 620538.



We are excited to deliver the Genesis hard fork to Bitcoin SV, and bring Bitcoin back closely to its original protocol and Satoshi Vision.

Bitcoin SV Genesis hard fork implementation plan – in advance of February 4, 2020

<h2>New transaction fee toolsets coming to Bitcoin SV</h2>



TLDR;



<ul><li>Cheaper transaction fees, fiat stable pricing and a highly flexible framework for dynamic fee rate discovery are all on the horizon for Bitcoin SV.</li></ul>



Since a recent price rise of BSV in fiat terms and the announcement of WeatherSV’s transaction fee deal directly with a mining pool (Mempool), the subject of transaction fees has become a hot topic in the Bitcoin SV space &nbsp;&nbsp;It’s an important topic to think through as BSV finally unlocks Bitcoin’s massive scaling capability and has opened the door to new business models for use of the blockchain to record large and continuous volumes of data.&nbsp; Transaction fees on Bitcoin SV are still far less than on competing blockchains (especially BTC and Ethereum), but we can do more to ensure that fees are reliably low, so applications can properly plan their business models while miners are also economically agile.



I’ve discussed this issue with several mining groups and many Bitcoin app developers. There are some common themes and opinions about future direction along with a general consensus that the toolset we inherited from BTC and BCH-ABC for managing transaction fee rates is clunky and inflexible.&nbsp;



We’ll begin by examining the common concerns among both users and miners of Bitcoin SV. Then we’ll survey the current state of play and what’s possible with the existing transaction fee toolset before turning our attention to where that toolset is heading on BSV.&nbsp; Finally we will consider what can be done between now and when it is fully available.



<h2>Concerns</h2>



<h4>Lack of fee discovery</h4>



It is astonishing that after 10 years, Bitcoin wallets still have no way to reliably determine what fees are required to get a transaction mined.&nbsp; Most rely on complex and unreliable mechanisms.&nbsp; This is partially a consequence of the Bitcoin Core model of a fee market where miners are price takers rather than price makers.&nbsp; Bitcoin SV turns this model on its head so there’s no excuse for miners not to be able to provide definitive fee quotes barring an implementation.



<h4>Price too high</h4>



The current fee rate is inherited from the default in the Bitcoin ABC implementation for BCH.&nbsp; It is denominated in satoshis per byte and currently equates to about $1.20 USD per MB. There is no particular reason for this price level and it appears to be widely agreed among the BSV ecosystem that rate is currently too high for data transactions (as compared to payment transactions).



<h4>Fiat stability</h4>



When you build a business model based on an operational cost of X and the volatile BSV market makes that price jump to 2X overnight, it’s very hard to make safe predictions about the viability of your business.&nbsp; Fiat stable pricing, e.g. $0.XX per MB, is something we’ve heard many enquiries about from businesses seeking certainty.



<h4>We don’t know the floor</h4>



No one really knows what the cost of processing a transaction is. It is very hard to model this as the inputs to the model are highly variable and some require guesses at future transaction volume.&nbsp; There are variable costs like cost/MB-bandwidth-use that are relatively proportional to the amount of transactions; that’s the easy part. The harder part are the fixed costs that must be amortised over many transactions without knowing exactly how many.&nbsp; There is some work beginning by some of the miners to start building these models and understanding the zones of risk.&nbsp; But it is only just beginning now because it’s only just started to matter.&nbsp; Until this is better understood I predict there will be some reluctance by miners to lower costs in an extreme manner because it is much harder to ask the market to bear a later increase than is to continually lower prices until the floor is found naturally.



<h4>Disparities in data value</h4>



Suffice to say, some data is worth more than other data from a miner’s point of view. We’ll address this further in the next section.



<h2>The current state of play</h2>



Right now miners have only two manual configuration options in Bitcoin SV to manage fees and changing either requires a restart of the node.&nbsp; These form the “transaction fee toolset” currently available to BSV miners:



<ul><li>There is the “actual fee rate” that miners accept to mine a transaction denominated in sats/byte.&nbsp;</li><li>There is an additional option “minrelaytxfee” which should be lower and is the fee rate required for a miner to even bother validating a transaction and subsequently relaying it to peers.&nbsp;</li></ul>



To my knowledge almost all miners currently use the default settings which are both set to 1 sat/byte.&nbsp; However, it is actually important for a safe 0-conf fee market to emerge that minrelaytxfee is set lower by some margin than the actual fee rate, so for the purposes of this discussion we will assume that the default minrelaytxfee is actually 0.5 sats/byte. The existence of this range of fee rates is important to enable room for miners to be competitive whilst still protecting the “first see rule” that is a fundamental pillar of 0-conf security. I have referenced the idea of a “secondary mempool” in many of my public presentations that is for miners to keep some transactions for double spend protection even if they don’t intend to mine them.&nbsp; There is a lower bound to the fee rate where this protection kicks in simply to discourage the excessive use of zero fee transactions.&nbsp;



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2019/11/tx-fee-scale-1024x293.png" alt="" class="wp-image-3065"/><figcaption>Relation between transaction properties and miner fee rates</figcaption></figure>



To illustrate the use of this range, let’s assume that all miners except one use the defaults and that one “exception miner” accepts a fee rate of 0.8 sats/byte.&nbsp; If confirmation time is not important to you, you might use this fee rate; the “majority miners” will accept the transaction into the mempool and refuse to allow it to be double spent because the fee is higher than 0.5 sats/byte, but because it is below the one 1 sat/byte fee rate that all the majority miners are using, only the one exception miner will try to mine it into a block so likely you’ll have to wait many blocks for it to be mined.&nbsp;



Let’s try a second scenario where one exception miner uses a fee rate of 0.3 sats/byte.&nbsp; This is below the 0.5 sats/byte threshold so the majority miners will not even accept or relay it let alone mine it.&nbsp; In this case most miners have forgotten the transaction and cannot do a double spend check in order to respect the first seen rule.&nbsp; For some use cases this might be ok (e.g. WeatherSV since they won’t double spend themselves).



With these examples along with the diagram above we can clearly see four distinct classes of transaction properties based on the chosen fee rate:



<ol><li>Offline, miners will ignore them. This can be useful if you consider that using CPFP you can later upgrade a transaction to one of the later classes</li><li>Slow to mine, no double spend protection</li><li>Slow to mine, full double spend protection</li><li>Fast to mine, full double spend protection.</li></ol>



These properties have progressively higher value dependant on use case and you should be able to select what is most appropriate for your situation.&nbsp; And in fact some of those properties are not just black and white.&nbsp; E.g. time to mine can be improved by choosing a fee rate that will satisfy xx% of miners without choosing the highest fee rate.



What this highlights is that not all transactions are created equal, and it would be nice if miners could compete on each class or specialize in some.&nbsp; But right now there is only one fee rate for everything.



So back to the current transaction fee toolset currently available. These two settings are buried inside the Bitcoin SV Node software itself.&nbsp; That means if you want to modify how they work you have to modify the node code.&nbsp; Because the node code handles some other very sensitive parts of the Bitcoin network, our Bitcoin SV Node team has very onerous QA processes and few other people are willing to risk touching it.&nbsp; The consequence is that changes to these mechanisms are slow and complex to implement and can only be implemented by one team (unless you want the overhead of maintaining a full Bitcoin codebase).&nbsp; This is the opposite of what is needed to enable multiple players to dynamically implement new mechanisms and engage in a real-time process of price floor discovery.&nbsp; I’m going to drop a controversial word here and say that Bitcoin needs a fee market.&nbsp; But unlike Bitcoin Core we aren’t using a market to discover how high transactions fees can be, we are using it to discover how low they can go.



A further issue with this setup is that the general public doesn’t have any visibility into these settings.&nbsp; So the actual price that miners are asking is unknown to the people who need to set the transactions fees in the transactions they create. There are all sorts of horrible fee estimation algorithms out there that we inherited from Bitcoin Core but they rarely give the best price, no assurance that you’ll even get it high enough and give you no visibility of what fee rate will actually provide 0-conf safety.&nbsp; We are currently saved from the disaster this could become by virtue of the fact that almost all miners currently use the defaults.&nbsp; This works until miners start changing them which they will likely do very soon.



Lastly, there is the lack of granularity.&nbsp; There is no mechanism to price different types of transactions at different rates.&nbsp; Data bytes cost less to process than ECDSA signatures but miners cannot reflect that in the current pricing model. Some types of data might be worth more from a miner’s point of view than others. For example, it could be argued that weather data is more valuable than pictures of someone’s cat as the weather data is a public utility that enhances the value of the blockchain as a data store.



<h2>Near future tools</h2>



For Bitcoin SV, there are three tools in the pipeline directly applicable to most of these concerns around transaction fees.&nbsp; The second might make the first one redundant but it illustrates one of the points above.



<ol><li>The ability for miners to price data bytes differently to the rest of the bytes in a transaction.</li><li>Moving the fee evaluation function OUT of the Bitcoin SV Node software.</li><li>Providing a fee discovery mechanism to end users</li></ol>



Change 1 is a change to the Bitcoin SV code that has been in pipeline for quite some time and will likely make it to release around Feb 2020.&nbsp; Its function will be easily replicated by change 2.&nbsp; Along its journey through the change pipeline it has dealt with competing priorities (e.g. the Genesis hard fork) and only being worked on by the Bitcoin SV team due to the myriad complexities of it being embedded in that code. This alone is a great justification for change 2.



Change 2 will have its first implementation in our planned Merchant API but it requires a change in the Bitcoin SV Node to open up a gateway.&nbsp; In essence, the Bitcoin SV Node needs a mechanism to accept transactions from a trusted source and because that source is trusted it will not check fee policies, rather it will just check the transaction is valid and append it to a block.&nbsp; This means delegating fee evaluation to an external module.&nbsp; There can be many implementations of these and anyone can build and maintain one without having to touch the Bitcoin SV code. The requirements for such a module are quite small so a project like this is not terribly onerous.



Change 3 is also a part of Merchant API but it doesn’t require changes to the node for its first iteration, so fee discovery will be available as a beta implementation in the coming weeks.



Let’s take Merchant API as an example of externalising fee evaluation, since it already has the facility to provide fee quotes to users and accept transactions it is a logical place to perform fee evaluation.&nbsp; It is embodied as a REST API which every developer on Earth knows how to use.&nbsp; So consider a few possibilities of what it might be able to do:



<ul><li>User based fee policies – public connections might be offered one fee rate whilst authenticated users might offered fees based on their particular contractual arrangements.</li><li>FeeQuote mechanism enables rapid changes to fee policies whilst users remain fully informed.</li><li>Lower pricing for data bytes compared to signature bytes.</li><li>That ability makes fiat stable pricing possible, fees can be updated daily or hourly to ensure they cost the same amount in USD rather than floating with the BSV price.</li><li>Per protocol pricing – Using the widely adopted OP_RETURN protocol_id standard to price different protocols according to their perceived utility e.g. plaintext data available to all users may be cheaper than encrypted data accessible to only one.</li><li>Volume discounts for bulk submission.</li><li>Out of band payment – “Hi Amazon, for $X/month payed with your credit card we’ll take care of getting all your transactions mined”.</li></ul>



The range of possibilities is endless when this functionality is pushed into the hands of miners and payment processors. The fee quote mechanism has been designed to very flexible going far beyond the traditional “satoshis per byte” mechanism we have today.



Merchant API and its companion tool, Miner ID, are beginning private beta testing over the next couple of weeks and we’d expect to make the endpoints public early in 2020.



<h2>Interim measures</h2>



But can we do something right now with the blunt instruments we currently have at our disposal?&nbsp; The answer is probably yes. From the discussions I’ve had with many actors (including miners) around the ecosystem there are clearly a couple of common themes:



<ol><li>There is a strong appetite to cut transaction fees significantly in the near term.</li><li>It is widely recognised that volatile pricing in fiat terms needs to be addressed to provide operational cost stability to businesses using Bitcoin SV so whatever solution is presented for the first point will probably be accompanied by a periodic review of pricing to keep them relatively stable in USD equivalent until automated mechanisms are enabled.</li></ol>



I think it’s reasonably safe to say these changes are imminent, it’s only a question of when and by how much.&nbsp; But what is probably important to note is that Bitcoin SV is already cheapest of all major blockhains to transact upon for real utility, both in satoshis and in fiat terms, any cut will send a clear signal to the market the cost of using Bitcoin SV is going in only one direction, down. &nbsp;This is only economically possible because the future of Bitcoin SV is to massively scale.



We’re just now experiencing how Bitcoin’s economic system should have played out for many years before. It will take the BSV ecosystem some time to adjust to this new reality, but we will do so by developing flexible new transaction fee toolsets and constructive business approaches.&nbsp; These steps will ensure a healthy and long-lasting transaction fee market that that is flexible and meets the economics needs of both application builders and miners.

On the future of Bitcoin transaction fees

In recent days there have been a couple of articles which incorrectly suggest that the Bitcoin SV Blockchain has suffered from a “three-way fork” over the last few weeks. These articles seem to stem from the same source, a tweet from BitMEX Research. Here are the facts.&nbsp;



The Bitcoin SV Blockchain had a planned hard-fork upgrade on 24th July. This upgrade increased the maximum block size from 128MB to 2GB. Unfortunately, despite publicity and announcements over a two month period, a minority of node operators did not update their software. These nodes, that had not updated their software, forked onto a new and incorrect chain after the upgrade. This is a natural consequence of how Bitcoin works: if the software is not aligned with the majority, it will create a “fork” in the blockchain.&nbsp;



Shortly after the hard-fork, several 256MB blocks were produced on the Bitcoin SV Blockchain. The size of these blocks caused some minor issues for some service providers. These issues were resolved quickly by the service providers.&nbsp;



Ten days later, on 3rd August, a member of the Chinese Bitcoin SV community initiated their own stress test on the Bitcoin SV Blockchain. Over 2 million payment transactions were blasted onto the Bitcoin SV network over a short period which resulted in two large blocks: a <a rel="noreferrer noopener" href="https://whatsonchain.com/block-height/593965" target="_blank">210MB block</a> containing 808,633 transactions, and a <a rel="noreferrer noopener" href="https://whatsonchain.com/block-height/593967" target="_blank">183MB block</a> containing 702,999 transactions. Unfortunately, some of the nodes on the Bitcoin SV network were running on small systems that were unable to cope with this flood of transactions. These systems failed. They did not create a third fork, they simply stopped working.&nbsp;



These are the facts. There was no “three-way fork”. There was a single fork in the blockchain on July 24th due to out-of-date software, a normal occurrence that affects all blockchains that use Nakamoto consensus. Ten days later, there was a group of nodes that failed because they were using sub-standard equipment and could not keep up with volume of transactions that Bitcoin SV is designed to accommodate.&nbsp;&nbsp;



The Bitcoin SV blockchain functioned as normal, and continues to function as normal, reliably processing huge numbers of transactions. Bitcoin SV is evolving and professionalizing Bitcoin, moving Bitcoin from a prototype supported by hobbyists to a professionally supported system capable of meeting global demand for an immutable blockchain. Inevitably, this does mean that the requirements for systems which participate in the network will increase. The Bitcoin SV Node implementation team has recently published <a rel="noreferrer noopener" href="https://bitcoinsv.io/2019/08/02/bitcoin-sv-node-system-requirements/" target="_blank">recommended system requirements</a> and we strongly urge node operators to follow these recommendations.&nbsp;



Daniel Connolly

The Bitcoin SV Blockchain & False Reports of a “Three-way Fork”

OP_RETURN is well known as the simplest mechanism for creating an unspendable output and carrying data within a bitcoin transaction.&nbsp; It’s had a checkered history with being the root cause of one of the worst bugs in Bitcoin’s history and arguably also being a political football that led to the beginning of the great altcoin diaspora.&nbsp; It is a far more important piece of the Bitcoin puzzle than is commonly understood though.&nbsp; It’s current usage is a subset of it’s potential and it’s also kind of wrong.&nbsp; Lets take a look at the history.



<h2>The original OP_RETURN</h2>



In the beginning the execution of scripts worked slightly differently than it does now.&nbsp; In some respects more primitive. In others more in line with the original intent.&nbsp; There are actually two scripts involved in the authorization of spending a UTXO.&nbsp; The locking script (also known as scriptPubkey) which is designated at the time a new bitcoin output is created.&nbsp; And the unlocking script (also known as scriptSig) which is provided at the time of spending the output (to create yet another new output).&nbsp; First the unlocking script is executed, then the stack(s) that are a result of that are fed as input to the locking script. Think of the locking script as a puzzle and the unlocking script as the solution to the puzzle. If you can solve the puzzle you are authorized to spend the Bitcoin.



In the original BitCoin this was achieved with the help of another op code OP_CODESEPERATOR.&nbsp; This op code limits the scope of what subsequent OP_CHECKSIG operation will cover during a signature check&nbsp; i.e. which parts of the transaction the signature signs.&nbsp; This is necessary because usually there is a signature in the unlocking script and an OP_CHECKSIG in the locking script.&nbsp; And the signature can’t sign itself without creating a paradox and probably ending the universe as we know it.&nbsp; What would happen is the two scripts were taken and turned into a single script a bit like this:



<pre class="wp-block-preformatted">Concatenate( unlockingScript | OP_CODESEPERATOR | lockingScript )</pre>



The single script was then executed.



<h2>I can haz all your Bitcoinz</h2>



There was a glaring bug in this arrangement. What determines if the ‘puzzle’ has been successfully solved is that if at the end of script execution 1) it hasn’t failed with an error and 2) that the top item remaining on the stack can be interpreted as a valid Boolean ‘true’.&nbsp; OP_RETURN didn’t change this.&nbsp; It simply exited the script early and the above check was done to determine if the script was spendable. But it neglected to distinguish between the locking script which is set in stone once in the UTXO at the (earlier) time when the output is created, and the unlocking script which anyone can create in an attempt to spend the coin.&nbsp; Consider the following locking script:



<pre class="wp-block-preformatted">&lt;public_key&gt; OP_CHECKSIG</pre>



This is the original pay-to-public-key script template.&nbsp; It *should* only be able to be unlocked by providing a valid signature, which you should only be able to provide if you have the private key that corresponds to the public key.&nbsp; In the original version of Bitcoin what’s executed looks like this:



<pre class="wp-block-preformatted">Concatenate( &lt;signature&gt; | OP_CODESEPERATOR | &lt;public_key&gt; OP_CHECKSIG )</pre>



This would work fine as long as the signature is valid but you could also do this:



<pre class="wp-block-preformatted">Concatenate( OP_TRUE OP_RETURN | OP_CODESEPERATOR | &lt;public_key&gt; OP_CHECKSIG )</pre>



This pushes true onto the stack then exits the script.&nbsp; The signature check is never performed and the script is considered valid because the top stack item is a Boolean ‘true’.&nbsp; In fact it doesn’t matter what the locking script is.&nbsp; This behavior could be exploited to spend any bitcoin at all.



Satoshi noticed this and fixed it. But he did it in a rush. The fix was to make OP_RETURN always exit and FAIL the script.&nbsp; The reason for this is likely in way the code was structured at the&nbsp;time.&nbsp; A better fix would have been to disallow OP_RETURN in the unlocking script.&nbsp; Or ensure it always exits and fails if found in the unlocking script but behaves normally if found in the locking script.&nbsp; The problem is that by concatenating the scripts there was no simple way for the script interpreter to know which part it was in.&nbsp; OP_CODESEPERATOR is a valid op code that can be used anywhere in locking or unlocking scripts.&nbsp; It can be used multiple times even.&nbsp; So encountering that op code isn’t a definite marker of the transition from unlocking to locking script.&nbsp; There are other ways it could have been done but they introduce complexity and I suspect Satoshi was in a bit of a hurry to roll out a fix before this vulnerability got exploited.



<h2>The data carrier</h2>



Roll forward in time and the way the script interpreter was called changed a bit.&nbsp; First lets point out there is not just one stack in script, there are three.&nbsp; The main stack, the alt stack and the “if” stack which is used to determine whether conditional branches in code are executed or not.&nbsp; In the original implementation, because it was a single execution of the engine, all three of the resultant stacks from unlocking script were passed onto the locking script.&nbsp; These days both scripts are executed separately with just the main stack contents from unlocking script being passed onto the locking script.&nbsp; The function of OP_CODESEPERATOR is now subsumed by the semantics of the script execution engine so it has fallen into disuse although that is not to say it isn’t useful in other ways, but that’s a whole other story.&nbsp; This is a significant change in semantics.



The now nerfed OP_RETURN was noted for one of its potential use cases which is to make an output provably unspendable.&nbsp; It’s behaviour is now hard coded, if it is found and executed the script fails no matter what.&nbsp; This was considered a useful property since miners will never need it for validating a future transaction they can optionally prune it.&nbsp; So it was a useful way of embedding data in the blockchain in way that proved its existence at a point in time but without imposing a long term storage burden on miners. We still use it that way today.&nbsp; It is not the only means of storing data in the blockchain and arguably not even the best.&nbsp; But it is now a common use case on Bitcoin SV.



<h2>To fix it we have to break it</h2>



That’s right.&nbsp; The way we are all using OP_RETURN right now is going to get broken if we fix OP_RETURN.&nbsp; But don’t worry too much, it’s an easy fix and we can start right now. Almost all usages of OP_RETURN look a bit like this:



<pre class="wp-block-preformatted">OP_RETURN &lt;data&gt;</pre>



And most have a value of zero so nothing is at risk.&nbsp; But this form of OP_RETURN script will become spendable (by anyone) when the original functionality is restored.&nbsp; Not for existing OP_RETURN outputs (please see <a href="https://bitcoinsv.io/2019/07/26/utxo-height-based-activation-roadmap-to-genesis-part-3/">part 3 of this series</a> for an explanation of UTXO height based activation).&nbsp; But for new ones.&nbsp; Consider the above script with an unlocking script that ends with OP_TRUE:



<pre class="wp-block-preformatted">OP_TRUE | OP_RETURN &lt;data&gt;</pre>



As you can see anyone could spend this.&nbsp; Whether that matters or not a point for others to debate but it is not the behavior we currently assume and expect.



<h2>The call to action</h2>



If you’re an app developer making use of OP_RETURN there is something very simple you can do right now that will ensure your app will maintain consistent behavior both now and after the Genesis upgrade.&nbsp; Instead of starting your script with OP_RETURN, start it with OP_FALSE OP_RETURN.&nbsp; A locking script that contains this will always fail when it hits this sequence of op codes both now and after the Genesis upgrade.&nbsp; Here’s an example of the how the same technique we showed above would look with this op code pattern:



<pre class="wp-block-preformatted">OP_TRUE | OP_FALSE OP_RETURN</pre>



As we can see the top stack item is OP_FALSE so when we encounter OP_RETURN and exit the script we will look at the top stack item, see that it is not a Boolean ‘true’ and the script will be deemed to have failed just like an old school OP_RETURN transaction.



Bitcoin SV v0.2.1 released on 12th July 2019 contains a change to recognize this op code pattern as a standard transaction.&nbsp; So once the majority of nodes are upgraded to this version there should be no functional difference to your app.&nbsp; Additionally this version also sets the data carrier size default to 100kb so transmission of data carrier transactions will become a lot easier and more reliable.



<h2>But what about my old OP_RETURN outputs?</h2>



I mentioned earlier that this won’t be a problem for existing outputs.&nbsp; I have written <a href="https://bitcoinsv.io/2019/07/26/utxo-height-based-activation-roadmap-to-genesis-part-3/">a separate article</a> to explain UTXO height based activation as it is a mechanism we will be using for several changes required in the Genesis upgrade.&nbsp; You can read it <a href="https://bitcoinsv.io/2019/07/26/utxo-height-based-activation-roadmap-to-genesis-part-3/">HERE</a> but the TLDR is that no your old OP_RETURN transactions will behave the same way they always did.



<h2>Get on it</h2>



The above section was titled ‘call to action’ and that’s exactly what this article is.&nbsp; You can change your code right now because OP_FALSE OP_RETURN behaves functionally identical to a simple OP_RETURN on its own right now.&nbsp; The sooner your app supports this the sooner you can forget about it.&nbsp; The behavior of this script type won’t change after the upgrade.&nbsp; So please update your software ASAP.&nbsp; We are now 7 month out from the return to Genesis.&nbsp; There is a lot of work to do both in the Bitcoin SV as well as in the wallet and app ecosystem.&nbsp; We can knock this one off now so we can focus on the other stuff later.



Steve Shadders

The return of OP_RETURN – roadmap to Genesis part 4

Unfuckening is a very tricky business.&nbsp; There is a lot that got fucked in ten long years and some things are so badly broken that they simply can’t be unbroken cleanly.&nbsp; The Bitcoin SV team has done an enormous amount of research, studying the existing and the original code extensively and it’s been a really steep learning curve.&nbsp; But we are feeling pretty confident in the roadmap we need to implement now.&nbsp; There are some pragmatic caveats though.



Let me give you one example.&nbsp; Arithmetic op codes.&nbsp; The original BitCoin used a number implementation that allowed numbers of arbitrary size.&nbsp; That is, it wasn’t restricted to 32 or 64 bit numbers like many systems are.&nbsp; 256 bit (and larger) numbers, which are really useful for cryptographic functions, were also able to be used.&nbsp; Quite early in Bitcoin’s history this was changed and restricted to 32 bit numbers along with the introduction of the horrific CScriptnum class.&nbsp; The removal of capability to do crypto math directly in script (without huge overhead) was a great loss to Bitcoin and it’s something we will unfuck next February. But the question is how?



<h2>The solution to many problems</h2>



Our next roadmap article will describe the upcoming changes to OP_RETURN because this is a change we want the Bitcoin ecosystem to be aware of as far in advance as possible.&nbsp; The mechanism of that change is what this post is about and the reason we explain it separately is because it is a concept we will be reusing in many ways.&nbsp; I could have incorporated it into the next post but it’s a subject that will come up over and over again so it’s worth giving it’s own post…



<h2>The golden rule of Bitcoin</h2>



Converting an arithmetic system in a backward compatible way is a tricky thing to do with certainty. We can build tests until we are blue in the face but how will be sure we’ve covered every single edge case?&nbsp; Is it even possible to ensure all cases CAN be backward compatible?&nbsp; We don’t know.&nbsp; But we certainly care because one of the rules we live and breathe by in Bitcoin, the GOLDEN rule, is never make a spendable Bitcoin unspendable.&nbsp; NEVER.&nbsp; Not even by accident.



<h2>Thanks P2SH</h2>



If you look at the history of Bitcoin this problem may not be as big as we think it is.&nbsp; There are less than 100 transactions in bitcoin history that actually use arithmetic op codes – that we can see.&nbsp; So couldn’t we just write tests to make sure all of those are spendable?&nbsp; Possibly (not in all cases though) but the bigger problem is pay to script hash transactions.&nbsp; P2SH has the interesting property that the content of the output script does not become visible on the blockchain until the time it is spent.&nbsp; That is in stark contrast to the original design where the locking script had to be posted publicly in the blockchain when it’s created.&nbsp; This causes some difficulty in respecting the ‘never make a spendable bitcoin unspendable’ principle.&nbsp; Because we cannot assume what is in P2SH scripts.&nbsp; We HAVE to assume that some of them contain arithmetic op codes and as such to be sure we need to write tests for every single possible usage and edge case to ensure backward compatibility.&nbsp; Many of those edge cases will not exist, in fact likely most.&nbsp; But we have no way of knowing which so we have no choice but to test for them all.



As I said earlier this is hard, maybe impossible to provably do.



<h2>Sidestepping the problem</h2>



The simple way around this is a principle that is in fact useful to us for many features beyond just the specific case of arithmetic op codes.&nbsp; Don’t even try to be backward compatible.&nbsp; We simply accept that a part of Bitcoin’s history has some broken stuff in it.&nbsp; We continue to support it with the view that one day, eventually, all of those broken outputs will be spent.&nbsp; Maybe that’s decades away but in time we will be able to deprecate the old code.



But how do we fix it if we keep supporting the old rules?&nbsp; Simple, we implement the new rules as of a certain point in time.&nbsp; Everything after that follows the new rules.&nbsp; Everything before follows the old rules.&nbsp; Most Bitcoin consensus changes use what we call ‘height based activation’.&nbsp; That is after the blockchain reaches a certain block height the new rules kick in.&nbsp; But this potentially breaks old transactions that follow the old rules.&nbsp; That imposes a huge burden on developers of a new change that effectively locks them into a set of restrictions that would look very much like what Bitcoin Core have previously called a “soft fork”.&nbsp; Soft forks are for numpties and we aren’t going to buy into that because they are unnecessarily restrictive when you’re trying to undo 10 years worth of damage.



So instead of just blanket implementing the new rules we make them conditional not on the current block height, but on the block height at the time the script was created.&nbsp; More specifically the block height at which the input UTXO you are trying to spend was mined into a block.&nbsp; This a very flexible activation mechanism.&nbsp; It means that all outputs created with arithmetic op codes will continue to be executed using the code that existed at the time they were created.&nbsp; If they were valid then, they are valid for all time regardless of which rule set they were designed for.&nbsp; Fortunately there isn’t a lot of tooling changes required for this in the ecosystem since arithmetic op codes are rarely used.&nbsp; But it is not the only change we plan to activate in this way. Pay to script hash itself will be deprecated this way.&nbsp; Old P2SH outputs will still be able to be spent using the P2SH semantics but after the sunset date (4th Feb 2020) new ones will be invalid (strictly speaking they will actually become a hash puzzle but that’s another story).&nbsp; These are two examples of how we will use UTXO height based activation to ensure a smooth and fully backward compatible pathway back to Genesis.

UTXO height based activation – Roadmap to Genesis part 3

On the 24th of July 2019 the Bitcoin SV will undergo a forking protocol upgrade.&nbsp; This upgrade has very limited scope with just changing the block size hard cap but it warrants some further explanation.&nbsp; It was first detailed in <a href="https://bitcoinsv.io/2019/04/17/the-roadmap-to-genesis-part-1/" target="_blank" rel="noreferrer noopener">part one of this post series</a>.



The first upgrade, code named “Quasar”, is proposed for Jul 24th 2019 and is primarily focused on scaling.&nbsp; At a protocol level the only change planned for this upgrade is a lifting of the default block size hard cap.&nbsp;&nbsp;We have previously signaled&nbsp;an intent to raise the cap to 512MB however after consultation with the Bitcoin Association (the owner of the Bitcoin SV project) and miners representing a significant majority of hash rate it has been decided that the Bitcoin SV software will implement a default of 2GB in July.&nbsp; Initially a majority of miner hash rate will manually set their hard cap down to 512MB.



<h2>Quick recap of caps</h2>



There are actually three block size caps to consider when thinking about how block size governance works in Bitcoin.&nbsp; I have previously only talked about two: soft cap and hard cap.&nbsp; But in this case it’s worth thinking about two different versions of the hard cap.



Soft cap: Is a miner specific setting that indicates that maximum sized block a specific node will try to mine.



Hard cap: Is the maximum sized block that a miner will accept as valid. This is the setting we intend to remove entirely in the Genesis upgrade next February.&nbsp; It is also the one we need to consider in two ways.



Firstly, there is the default setting.&nbsp; If you don’t manually set this value on a Bitcoin SV node it will use the default.&nbsp; The upcoming Quasar upgrade changes this default value from 128mb to 2gb or more specifically 2,000,000,000 bytes.



Secondly there is the setting that the majority of mining hashrate is using.&nbsp; In this case we have previously announced that a group of miners totaling a majority of hashrate have signaled their intent to manually set their hard cap to 512mb.



So let’s call these two cases the “default hard cap” and the “consensus hard cap” respectively.



<h2>Consensus is among miners</h2>



If you’ve ever heard the nonsense about how it’s important for other people (non-miners) to run fully validating nodes, you’re about to get a real life demonstration that this is simply not true.



We are not recommending that anyone but miners make manual changes to their hard caps.&nbsp; This is for the simple reason that it is easier to follow consensus if you don’t enforce a hard cap at all and if you can’t do that, the next best thing is to have a higher hard cap than the consensus hard cap.&nbsp; We will explain this in more detail later in this post.



<h2>Recommendations for miners</h2>



If you are a miner it is recommended that you set your hard cap to 512mb and that you set your soft cap to some lower value.&nbsp; In the Bitcoin SV software these are config parameters that actually have different names.&nbsp; By way of example I’ll give you the specific config parameters for a 512/256 cap configuration:



<pre class="wp-block-preformatted">Hard cap: -excessiveblocksize=512000000
Soft cap: -blockmaxsize=256000000</pre>



<h2>Recommendations for everyone else</h2>



By everyone else we mean people/businesses that are running an instance of Bitcoin SV that is not involved in mining.&nbsp; I call these “Blockchain listeners”.&nbsp; Miners write the blockchain, anyone else running Bitcoin SV is just listening to it.



For these we don’t recommend changing any of the above settings.&nbsp; Your default hard cap should remain at 2gb.&nbsp; If you do attempt to change it to match the miners there is a risk the miners will change the setting sometime between now and February next year (and you may not hear about it) and you will be permanently forked off the network until you notice and raise your own limit.



<h2>But what if there’s a bigger block than 512mb?</h2>



Fair question.&nbsp; Your node will accept that block initially then one of two thing will happen.



1/ If the miner that mined the larger block has a majority of hashrate then the chain will get longer and you’ll continue following the longest chain.&nbsp; The other miners will have to choose to either raise their limit and follow the longest chain or remain forked.&nbsp; I’d put my money on the former.



2/ If the miner that mined the larger block has minority hashrate then the bock will get orphaned and your Bitcoin SV instance will reorg back to the majority chain.



<h2>That sounds dangerous</h2>



Of course it does.&nbsp; We’ve all been told for 10 years that orphans are bad and a security risk. But it’s simply not the case, it’s actually how Bitcoin is supposed to work. I’ve addressed this point extensively <a href="https://www.yours.org/content/on-forks--orphans-and-reorgs-0c0c39d3c79b" target="_blank" rel="noreferrer noopener">here</a>.



<h2>Retraining Bitcoin</h2>



In the introduction we described the Quasar upgrade as being very limited in scope.&nbsp; That’s not entirely true.&nbsp; From a technical point of view the changes are limited but its role in the lead up to the Genesis upgrade is much more important that it may seem on the surface.



Some will no doubt ask “what if a malicious party mines blocks larger than 512mb just to cause trouble”.&nbsp; Well I hope they do because it will be the first real life demonstration of the power of Nakamoto consensus as a capacity governance tool.



This upgrade represents a very significant cultural shift for Bitcoin.&nbsp; By separating the default hard cap (developer chosen) from the consensus hard cap (miner chosen) we are diluting the power of the default setting which can only be set by a single group (us).&nbsp; This is a very active effort by the Bitcoin SV development team to push the responsibility for capacity consensus out of their own hands and into the hands of miners.&nbsp; The miners are now responsible for managing block size consensus and if they screw it up it will cost them.&nbsp; The final stage in that transition is removing the default altogether next year (or rather the default will be infinite).&nbsp; But we think it’s fair to give the miners time to get used their new role and we also need a bit more time to give them better tools to manage uncapped block sizes more safely.



Putting aside miners for a moment, there is another consideration.&nbsp; Operators of blockchain listeners are slowly getting used to the idea that they need to make peace with orphans and reorgs or at the least, if they can’t make peace with it, learn how manage in an environment where they are normalized.&nbsp; It’s not hard to do and we already have some of the tools to do it.&nbsp; But a reorg or two from time to time is a good reminder.&nbsp; This is another reason we are pushing businesses onto the STN.&nbsp; We want to break your services there.&nbsp; But reorgs don’t really break services they seem to cause more of a mental shock to people who’ve been listening to Core for too long.&nbsp; So if someone wants to mine 600mb blocks and try to cause some reorgs we’re pretty happy for that to happen.&nbsp; It will do two things, it will help people in the ecosystem get used to reorgs as normal events and Nakamoto consensus will ensure the event costs some miner dearly which is also a thing they need to get used to.



Bitcoin is a brutally Darwinian game.&nbsp; It is a reflection of the natural world in which some of the harsher realities are the very things that drive the strengthening of species and the global ecosystem that hosts them. Quasars are one the most brutal phenomena in nature and the Quasar upgrade is all about helping all Bitcoin participants to understand and adapt to those facts in preparation for the gloves coming off fully after the return to Genesis.



Steve Shadders

Quasar upgrade 24th July recommendations – roadmap to Genesis part 2

<figure class="wp-block-image size-full"><img loading="lazy" width="1024" height="349" src="https://theoffgrid.net/wp-content/uploads/2022/04/Satoshi-scale-ceiling-1-1024x349-1.png" alt="" class="wp-image-921" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/Satoshi-scale-ceiling-1-1024x349-1.png 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/Satoshi-scale-ceiling-1-1024x349-1-300x102.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/Satoshi-scale-ceiling-1-1024x349-1-768x262.png 768w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



<h2>Background</h2>



On May 21st 2019 the Bitcoin SV Scaling Test Network (STN) saw its maximum mined block size record broken eight times in rapid succession. In the <a href="https://github.com/bitcoin-sv/bitcoin-sv/blob/master/doc/release-notes.md">latest release</a> of Bitcoin SV Node (0.2.0) one of the standout changes was lifting the hard cap block size limit from 128MB to 10GB. The reason for setting the cap so far in excess of mainnet is the stated intention of STN, which is to push the limits of Bitcoin SV software to breaking point so we can identify those breaking points well in advance. &nbsp;The STN capacity is always intended to be several months ahead of mainnet.



<h2>Test plan</h2>



The SV node team had been hard at work on scaling improvements to the node, which is a requirement if we are to safely provide a 2GB cap in July on mainnet. As such the team called on the STN to show us how those improvements have affected capacity. &nbsp;The stress test set out with a modest goal of increasing the softcap to 200MB, then, if all went well, continue increasing by 200MB increments until we reached 1GB or until a natural limit in the software was encountered. A mixture of small payment transaction and big data transactions was used in varying proportions as the goal was not simply test and gather data on transaction throughput but to observe the effect on bitcoind and other services of large data transactions pushing block sizes to extremes. &nbsp;It is already known to us that transaction counts are more of a constraint than pure block size but due to the previous limits (128mb) it has been impossible to test raw block size capacity.



One of the first challenges when talking about scaling Bitcoin to 1GB is mining itself. &nbsp;The old GetBlockTemplace mechanism doesn’t scale well at all. This is where a new mining api comes into play. Put simply, it allows miners to mine without sending every transaction over the RPC connection between Node and miner. 0.2.0 was our first official release with this API and the result was a complete decoupling of mining pool load from block size.



<h2>Results</h2>



With that problem solved and multiple other improvements to the node software, 200MB was reached comfortably as expected. &nbsp;So the team began incrementing the cap in successive cycles. The end result was better than hoped for, after seeing how robustly 0.2.0 handled 1GB the decision was taken to push past the initial target. The test ended with a 1.424GB block containing 359,793 transactions. &nbsp;At this point some degradation of services like block explorers was observed. &nbsp;The Bitcoin SV nodes handled things ok and probably could have been pushed further but the Stresstest team and the nChain team both needed some sleep.



The following table shows some of the more notable blocks from the test period:



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2019/05/block-table-ascending.png" alt="" class="wp-image-2849"/></figure>



As can be seen, consecutive big blocks were common any not posing any real issue at all.



We did observe degradation of some services, in particular the block explorers had a little trouble in the beginning when blocks started breaking the 400MB barrier. However, with a little communication and some sharing of IP’s they all managed to get caught up and from what we saw, all were operational throughout the process after this.



Some real world effects of the Great firewall of China were also noted. A user participating in the STN had their node fall behind the chain, this was due to bandwidth restrictions with their service as a result, we have begun looking at ways to improve our connectivity in China for the STN (We already do this for mainnet).



We now have a mountain of data to comb through and analyse, looking for more ways to improve, more ways to be reliable, more ways to ensure that when mainnet reaches these levels it is boring. So boring you don’t notice. Boring means its reliable, boring means it can be built on. Boring is good.



The Bitcoin SV team would like thank Esthon Medeiros from the Satoshi Shotgun team who has worked tirelessly to ensure we can blast just about any size and combination of block or transaction volume as required into the p2p network, on demand.

First gigabyte+ blocks mined in STN stress test

The Bitcoin SV Scaling Test Network (STN) is an initiative of the Bitcoin SV Node project, owned by <a href="https://bitcoinassociation.net/">Bitcoin Association</a> and operated by <a href="https://nchain.com/en/">nChain</a> (with funding by <a href="https://coingeek.com/">CoinGeek</a>) to scale and test Bitcoin beyond gigabyte and eventually to terabyte blocks. In February 2019, the Bitcoin SV team publicly released client software with full support for the STN making it available to all. We have since been working on building robust ancillary services on the STN to make it easier to work as well as a more accurate representation of the mainnet. The network has since been used extensively by the BSV Node team to conduct research as well as to test the limits of the Bitcoin SV Node software under various conditions.&nbsp; Now that we have built a solid base, it is time to cast the net wider.



We invite and actively encourage Bitcoin developers and business alike to join the STN, to run their apps and services alongside their production environments. Working closely with Esthon Medeiros and the Satoshi Shotgun team, the STN has a continuous and varying supply of transaction traffic and your service will be continuously battle tested with a constant cycle of load profile conditions.&nbsp; In addition to the benefits of learning the performance bottlenecks of your app or service early and being able to rectify them before those loads are reached in production, the presence of your service on the STN can be used to give your clients assurance that it is keeping up with the scaling requirements.&nbsp; To that effect, we plan later this year to create an STN Certification program that will enable a service to claim independent certification of its resilience to specific network load profiles.



We are building out further support infrastructure for the STN, the beginnings of this were launched with <a href="https://bitcoinscaling.io">bitcoinscaling.io</a>. This includes a dedicated support team behind the STN, who will be eager to assist with any questions from the builders and innovators in the space, breaking new ground on what is known about what Bitcoin can do.



In order to the ensure STN is adequately resourced, the Bitcoin SV Node team has appointed Brad Kristensen (a.k.a @brad1121) to the role of STN Operations Manager.&nbsp; Brad’s role will be to further develop the support infrastructure behind the STN and to ensure smooth running of the network.&nbsp; He will also be tasked with providing support channels for businesses and developers that need assistance with getting an instance of their application running on the STN.&nbsp; Brad has a long history with Bitcoin including mining as far back as the GPU era as well as being a senior developer with nChain who works very closely with the Bitcoin SV node team.&nbsp; He is a natural fit as a liaison between STN users and the Bitcoin SV dev team.



In the coming months, we plan to increase the maximum block size of the STN to 10GB. We are moving past the era of filling up blocks and stepping into the realm of boundless growth. Our goal is not to push the limits, but to prove there are no limits.



To get involved, head to <a href="https://bitcoinscaling.io/">https://bitcoinscaling.io/</a> or get in touch via <a href="mailto:stn@bitcoinsv.io">stn@bitcoinsv.io</a> to join the STN and work on the cutting edge of Bitcoin’s unbounded future.



Steve Shadders

Bitcoin SV [BSV] Scaling Test Network is open for business

<figure class="wp-block-image size-full"><img loading="lazy" width="1024" height="511" src="https://theoffgrid.net/wp-content/uploads/2022/04/128mb36h-1024x511-1.png" alt="" class="wp-image-928" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/128mb36h-1024x511-1.png 1024w, https://theoffgrid.net/wp-content/uploads/2022/04/128mb36h-1024x511-1-300x150.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/128mb36h-1024x511-1-768x383.png 768w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



A new milestone was achieved recently on the Bitcoin SV Scaling Test Network with continuous 128MB blocks over a period of 36 hours. The test ran from about midday on the 7th of March through to midnight on the 8th. 246 blocks were produced during this period and each one was 128MB large. The blocks contained 89 million transactions with an average size of 354 bytes each. This equates to 700 direct cash transactions per second over the entire period, a remarkable achievement that demonstrates that Bitcoin, as originally designed by Satoshi Nakamoto in 2009, can scale to meet the needs of global use.



The BSV Scaling Test Network is an initiative of Bitcoin Association’s BSV Node project, developed by nChain with funding from CoinGeek; transaction volume is generated by the Satoshi Shotgun team. The global public network is continuously loaded with transactions to enable Bitcoin SV development teams to test their applications and systems under heavy load. The Bitcoin SV Node implementation development team also uses this network to measure performance of the Bitcoin SV Node software and validate optimizations and improvements. Use of the network has produced vital data and information which is being used to guide further improvements to the Bitcoin SV Node software, preparing the path for 512MB blocks this summer and 2GB blocks by the end of the year.

BSV Scaling Test Network Sustains 128MB Blocks for 36 Hours

The Bitcoin SV (BSV) community is committed to the “Satoshi Vision” for delivering a secure and scalable Bitcoin network that supports the world’s new money and use as the global enterprise blockchain. As part of its commitment to professionalise the Bitcoin development process, the <a href="https://bitcoinsv.io/">Bitcoin SV Node </a>implementation team engaged the services of Trail of Bits, a leading cybersecurity research company with expertise in blockchain technologies, to perform a security audit of the Bitcoin SV Node implementation source code.&nbsp; The security audit revealed multiple vulnerabilities that Bitcoin SV did not itself cause but likely inherited from the Bitcoin Core (BTC) and thus Bitcoin ABC software for Bitcoin Cash (BCH) from which the Bitcoin SV were forked.&nbsp; However, Bitcoin SV’s audit and professionalised approached to security has now helped all these major blockchains resolve the vulnerabilities.



A full security audit requires significant time and cost to perform, but the Bitcoin SV Node implementation team did so (with financial support from its partners at <a href="https://coingeek.com/">CoinGeek</a>) as a critical step to bring more professionalism to the Bitcoin ecosystem.&nbsp; We believe this is the first time any Bitcoin node implementation has ever been security audited in the 10-year history of Bitcoin.



After conducting its security audit, Trail of Bits reported numerous&nbsp; findings.&nbsp; The Bitcoin SV Node implementation team considered three of these findings to be significant enough to warrant responsible and confidential disclosure to other potentially affected Bitcoin implementations – specifically to implementations for the Bitcoin Core (BTC) and Bitcoin Cash (BCH) chains which compete against BSV.



The three vulnerabilities have been rated as medium severity with low difficulty to exploit and expose the Bitcoin node software to Denial of Service attacks resulting in a high overall risk rating. The Bitcoin SV Node implementation team disclosed the details of these vulnerabilities to other Bitcoin implementations (for Bitcoin Core and Bitcoin Cash) on 10 January 2019, requesting full confidentially until 11 February 2019 and that detailed information about the vulnerabilities be kept confidential until 1 March 2019. This process follows industry best practice by providing sufficient time for development teams to release and deploy updated software before the details of the vulnerabilities become public knowledge.



The details of the vulnerabilities were disclosed to the software development teams of Bitcoin Unlimited, Bitcoin XT, Bitcoin ABC, and Bitcoin Core. An analysis of the vulnerable portions of the source code indicated that these software implementations may be affected by these vulnerabilities – most likely because the vulnerabilities first existed in the Bitcoin Core software before it was forked by Bitcoin ABC to create ABC (an implementation for Bitcoin Cash), and before Bitcoin SV thus inherited these vulnerabilities from Bitcoin ABC.



1) The first vulnerability, CVE-2018-1000891, would enable an attacker to send specially crafted network packets to the target node which would needlessly consume large amounts of processor and network resources. The attack could result in a Denial of Service by exhausting processor and network resources and would not be detected or prevented by the software.



2) The second vulnerability, CVE-2018-1000892, would similarly enable an attacker to send specially crafted network packets which would needlessly consume large amounts of processor and network resources. The attack could result in a Denial of Service by exhausting processor and network resources and would not be detected or prevented by the software.



3) The third vulnerability, CVE-2018-1000893, would also enable an attacker to send specially crafted network packets which would needlessly consume large amounts of memory resources. The attack could result in a Denial of Service by exhausting memory resources and causing system failure. The attack would not be detected or prevented by the software.



For Bitcoin SV, these vulnerabilities were addressed in release 0.1.1 of the Bitcoin SV Node implementation which was released on 11 February 2019.



Bitcoin SV Node Lead Developer Daniel Connolly remarked:



“By organising this security audit (with funding by CoinGeek) and by sharing the results in a responsible and secure manner, the Bitcoin SV Node team, <a href="https://nchain.com/en/">nChain</a> and our partners at CoinGeek demonstrate our commitment to increase the quality of Bitcoin software and professionalise the engineering process.”



Even though the Bitcoin SV Node implementation team did not create these vulnerabilities and likely inherited them from Bitcoin Core and Bitcoin ABC, its groundbreaking approach to apply software industry best practices to Bitcoin node development has now also benefited the competing Bitcoin Core and Bitcoin Cash ecosystems.



The Bitcoin SV Node reference implementation is a project of the <a href="https://bitcoinassociation.net/">Bitcoin Association</a>.&nbsp; The Bitcoin Association’s Founding President Jimmy Nguyen observed:



“As I’ve said before, it’s time for Bitcoin to grow up and professionalise.&nbsp; This security audit is a big step in that direction, because no other Bitcoin project is taking such a comprehensive approach to security.&nbsp; The results and improvements exemplify how the Bitcoin SV Node team is taking steps to prepare Bitcoin SV to have the reliability needed to become the world’s new money and the global enterprise blockchain.&nbsp; It also demonstrates that Bitcoin SV is now leading the Bitcoin industry, even helping other projects that deviated from the Satoshi Vision for Bitcoin.”

BITCOIN SV SECURITY AUDIT HELPS RESOLVE MULTIPLE VULNERABILITIES ACROSS DIFFERENT BITCOIN BLOCKCHAINS

As part of its commitment to professionalise the Bitcoin development process, the Bitcoin SV Node implementation team engaged the services of Trail of Bits, a leading cybersecurity research company with expertise in blockchain technologies, to perform a security audit of the Bitcoin SV Node implementation source code. Three of the vulnerabilities that were discovered by this security audit could be exploited to perform denial of service attacks on Bitcoin.



These vulnerabilities were responsibly disclosed to the software development teams of Bitcoin Unlimited, Bitcoin XT, Bitcoin ABC, and Bitcoin Core. An analysis of the vulnerable portions of the source code indicated that these software implementations may be affected by these vulnerabilities because the source code for these implementations are derived from the same origin.



These vulnerabilities have been addressed in <a href="https://bitcoinsv.io/2019/02/11/bitcoin-sv-v0-1-1-released/">release 0.1.1 of Bitcoin SV</a>. The Bitcoin SV Node implementation team strongly encourages all users of the Bitcoin SV Node implementation to upgrade their software as quickly as possible.



<h2>CVE-2018-1000891 – Uncontrolled resource consumption when receiving messages with invalid checksums</h2>



Impact of vulnerability: Denial of Service Severity: Medium Difficulty: Low Recommendation: upgrade to Bitcoin SV 0.1.1



It’s currently possible for a malicious remote host to send an arbitrary number of p2p messages with invalid checksums, wasting the victim node’s CPU and network resources. This activity is not classified as a misbehaving node, and will never result in an IP ban. The remote host can send these messages unsolicited, without waiting for a protocol session to be initiated by the victim via its peer discovery process.



<h5>Exploit Scenario</h5>



A malicious node intentionally generates and sends messages with invalid checksums, and consumes both network resources (available TCP ports, network bandwidth) and CPU time (to compute the SHA256 hash of the message payload, in ​ GetMessageHash​ ) of the victim node.



The impact of such a resource consumption attack appears to be limited only by the throughput of the network connection between the attacker and the victim. The Bitcoin SV software itself implements various DoS mitigations​, but those do not include any rate-limiting on traffic from a peer. In the worst-case scenario of resource consumption, the attacker would be able to prevent the victim from mining.



The vector for exploiting this vulnerability is any p2p connection to or from the node. Bitcoin nodes usually make outbound p2p network connections to other nodes and also accept inbound p2p connections from any source. Either type of connection, inbound or outbound, could be a vector for an exploit of this vulnerability.



<h2>CVE-2018-1000892 – Uncontrolled resource consumption when receiving sendheaders messages</h2>



Impact of vulnerability: Denial of Service Severity: Medium Difficulty: Low Recommendation: upgrade to Bitcoin SV 0.1.1



A Bitcoin SV node will accept up to 64KB of messages at a time from another node. This is enough space to deliver a sequence of 2739 ​ sendheaders​ messages, which require only 24 bytes and have, by definition, a zero-length body. Receiving 2739 null-sized ​ sendheaders messages keeps the victim node busy for a while, since nodes are expected to announce new blocks by sending the header of the new block along with any other blocks that it believes a peer might need.



<h5>Exploit Scenario</h5>



A malicious node intentionally floods a victim node with empty ​ sendheader​ messages, and consumes both network resources (available TCP ports, network bandwidth) and CPU time (message processing) of the victim node. The attack can be sent repeatedly because there is currently no logic to detect this behavior or ban a node for sending too many sendheaders​ messages.



The impact of such a resource consumption attack appears to be limited only by the throughput of the network connection between the attacker and the victim. The Bitcoin SV software itself implements various DoS mitigations​, but those do not include any rate-limiting on traffic from a peer. In the worst-case scenario of resource consumption, the attacker would be able to prevent the victim from mining.



The vector for exploiting this vulnerability is any p2p connection to or from the node. Bitcoin nodes usually make outbound p2p network connections to other nodes and also accept inbound p2p connections from any source. Either type of connection, inbound or outbound, could be a vector for an exploit of this vulnerability.



<h2>CVE-2018-1000893 – Uncontrolled resource consumption when deserializing transactions</h2>



Impact of vulnerability: Denial of Service Severity: Medium Difficulty: Low Recommendation: upgrade to Bitcoin SV 0.1.1



A specially crafted message with a falsified value in its size field causes Bitcoin SV to allocate and create a massive amount of CTxOut​ objects when the message is deserialized.



<h5>Exploit Scenario</h5>



A malicious peer sends a message that has a valid header, but when deserialized, reports a size field of 33,554,432 (the maximum number). This wastes a significant (and asymmetric) amount of the victim node’s memory and CPU time. This condition causes an exception to be thrown, but does not cause the sender to be classified as a misbehaving peer. The attacking node will not be banned, and can repeat the attack with additional malicious messages.



In the worst-case scenario, the attacked would be able to prevent the victim from performing any useful work, including the distribution of transactions or blocks, or even mining.



The vector for exploiting this vulnerability is any p2p connection to or from the node. Bitcoin nodes usually make outbound p2p network connections to other nodes and also accept inbound p2p connections from any source. Either type of connection, inbound or outbound, could be a vector for an exploit of this vulnerability.

Denial of Service Vulnerabilities Repaired in Bitcoin SV version 0.1.1

The Bitcoin SV ecosystem has benefited from significant developments in the past week – with six (count them six!) new releases just from Bitcoin developer <a href="https://twitter.com/_unwriter">_unwriter</a>. That alone deserves a special Satoshi Shout-Out below!



<a href="https://coingeek.com/bitcoin-sv-bsv-mines-world-record-103mb-block-10th-anniversary-bitcoin-genesis-block/">Along with increased scaling achievements</a>, the Bitcoin SV ecosystem continues to grow at a rapid pace. &nbsp;Read below for a summary of the past week’s developments from around the world



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/10/jimmy.png" alt="" class="wp-image-4663"/></figure>



Jimmy Nguyen



Founding President, bComm Association &amp; your friendly BSV Global Ambassador



Satoshi Shout-Out



The week’s special “Satoshi Shout-Out” goes to Bitcoin developer <a href="https://twitter.com/_unwriter">_unwriter</a> who made an epic series of announcements, releasing 6 powerful applications in 7 days (resting on the last day). The <a href="https://twitter.com/_unwriter/status/1084935371551588352">first day’s application, appropriately called “Genesis,”</a> is a Bitcoin SV-exclusive node that is powered by _unwriter’s <a href="https://bitdb.network/">BitDB data library</a>.&nbsp; After Genesis, <a href="https://twitter.com/_unwriter">_unwriter’s</a> next 5 applications and tools are specific use-case applications of BitDB:



<ul><li>a data-only node called “<a href="https://twitter.com/_unwriter/status/1085186279749369861">Babel</a>,”</li><li>a time-indexing “ephemeral” node called “<a href="https://twitter.com/_unwriter/status/1085687191857229826">Chronos</a>,”</li><li>a block-metadata application called “<a href="https://twitter.com/_unwriter/status/1085923999987703808">Meta</a>,”</li><li>a programmable API for push notifications (for all of the above) called “<a href="https://twitter.com/_unwriter/status/1086299718395854849">BitSocket</a>,”</li><li>and a multiuser chat browser called “<a href="https://twitter.com/_unwriter/status/1086608512996773890">Bitchat</a>.”</li></ul>



Find the list of <a href="https://twitter.com/_unwriter">_unwriter’s</a> Bitcoin [SV] tools and the respective elaborating Medium posts <a href="https://twitter.com/_unwriter/status/1087035086598483968">here</a>.



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/unwriter.png" alt="" class="wp-image-4196"/></figure>



Dear _unwriter:&nbsp; we don’t know who you are, but you deserve a loud Satoshi Shout-Out from the entire BSV community!



Applications &amp; Services



<h3><a href="http://maps.bsvdevs.com/">BSV Maps</a></h3>



BSV/DEVS, the developer resource centre, has introduced a new service for merchants and other service providers such as ATMs to express their support for BSV. In the <a href="https://twitter.com/BsvDevs/status/1085092018907312128">introducing tweet</a>, the team explains:



Introducing BSV MAPS



You can now submit bars, restaurants, stores and ATMs that support Bitcoin SV.



The plan is to change the captcha into a moneybutton paywall and therefore have it instantly publish.



I will also expose the map data via an API.



<a href="http://maps.bsvdevs.com">http://maps.bsvdevs.com</a>



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/bsv-map-300x224-1.png" alt="" class="wp-image-4197"/></figure>



<h3><a href="https://coinify.com/">Coinify</a></h3>



In a very big development for the BSV ecosystem growth, the leading virtual-currency payment provider announced it added support for BSV.&nbsp; Coinify allows merchants to seamlessly accept BSV and convert it, at will, to the fiat currency of their choice (a big step towards mass adoption!). &nbsp;<a href="https://coingeek.com/virtual-currency-payment-gateway-coinify-activates-bitcoin-sv-bsv/">From its announcement</a>, Coinify CEO and co-founder Mark Højgaard explained:



Virtual currencies need to have widespread merchant adoption to really ignite on a mainstream level, and we believe that the simplicity and flexibility of our payment product range makes this possible. Adding BSV as a virtual currency helps us ensure we have the most comprehensive range of options for both merchant and customer.



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/coinify.png" alt="" class="wp-image-4198"/></figure>



<h3><a href="x-apple-ql-id://word/Memo.cash">Memo.cash</a></h3>



The popular blockchain-powered social media platform <a href="https://twitter.com/memobch/status/1086994739402964993">announced</a> release of its mobile app for Android phones.&nbsp; The app is available at the <a href="https://play.google.com/store/apps/details?id=com.memoapp">Google Play store</a>.



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/memocash.png" alt="" class="wp-image-4199"/></figure>



<h3><a href="https://www.bitcoin.no/">Ka-Ching</a></h3>



The <a href="https://www.youtube.com/channel/UCoWA4QI_uEMYV2WXbLbDVNQ">Bitcoin SV Crypto Channel</a> featured a <a href="https://www.youtube.com/watch?v=Zv2xvoE6S0E">video interview</a> with the Bitcoin.no team (Stein Håvard Ludvigsen &amp; Thomas Bakketun). Their company has created the Ka-Ching protocol to enable contactless payments using physical NFC cards (or wearable devices in the future).&nbsp; The solution will allow easy payments using BSV at retail points of sale (similar to the HandCash solution with POP!).&nbsp; Ka-Ching can process 19 payment transactions (and thus customers) per minute from a single terminal.



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/ka-ching.png" alt="" class="wp-image-4200"/></figure>



<h3><a href="https://www.duckcreation.com/">DuckCreation</a></h3>



The merchant offering Bitcoin stickers and other products is showing us the way of the future by accepting BSV for payments (taking advantage of the new recommended BSV logo to announce Bitcoin SV Accepted Here!). &nbsp;Now you can buy some unique artwork merchandise and stickers with BSV <a href="https://www.duckcreation.com/">here</a>.



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/bsv-artwork.png" alt="" class="wp-image-4201"/></figure>



Exchanges



Last week, we learned more about <a href="https://blog.sfox.com/introducing-bitcoin-sv-on-sfox-c7f9d3490cb4">SFOX</a>, an algorithmic trading platform, which has now added support for BSV trading (in beta stage).&nbsp; Watch an interview by the SFOX team with Jimmy Nguyen to learn more about the BSV split from BCH and the future of BSV <a href="https://bcommassociation.com/news/sfox-edge-interview-with-jimmy-nguyen">here</a>



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/BSV-SFOX.png" alt="" class="wp-image-4202"/></figure>



To see all major exchanges that list BSV, visit <a href="https://coinmarketcap.com/currencies/bitcoin-sv/#markets">CoinMarketCap</a> or <a href="https://www.coingecko.com/en/coins/bitcoin-sv/trading_exchanges#panel">CoinGecko</a>.[



New Visions for Bitcoin from Dr. Craig S. Wright – BSV Peer-to-Peer Web Payments and Bookkeeping



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2020/09/csw-portrait.png" alt="" class="wp-image-4203"/></figure>



nChain’s Chief Scientist Dr. Craig S. Wright has continued with his weekly series on his <a href="https://medium.com/@craig_10243">Medium account</a>, revealing new applications and uses for Bitcoin.&nbsp; In the powerful series, Wright shares his ideas about and expertise on new ground-breaking applications and services—made possible on the <a href="https://bitcoinsv.io/">Bitcoin SV blockchain</a>.



Wright’s <a href="https://medium.com/@craig_10243/taking-money-over-the-web-using-bitcoin-the-way-it-was-designed-446385c1a04b?source=user_profile---------2------------------">third entry</a> in the series is entitled “<a href="https://medium.com/@craig_10243/taking-money-over-the-web-using-bitcoin-the-way-it-was-designed-446385c1a04b?source=user_profile---------2------------------">Taking money over the web using Bitcoin — the way it was designed</a>,” and focuses on the seamless integration and facilitation of payments on the web using Bitcoin; the solution allows both fiat and bitcoin (and any tokens for that matter) to be safely accepted for value of consideration or payment—in a manner that is more structured, organised, and thus more efficient than current standards.



The solution is one of many cornerstones of nChain’s ground-breaking <a href="https://nchain.com/en/media/nchain-unveils-ground-breaking-metanet-project-to-power-the-internet-on-bitcoin-sv-blockchain/">Metanet project</a>, and brings us closer to establishing the Internet services we know (and more) on top of a safer and more efficient back-end—by using Bitcoin SV as the world’s global blockchain and database.



Read the full business-friendly summary <a href="https://nchain.com/en/blog/bsv-peer-to-peer-web-payments-and-bookkeeping-new-visions-for-bitcoin-from-dr-craig-s-wright/">here</a>.



Implement the BSV-powered web payments and bookkeeping (call it “BDI” for “Bitcoin data interchange”), and follow more exciting new applications and solutions by reading Craig Wright’s entry <a href="https://medium.com/@craig_10243/taking-money-over-the-web-using-bitcoin-the-way-it-was-designed-446385c1a04b?source=user_profile---------2------------------">here</a>.



Or get in touch with nChain Professional Services <a href="https://nchain.com/en/contact/">here</a>.



For a more comprehensive list of Bitcoin SV services, applications, and developer tools, please visit <a href="https://bitcoinsv.io/services/">https://bitcoinsv.io/services/</a>.



If you would like your application or service listed in a future BSV Weekly update, please email us at <a href="mailto:info@bcommassociation.com">info@bcommassociation.com</a>.

Bitcoin SV (BSV) Weekly – Jan 23, 2019

The Bitcoin SV network is committed to massive on-chain scaling, and nChain’s team is progressing with technical work needed to achieve this Satoshi Vision. &nbsp;In fact, our recent tests have demonstrated the Bitcoin SV network’s capacity to handle sustained 64 MB blocks over a full 24 hour period, and we are already moving towards showing sustained 128 MB blocks. &nbsp;Here’s a quick update on what we are doing, and what is coming for the future.



Sustained Big Blocks on BSV Scaling Test Network



In September 2018 nChain built its own version of the former Gigablock Test Network to research Bitcoin scalability. The new Scaling Test Network (STN) is designed to be a permanent public test network with regular and consistent large volumes of transactions. The next release of the Bitcoin SV Node implementation will support the STN in the same way as the testnet and regtest networks.



nChain and the Satoshi Shotgun (Professional Stress Test) team began collaborating on the STN in December 2018, starting with a &nbsp;“warm up”. We updated the network, implemented a performance monitoring and analytics system, and extended the Satoshi Shotgun to support the STN. Once this was done, we began steadily ramping up the volume of transactions.



We have seen large blocks (64, 65 and even 103 MB) mined on the BSV live network. While those are impressive, we know that true success is showing that BSV can sustain large blocks of that and much bigger size for long periods. The STN is designed to support research into the throughput capacity of the Bitcoin network. Our focus over the last month has been on transaction propagation. That means we have specialized systems, such as the Satoshi Shotgun, produce transactions and deliver them to a non-mining node. The transactions then propagate across the STN, are received by mining nodes, and are mined into blocks. The aim is to have a reasonably realistic model of the public Bitcoin SV network. We will be adjusting this model as needs and focus change.



What have we seen? Well, sustained 64MB blocks – over a full 24 hour period – with the latest development build of Bitcoin SV are easy. That’s 270 transactions per second, sustained, continuously for a full 24 hour period. Our tests did this over a 24 hour period with no problem.



<figure class="wp-block-image size-full"><img loading="lazy" width="728" height="422" src="https://theoffgrid.net/wp-content/uploads/2022/04/img64mb.png" alt="" class="wp-image-936" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/img64mb.png 728w, https://theoffgrid.net/wp-content/uploads/2022/04/img64mb-300x174.png 300w" sizes="(max-width: 728px) 100vw, 728px" /></figure>



Sustained 128MB blocks? Yup.



<figure class="wp-block-image size-full"><img loading="lazy" width="573" height="332" src="https://theoffgrid.net/wp-content/uploads/2022/04/img128mb.png" alt="" class="wp-image-937" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/img128mb.png 573w, https://theoffgrid.net/wp-content/uploads/2022/04/img128mb-300x174.png 300w" sizes="(max-width: 573px) 100vw, 573px" /></figure>



A bit more difficult than 64MB but we’re getting there for sustained 128MB blocks.



Improving Transaction Propagation



Block size achievements are important, but it’s critical to measure specific behaviour in the node. During our research, we confirmed that transaction propagation is one of the key factors that is limiting the capability to produce big blocks. This is unsurprising and was expected but it’s important to confirm theories and suspicions with measurements and data.  We added a specific metric called txninvsize, this is the number of transactions that are queued to be included in inventory messages to a peer. It’s the mechanism that the node uses to inform other nodes about transactions so that they can be propagated.



<figure class="wp-block-image size-full"><img loading="lazy" width="679" height="350" src="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture1.png" alt="" class="wp-image-938" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture1.png 679w, https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture1-300x155.png 300w" sizes="(max-width: 679px) 100vw, 679px" /></figure>



This graph is from a mining node. You can see that occasionally 1000 transactions are queued for notification to other nodes but these are exceptions, the queue gets quickly cleared. This is a specific function that we have improved in the next version of the Bitcoin SV Node implementation. Prior to this change, we were seeing queues of between 600,000 and 800,000 transactions build up during stress tests. If a node can’t inform other nodes about the transactions it has, those transactions just don’t get propagated.



That change also addressed CPU use by the P2P networking, spreading the load out across multiple cores. The graph below shows the load on that mining node during the same period.



<figure class="wp-block-image size-full"><img loading="lazy" width="677" height="375" src="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture2.png" alt="" class="wp-image-939" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture2.png 677w, https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture2-300x166.png 300w" sizes="(max-width: 677px) 100vw, 677px" /></figure>



What’s interesting here are the peaks, reaching regularly above 1.2 and touching 1.4. Load is measured in terms of cores, so 1 is equivalent to one core being fully occupied. In this graph, we can see the P2P networking code starting to spread out over other cores. Prior to this update, we never saw the load above 1. There’s still a long way to go with making Bitcoin truly multi-processing but this is a great start.



No measurement system would be complete without measuring the performance of individual cores. This dashboard is not very useful at this resolution, it’s just here to give an idea of the kind of metrics we are gathering.



<figure class="wp-block-image size-full"><img loading="lazy" width="974" height="422" src="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture3.png" alt="" class="wp-image-940" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture3.png 974w, https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture3-300x130.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture3-768x333.png 768w" sizes="(max-width: 974px) 100vw, 974px" /></figure>



It’s also useful to look at the problems. Here is a graph of the mempool size of an under-provisioned node. You see the sharp drops in the graph, this is where the system runs out of memory and terminates the bitcoin process. Bitcoin starts up again, loads up the mempool, and then fails again.



<figure class="wp-block-image size-full"><img loading="lazy" width="679" height="379" src="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture4.png" alt="" class="wp-image-941" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture4.png 679w, https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture4-300x167.png 300w" sizes="(max-width: 679px) 100vw, 679px" /></figure>



One area of concern is collecting the metrics. In the graph below you can see several gaps in the data, this is caused by timeout’s when collecting the data. We will hopefully be addressing this in a future version of the Bitcoin SV Node implementation.



<figure class="wp-block-image size-full"><img loading="lazy" width="974" height="247" src="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture5.png" alt="" class="wp-image-942" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture5.png 974w, https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture5-300x76.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/warming-post-Picture5-768x195.png 768w" sizes="(max-width: 974px) 100vw, 974px" /></figure>



The STN provides an invaluable resource for evaluating the performance of the Bitcoin SV software with large transaction volumes. We have used it extensively to confirm theories and evaluate our improvements to the Bitcoin SV Node implementation and we will continue to extend it. What we have learned has not only helped the Bitcoin SV Node team to get to this point but has helped outline a clear roadmap for more short term scaling gains.



Next Steps on the Scaling Journey



With these test results in hand, what’s next?



We are now starting to contact BSV miners and development teams and inviting them to participate in testing on the BSV STN, to make use of this opportunity to evaluate their systems performance and capacity to deal with a high transaction throughput network. &nbsp;For the ecosystem at large, it is important that ALL infrastructure services, not just mining nodes, are properly load tested to ensure uninterrupted service during peak load periods.



Our goal is to eventually have every ecosystem participant running a test instance of their product on STN – &nbsp;including wallets providers, exchanges, block explorers, BitDBs and more. With the next release of Bitcoin SV, planned for 11 February 2019, this network will be public and available to everyone.



After that, we plan to conduct a public stress test on the BSV mainnet. We will work with the Satoshi Shotgun team to do another Professional Stress Test of BSV, and see how sustained periods of large blocks perform on BSV in real life. &nbsp;&nbsp;This is just another step in our scaling journey for BSV. One day, we want to look back and see how small 64 and 128MB blocks truly are in the Satoshi Vision for Bitcoin.



Daniel Connolly



Bitcoin SV Lead Developer

Warming Up the Scaling Test Network  for Bitcoin SV – 24 hours of Sustained 64 MB Blocks

<a href="https://coingeek.com/bitcoin-sv-bsv-mines-world-record-103mb-block-10th-anniversary-bitcoin-genesis-block/">Along with scaling capacities</a>, the Bitcoin SV ecosystem continues to grow at a rapid pace. &nbsp;In our weekly post, we provide a summary of some of the past week’s developments from around the world.



Today’s special “Satoshi Shout-Out” goes out to <a href="https://play.google.com/store/apps/details?id=com.hivr.bch.bitcoincash.production&amp;hl=en_US">hivr</a>; the social network built around a BSV wallet is sponsoring “one of the biggest #esport events in Thailand,” further <a href="https://twitter.com/hivrapp/status/1083665410816262146">explaining</a>:



We decided to add #BitcoinSV #BSV as an official sponsor. We will push BitcoinSV in our native country (Thailand) in every way we can this year <a href="https://t.co/3EBpaHRFXz">#ADOPTION</a>



eSport and Bitcoin make a natural combination, so a shout-out to hivr for using theopportunity to push adoption in Thailand! &nbsp; Working together across the world, we are bringing the Satoshi Vision to life — to create the world’s new money and the global public ledger for the world’s enterprises.[/vc_column_text][vc_column_text]



Jimmy Nguyen



Founding President, bComm Association



&amp; your friendly BSV Global Ambassador



Wallets



As we have <a href="https://bcommassociation.com/news/bitcoin-sv-bsv-weekly-jan-2-2019">previously summarized</a>, numerous wallets have announced exclusive support for BSV – &nbsp;<a href="https://www.cashpay.solutions/wallet/">CashPay,</a>&nbsp;<a href="https://centbee.com/">Centbee</a>,&nbsp;<a href="https://handcash.io/">HandCash</a>,&nbsp;<a href="https://play.google.com/store/apps/details?id=com.hivr.bch.bitcoincash.production&amp;hl=en_US">hivr</a>, <a href="https://www.pixelwallet.io/">Pixel Wallet</a>, and more. Last week’s further progress includes:



<a href="https://bcommassociation.com/news/electrumsv-wallet-released-for-bitcoin-sv-bsv-the-original-bitcoin">ElectrumSV</a> – considered one of the top Bitcoin wallets because of its strong technical feature set, key developers from the Electrum wallet project (and its spin-off Electron Cash for BCH) have released a BSV version in the form of <a href="https://electrumsv.io/">ElectrumSV</a>. Given that there are already strong BSV mobile wallets, ElectrumSV will focus on being a desktop wallet. &nbsp;Version 1.0.0 is&nbsp;available for download at&nbsp;<a href="https://electrumsv.io/">electrumsv.io</a>,&nbsp;and is provided for free usage under the open–source&nbsp;<a href="https://opensource.org/licenses/MIT">MIT license.</a> &nbsp;ElectrumSV is supported by the bComm Association and nChain. &nbsp;Read the bComm Association’s official announcement <a href="https://bcommassociation.com/news/electrumsv-wallet-released-for-bitcoin-sv-bsv-the-original-bitcoin">here</a>.



<a href="https://handcash.io/">HandCash</a> – the user-friendly mobile wallet (the one with the easy-to-use $handles) has announced a major update for its Android application. On Twitter, the team <a href="https://twitter.com/handcashapp/status/1083341788172165121">shares</a>:



Android 1.3 update for next week:



–​Deep wallet (internals) redesign, moving away from SPV.



– ​Drastic improvements in speed and reliability, fixing all problems when displaying certain transactions



–​Drastic reduction of recovery time – from minutes to seconds.



–​Payment requests adapted to the new standard “bitcoin:?sv”



–​The update will automatically restore your wallet so everything is migrated to the new structure, it will just take a few seconds.



<a href="https://www.coinomi.com/en/">Coinomi</a> – the multi-coin wallet supporting BSV has released its desktop application. In the email announcement, the team explains:



Beside your native Android and iOS support, your coin is included in our latest Desktop release for Windows, Linux, and Mac. (…)



We value the coins in our ecosystem and we want to also share the good news that historical features and more exchange options are coming to the application very soon making it easier for users to interact with your coin.



Exchanges



Exchanges are a useful on-ramp service that enables users to purchase and trade BSV, which they can then use to facilitate transactions on the BSV blockchain that benefit their everyday lives. &nbsp;More than 70 exchanges now list BSV, including some of the biggest global exchange services such as <a href="https://www.binance.com/">Binance</a>,&nbsp;<a href="https://www.bitcoin.de/">Bitcoin.de</a>, or <a href="https://shapeshift.io/">ShapeShift.io</a>.



Last week’s new entry is from <a href="https://twitter.com/sideshiftai">SideShift.ai</a>. &nbsp;Similar in function to the exchange service <a href="https://shapeshift.io/">ShapeShift.io</a>, SideShift allows users to exchange other cryptocurrencies for BSV, without some of the requirements needed to register for a fiat-to-cryptocurrency exchange.



To see all major exchanges that list BSV, visit <a href="https://coinmarketcap.com/currencies/bitcoin-sv/">CoinMarketCap</a> or <a href="https://www.coingecko.com/en/coins/bitcoin-sv/trading_exchanges">CoinGecko</a>.



Developer Tools



The Bitcoin developer community is rapidly creating more tools for BSV which help power user-friendly Bitcoin applications. New developments include:



<a href="https://www.moneybutton.com/">Money Button</a> – the powerful and easy-to-use tool enabling and backing several other Bitcoin applications, such as <a href="https://t.co/qBtkFEbQuh">Datapay</a> and <a href="https://github.com/monkeylord/electrum-ecies">ECIES</a>, has released an <a href="https://twitter.com/money_button/status/1083214809816911872">update</a> allowing bigger blocks(such as the record-setting 103MB block mined on BSV on January 3) to be processed even faster:



Our new monitor is now live! We can process the 103 MB block in about 40 seconds instead of 1 hour. In theory we can go up to about ~ 1 GB blocks without user experience being impacted. Do we have any remaining scaling issues? Bring on the next stress test!



<a href="http://bitindex.network/">BitIndex</a> – a developer tool powering other useful Bitcoin applications; services include a UTXO database, a wallet manager, and a blockchain API. The <a href="https://twitter.com/BitIndexNetwork/status/1083630919624417280">announcing tweet</a> describes the tool as follows:



BitIndex API is now public for #Bitcoin #SatoshiVision developers.



Build your app faster and spend less time managing UTXOs and Wallets for Bitcoin.



Real-time UTXO database, manage wallets (XPUB suppport) and blockchain API.



Get your API key at <a href="http://bitindex.network/">http://bitindex.network</a>



<a href="https://t.co/qTMiuX3UZU">Bitcoin SV Payments for WooCommerce</a> – a tool that enables payments in Bitcoin SV for physical and digital products at a WooCommerce-powered store. As the developer resource centre <a href="https://twitter.com/BsvDevs">BSV/DEVS</a> shared on <a href="https://twitter.com/BsvDevs/status/1084570796381462528">Twitter</a>:



A new payment processor option has been added to <a href="http://bsvdevs.com/">http://bsvdevs.com</a>



Bitcoin SV Payments for WooCommerce is a WordPress plugin that allows you to accept payments in Bitcoin SV for physical and digital products at your WooCommerce-powered store.



Applications &amp; Services



<a href="https://fivebucks.com/">Fivebucks</a> – the team behind the global freelance marketplace <a href="https://twitter.com/fivebuckscom/status/1083211075741458433">summarized in a tweet</a> the significant progress it has made, in commemoration of the 10th anniversary of the Bitcoin genesis block:



Happy 10 years Bitcoiners! 🎉



These days Fivebucks hit some small but important milestones: 500 listings, 1k freelancers, 200 completed jobs



We’re only scratching the surface but some REAL deals have emerged. Thanks to BSV, Fivebucks is already delivering #BCONVENIENCE┗(°0°)┛



<a href="file:///C:/Users/s.ploetzeneder/AppData/Local/Microsoft/Windows/INetCache/Content.Outlook/WLT1PIC5/Memo.cash">Memo.cash</a> – “<a href="https://sv.memo.cash/">https://sv.memo.cash</a> now has SV block explorer links!” is the announcement from Memo.cash, allowing users to view transactions made on the popular blockchain-powered social media platform in a BSV explorer; directly linked blockchain explorers c<a></a>urrently include <a href="http://whatsonchain.com/">whatsonchain.com</a>, <a href="https://svblox.com/">svblox.com</a>, and&nbsp;<a href="https://bchsvexplorer.com/">bchsvexplorer.com</a>.



BSV-powered Passports – New Visions for Bitcoin from Dr. Craig S. Wright



nChain’s Chief Scientist Dr. Craig S. Wright has continued with his weekly series on his <a href="https://medium.com/me/stories/public">Medium account</a>, revealing new applications and uses for Bitcoin (possible exclusively on Bitcoin SV, because they use nChain intellectual property). &nbsp;In the powerful series, Wright shares his ideas about and expertise on new ground-breaking applications and services—made possible on the <a href="https://bitcoinsv.io/">Bitcoin SV blockchain</a>.



Wright’s <a href="https://medium.com/@craig_10243/smart-card-based-mobile-wallets-9cb75595b71d">second entry</a> in the series is entitled “<a href="https://medium.com/@craig_10243/smart-card-based-mobile-wallets-9cb75595b71d">Smart-card-based mobile wallets</a>,” and focuses on the use of electronic cards (“smart cards”) to facilitate secure, feasible, yet user-friendly system authentication through a Bitcoin (SV) wallet. The application is an enhanced application of nChain’s patent innovation for “<a href="https://nchain.com/en/blog/nchain-receives-6th-epo-patent-security-personal-device-determined-common-secret/">Security through a Personal Device and Determined Common Secret</a>,” which through the use of a biometric (think fingerprints) smart card allows for greater ease of use and security in passports / personal identification cards, communication channels, payments, or file encryption.



Businesses and institutions offering identification services can save costs by gaining in reliability, security, and speed.



New possibilities are becoming feasible because of the efficient and secure database that Bitcoin SV provides; and the integrated use of BSV transactions allows direct and efficientmonetisation.



The technology can be implemented in a smart card, but also a smart watch, or even as a direct integration into one’s passport.



Read more about the invention in our blog summary <a href="https://nchain.com/en/blog/bsv-powered-passports-new-visions-for-bitcoin-from-dr-craig-s-wright/">here</a>.



OR implement the new BSV-powered identification system (the “BSV Pass,” “bID,” or “bCard”—you name it), and follow more exciting new applications and solutions by reading Craig Wright’s entry <a href="https://medium.com/p/9cb75595b71d?source=user_profile---------4------------------">here</a>.



For a more comprehensive list of Bitcoin SV services, applications, and developer tools, please visit <a href="https://bitcoinsv.io/services/">https://bitcoinsv.io/services/</a>.



If you would like your application or service listed in a future BSV Weekly update, please email us at <a href="mailto:info@bcommassociation.com">info@bcommassociation.com</a>.

Bitcoin SV (BSV) Weekly – Jan 16, 2019

The new year has started off with a big bang (or block) for Bitcoin SV (BSV)—the biggest yet in the history of public blockchains: on <a href="https://coingeek.com/bitcoin-sv-bsv-mines-world-record-103mb-block-10th-anniversary-bitcoin-genesis-block/">January 3rd, at block height 563638, a block the size of 103 MB</a> – containing 460,400 transactions – was successfully mined by <a href="https://pool.mempool.com/wn">Mempool</a> on the BSV chain. With over 700 transactions per second, Bitcoin SV has processed several multiples of the average capacity managed by PayPal. Yes, Bitcoin (SV) scales—on-chain!



The <a href="https://blockchair.com/bitcoin-sv/block/563638">record block</a> helped mark the 10th anniversary of the Bitcoin genesis block, and further confirms BSV is the rebirth of the original Bitcoin, designed to preserve Bitcoin’s fundamental design and fulfil the Satoshi Vision. &nbsp;The new year has ignited a focus on scaling to build the <a href="https://nchain.com/en/blog/bitcoin-sv-means-business-why-bsv-is-the-enterprise-friendly-blockchain/">enterprise-friendly blockchain</a> – with a stable, scalable, secure, and regulation-friendly platform for businesses to confidently build upon.



Along with scaling capacities, the Bitcoin SV ecosystem continues to grow at a rapid pace. Here’s a summary of some of the past week’s developments from around the world. &nbsp;Working together, we can bring the Satoshi Vision to life — to create the world’s new money and the global public ledger for the world’s enterprises of the future.



Jimmy Nguyen



Founding President, bComm Association &amp; your friendly BSV Global Ambassador



<h2>New BSV Logo</h2>



On January 3, 2019 – the 10th anniversary of the Bitcoin genesis block – we announced a <a href="https://bcommassociation.com/news/bitcoin-sv-bsv-unveils-logo-for-rebirth-of-original-bitcoin">new logo</a> for the Bitcoin SV token, and are recommending its usage. &nbsp;A&nbsp;modernized update of the&nbsp;cryptocurrency’s classic&nbsp;logo, the new design&nbsp;reflects&nbsp;Bitcoin SV’s roots, while leading a new era for&nbsp;Bitcoin to&nbsp;professionalize.



<figure class="wp-block-image"><img src="https://bitcoinsv.io/wp-content/uploads/2019/01/BSV_header-banner-300x150.png" alt="" class="wp-image-2193"/></figure>



▪ The B symbol&nbsp;is&nbsp;cleaner and&nbsp;stands&nbsp;upright&nbsp;rather than tilted forward or backward. &nbsp; ▪ “Bitcoin SV” characters&nbsp;also&nbsp;stand&nbsp;upright. ▪ “Bitcoin” begins with a&nbsp;capital B,&nbsp;rather than&nbsp;lower case. ▪ “SV”&nbsp;appears&nbsp;in superscript&nbsp;–&nbsp;reflecting Satoshi Vision as the way forward, while&nbsp;keeping emphasis on&nbsp;the name&nbsp;Bitcoin.&nbsp;&nbsp; ▪ The&nbsp;design&nbsp;color uses “dragon gold,”&nbsp;honouring&nbsp;the dragon logo of the&nbsp;<a href="https://bitcoinsv.io/">Bitcoin SV</a>&nbsp;full–node implementation which birthed BSV.



The logo was chosen after three Twitter polls of numerous design&nbsp;options developed by the bCommAssociation.



<a></a>The polls went <a></a>hand in hand with several other supporters in the ecosystem designing and providing matching contributions. For example, <a href="https://twitter.com/tomconn92205433/status/1081347138116833281?s=21">check out</a> an entire branding guide and collection by user <a href="https://twitter.com/Tomconn92205433">“tommy sv,”</a> offering BSV backgrounds, headers, and profile pictures.



The&nbsp;<a href="https://bitcoinsv.io/">Bitcoin SV Node</a>&nbsp;is now the reference implementation for the BSV protocol. &nbsp;To&nbsp;differentiate&nbsp;the full–node implementation from the&nbsp;BSV&nbsp;cryptocurrency, the Bitcoin SV Node team&nbsp;at&nbsp;<a href="https://nchain.com/en/">nChain</a>&nbsp;intends to keep its dragon logo for the time being.&nbsp;



[/vc_column_text][vc_column_text]



<h2>Applications &amp; Services</h2>



<h3><a href="https://bitcoinplayspokemon.com/">Bitcoin Plays Pokemon!</a></h3>



An application that will make you chuckle! &nbsp;<a href="https://bitcoinplayspokemon.com/">Bitcoin Plays Pokemon</a> demonstrates the power, efficiency, and speed of the Bitcoin SV blockchain by using the <a href="https://www.moneybutton.com/">Money Button</a> to charge a micropayment for every move in a Pokémon game. On the <a href="https://bitcoinplayspokemon.com/">site</a>, the provider explains:



“Swipe a MoneyButton to make a move!



All moves cost 1/10th of a penny and are considered a donation to the site.



The stream is about 6 seconds behind but the move will be displayed to the right instantly.”



Gamification at new levels—the BSV level!



<h3><a href="https://cryptograffiti.info/">Cryptograffiti</a>.info</h3>



A blockchain-explorer interface that allows users to view or write messages on the Bitcoin SV blockchain, including <a href="https://cryptograffiti.info/">pictures</a>. &nbsp;It has announced its <a href="https://cryptograffiti.info/stance">official stance</a> regarding the future of Bitcoin by posting on its website:



“2018 Bitcoin SV Roadmap has our full support.



2018 Bitcoin ABC Roadmap is unacceptable.”



<h3><a href="https://metanet.party/">metanet.party</a></h3>



A social media platform by “<a href="https://twitter.com/BitWhiterab">Whiterab.bit</a>,” it is dedicated to sharing developments on the Bitcoin SV chain.



<h2>Wallets</h2>



As we have <a href="https://bcommassociation.com/news/bitcoin-sv-bsv-weekly-jan-2-2019">previously summarized</a>, numerous wallets have announced exclusive support for BSV – &nbsp;<a href="https://www.cashpay.solutions/wallet/">CashPay,</a>&nbsp;<a href="https://centbee.com/">Centbee</a>,&nbsp;<a href="https://handcash.io/">HandCash</a>,&nbsp;<a href="https://play.google.com/store/apps/details?id=com.hivr.bch.bitcoincash.production&amp;hl=en_US">hivr</a>, <a href="https://www.pixelwallet.io/">Pixel Wallet</a>, and more.



Recently, we also learned of <a href="https://www.bitaddress.org/">bitaddress.org</a>, a fun and open-source JavaScript Bitcoin wallet generator—creating a pseudorandom wallet by typing in letters in a textbox or moving your mouse cursor around.



<h2>Developer Tools</h2>



The Bitcoin developer community is rapidly creating more tools for BSV which help power user-friendly Bitcoin applications. New tools include:



<h3><a href="https://t.co/qBtkFEbQuh">Datapay</a></h3>



With a focus on severe simplicity (a rare treat in the ecosystem), infamous Bitcoin contributor “<a href="https://twitter.com/_unwriter">unwriter</a>” has released <a href="https://t.co/qBtkFEbQuh">Datapay</a>, a fork of his previously developed Datacash. It is an open-source JavaScript library—powered by <a href="https://www.moneybutton.com/">Money Button</a>’s <a href="https://blog.moneybutton.com/2018/12/11/introducing-bsv-a-javascript-bitcoin-library-for-bitcoin-sv/">bsv library</a>—that allows writing data onto the Bitcoin SV blockchain in mere 4 steps. In his announcing Tweets, “unwriter” explains:



Datapay is unique in that it’s probably the only Bitcoin library that implements simple declarative programming.



Because of this declarative nature, for example you can implement language agnostic Microservices like BitShovel, by <a href="https://twitter.com/dfoderick">@dfoderick</a>



<h3><a href="https://t.co/D7FoR3sMLm">Awesome Bitcoin SV</a></h3>



Similar to <a href="http://bsvdevs.com/">BSVDevs.com</a>, <a href="https://t.co/D7FoR3sMLm">Awesome Bitcoin SV</a> by “monkeylord” offers a repository to keep track of useful Bitcoin services, applications, and tools for software developers.



<h3><a href="https://github.com/monkeylord/electrum-ecies">ECIES</a></h3>



A tool that allows Electron Cash’s encrypting and decrypting of messages in JavaScript on the BSV blockchain. Like <a href="https://t.co/qBtkFEbQuh">Datapay</a>, it is yet another application powered by <a href="https://www.moneybutton.com/">Money Button</a>’s <a href="https://blog.moneybutton.com/2018/12/11/introducing-bsv-a-javascript-bitcoin-library-for-bitcoin-sv/">bsv library</a>. <a href="https://github.com/monkeylord/electrum-ecies">ECIES</a> creator “monkeylord” <a href="https://github.com/unwriter/datapay/issues/1">explains</a> that it “may be useful in data cash.”



<h3><a href="https://whatsonchain.com/">WhatsOnChain</a></h3>



We like <a href="https://whatsonchain.com/">WhatsOnChain</a>’s new look! &nbsp;It shows mined blocks visually and other blockchain data in more user-friendly visual formats.



<h3><a href="https://testnet.bitcoincloud.net/">BSV Testnet Explorer</a></h3>



Maintained by the same developers of <a href="https://whatsonchain.com/">WhatsOnChain</a>, <a href="https://testnet.bitcoincloud.net/">https://testnet.bitcoincloud.net/</a> provides Bitcoin-application developers with a testnet BSV explorer—allowing them to view transaction propagation in a testing environment.



Blockchain explorers help power Bitcoin applications, such as the popular explorer offered by <a href="https://t.co/2R0NDLfMJl">Blockchair</a>, which <a href="https://twitter.com/Blockchair/status/1073233640866361344">announced</a> support for BSV.



<h2>New Visions for Bitcoin – from Dr. Craig S. Wright</h2>



nChain’s Chief Scientist Dr. Craig S. Wright has started a new series on his <a href="https://medium.com/me/stories/public">Medium</a> account, to begin revealing new applications and uses for Bitcoin (only possible on Bitcoin SV, because they use nChain intellectual property). &nbsp;In the powerful series, he plans to share his ideas about and expertise on new ground-breaking applications and services that the Bitcoin SV blockchain enables.



Wright’s <a href="https://medium.com/p/36f67fc044d7?source=your_stories_page---------------------------">first entry</a> in the series is entitled <a href="https://medium.com/p/36f67fc044d7?source=your_stories_page---------------------------">“An immutable file and data store,”</a> and focused on advanced file-storage solutions using the Bitcoin SV blockchain as their backend. The proposed solutions offer similar functionalities to Google Drive, Dropbox, or OneDrive, yet because of the security and efficiency of the Bitcoin SV blockchain, a more complete yet user-friendly service can be offered: 1. Because each file is secured in a new transaction, the security breach of one file does not affect the security of other files held in the same organised drive (because they are essentially separate). 2. Enabling cross-platform capability, since the same file is stored on the same secure blockchain (BSV); which one can think of as sharing one file on Google Drive with a user on Dropbox, for example, seamlessly and without the need to duplicate the file oraffecting the file path. 3. File authorisation can be organised in a hierarchical key structure, where the user keeps his privacy and complete control of his files—sharing merely what he needs to share for effective security. 4. Because storage is secured through a new key pair (a common secret) for every transaction (and therefore file), we are no longer required to use passwords; instead, a security device such as a smartphone can be used, allowing both greater security and ease of use.



To build such an immutable, efficient, yet user-friendly file-storage solution (“MetaDrive” or “bDrive”—you name it), see a more detailed and technical elaboration in Craig Wright’s article <a href="https://t.co/IqzgOPwa3c">here</a>.



<h2>Satoshi Shout-Out</h2>



A special “Satoshi Shout-Out” goes out to <a href="https://wmvinyl.com/">White Mountain Vinyl</a> (WMV), which started accepting BSV for payments. &nbsp; WMV makes and sells vinyl decals and signs. &nbsp;It explained on its <a href="https://wmvinyl.com/wm-vinyl-now-accepts-bitcoin/">website</a>:



“With Bitcoin SV (Satoshi’s Vision), we have a stable, enterprise-grade, bitcoin protocol implementation that is built to handle transactions, fast and inexpensively and we are excited to offer this option to our customers!



This payment option is already integrated it into our online payment system and because we will not have to pay the transaction fees associated with credit cards, or paypal payments, we are pleased to offer you a 10% discount off your total order by choosing the Bitcoin SV option during checkout! No coupon needed!



To further celebrate the event, we are offering limited-edition Bitcoin SV decals. Show your love and support for Bitcoin SV by showcasing this decal proudly for the world to see!”



Among its many products, WMV sells Bitcoin SV accepted here decals, using the newly-revealed <a href="https://bcommassociation.com/news/bitcoin-sv-bsv-unveils-logo-for-rebirth-of-original-bitcoin">Bitcoin SV logo</a> recommended by the bComm Association.



<figure class="wp-block-image"><img src="https://stag.bitcoinsv.io/wp-content/uploads/2020/09/3-bsv-accepted-here-gold-medium-300x111-1.png" alt="" class="wp-image-4187"/></figure>



<figure class="wp-block-image"><img src="https://stag.bitcoinsv.io/wp-content/uploads/2020/09/1-bsv-accepted-here-medium-300x111-1.png" alt="" class="wp-image-4188"/></figure>



The decals are easy for merchants to use as signs to announce they accept BSV for payments. &nbsp;View and order them <a href="https://wmvinyl.com/">here</a>.



For a more comprehensive list of Bitcoin SV services, applications, and developer tools, please visit <a href="https://bitcoinsv.io/services/">https://bitcoinsv.io/services/</a>.



If you would like your application or service listed in a future BSV Weekly update, please email us at <a href="mailto:info@bcommassociation.com">info@bcommassociation.com</a>.

Bitcoin SV (BSV) Weekly – Jan 9, 2019

The bComm Association unveils an updated logo for Bitcoin SV (ticker: BSV), chosen from public voting after three Twitter polls in a new form of decentralized marketing. &nbsp;The BSV logo is revealed on the 10th anniversary of the Bitcoin genesis block, to mark Bitcoin SV as rebirth of the original Bitcoin. &nbsp;A modernized update of the cryptocurrency’s classic logo, the new design reflects Bitcoin SV’s roots, while leading a new era for Bitcoin to professionalize.



Emerging from the November 15, 2018 contentious hard fork of Bitcoin Cash, BSV is dedicated to preserve Bitcoin’s original design. &nbsp;Named for the “Satoshi Vision” of Bitcoin’s creator Satoshi Nakamoto, Bitcoin SV’s mission is focused: &nbsp;restore the original Bitcoin protocol, keep it stable, and allow it to massively scale. &nbsp;Unlike paths chosen by Bitcoin Core (BTC) and Bitcoin Cash ABC (BCH/BAB), BSV’s roadmap will achieve the world’s new money used by billions of people, and the global public blockchain upon major enterprises can confidently build.



With modernized features, the new BSV logo conveys that Bitcoin is ready to grow up: • The B symbol is cleaner and stands upright rather than tilted forward or backward. &nbsp; • “Bitcoin SV” characters also stand upright. • “Bitcoin” begins with a capital B, rather than lower case. &nbsp; • “SV” appears in superscript – reflecting Satoshi Vision as the way forward, while keeping emphasis on the name Bitcoin. &nbsp; • The design color uses “dragon gold”, honouring the dragon logo of the <a href="https://bitcoinsv.io/">Bitcoin SV</a> full node implementation which birthed BSV.



This BSV logo was chosen after three Twitter polls of numerous design options developed by the <a href="https://bcommassociation.com/">bComm Association. </a>The first-ever organization dedicated to bCommerce (Bitcoin commerce), the bComm Association brings together developers, merchants, exchanges, miners and other Bitcoin network participants. &nbsp;bComm Association supports Bitcoin SV as the only stable, scalable blockchain that can achieve a world of bCommerce.



nChain’s Jimmy Nguyen, Founding President of the bComm Association, remarks: “Today marks 10 years since the birth of the Bitcoin blockchain, and this date has more importance now than ever. &nbsp;After too many years of wasteful diversions from the Satoshi Vision, we can now finally celebrate Bitcoin’s rebirth – unchained from experimental whims of developer teams who veered away from Satoshi’s original plan. &nbsp;The new BSV logo represents this pivotal moment for Bitcoin to grow up. &nbsp;In the spirit of Satoshi Vision, we are especially thrilled that BSV supporters around the world chose this logo after multiple rounds of online polling in a new paradigm of decentralized marketing.” 



Though Bitcoin SV remains a decentralized cryptocurrency system, the bComm Association will now urge the global Bitcoin ecosystem to adopt this new logo for BSV. &nbsp; &nbsp;



Nguyen adds:



“The <a href="https://bitcoinsv.io/">Bitcoin SV Node</a> is now the reference implementation for the BSV protocol. &nbsp;To differentiate the full node implementation from the BSV cryptocurrency, the Bitcoin SV Node team at <a href="https://nchain.com/en/">nChain</a> intends to keep its dragon logo for the time being. &nbsp; Occupying the 5th position in the Chinese zodiac, the dragon is the mightiest of the signs. &nbsp;It symbolizes leadership, ambition, good fortune, energy, and independence – perfect qualities for a reference implementation to lead Bitcoin to its destined world-changing future.”



In just over one month since emerging as a separate chain and token, the Bitcoin SV ecosystem has quickly grown. &nbsp;More than <a href="https://coinmarketcap.com/currencies/bitcoin-sv/">50 exchanges</a> now list BSV. &nbsp;<a href="https://bcommassociation.com/news/bitcoin-sv-bsv-weekly-dec-19-2018">Numerous wallets</a> have announcedexclusive support for BSV – including the user-friendly and popular <a href="https://www.cashpay.solutions/wallet/">CashPay,</a> <a href="https://centbee.com/">Centbee</a>, <a href="https://handcash.io/">HandCash</a>, <a href="https://play.google.com/store/apps/details?id=com.hivr.bch.bitcoincash.production&amp;hl=en_US">hivr</a>, and <a href="https://www.pixelwallet.io/">Pixel Wallet</a>. &nbsp;Top Bitcoin applications <a href="https://keyport.tv/">Keyport TV</a>, <a href="https://www.moneybutton.com/">Money Button</a>, <a href="https://www.yours.org/">Yours.org</a>, and others have moved exclusively to BSV. &nbsp;And BSV even has a dedicated tokenisation protocol in <a href="https://tokenized.cash/">Tokenized.</a> &nbsp;For a more comprehensive list of Bitcoin SV services, applications, and developer tools, please visit <a href="https://bitcoinsv.io/services/">https://bitcoinsv.io/services/</a>.



For 2019, the bComm Association is dedicated to support technical efforts for massive on-chain scaling of the Bitcoin SV blockchain. &nbsp;BSV has already seen the world’s largest blocks – 65 and 64MB – ever mined on a public blockchain. &nbsp;The bComm Association will work with the <a href="https://www.stresstestbitcoin.cash/">BCH Professional Stress Test</a> team, nChain and others to further test the BSV blockchain’s throughput capacity, and demonstrate Satoshi Vision is the corre<a></a>ct roadmap to much bigger blocks and big enterprise use. &nbsp;



FOR MEDIA INQUIRIES: &nbsp;Please email Ed Pownall at <a href="mailto:ed@pownall.eu">ed@pownall.eu</a>

Bitcoin SV (BSV) Unveils Logo for Rebirth of Original Bitcoin

Bitcoin SV (BSV) is rebirth of the original Bitcoin, designed to preserve Bitcoin’s fundamental design and fulfil the Satoshi Vision . &nbsp;BSV provides the <a href="https://nchain.com/en/blog/bitcoin-sv-means-business-why-bsv-is-the-enterprise-friendly-blockchain/">enterprise-friendly blockchain</a> – with a stable, scalable, secure, and regulation-friendly platform for businesses to confidently build upon.



In just one month since it emerged, the BSV ecosystem has quickly grown. &nbsp;Numerous Bitcoin applications and services have declared #WeChooseSV – by adding support for BSV, and in many cases, moving exclusively to BSV.



To track this progress the bComm Association is launching this BSV Weekly update. &nbsp;Join us on this exciting journey to make BSV the world’s new money and the global public ledger for the world’s enterprises. &nbsp;Together, let’s bring to life the Satoshi Vision.



Jimmy Nguyen



Founding President, bComm Association



&amp; your friendly BSV Global Ambassador



Wallets



Since BSV emerged, several wallets have announced exclusive support for BSV. &nbsp;In the past week, these include: ▪ <a href="https://play.google.com/store/apps/details?id=com.hivr.bch.bitcoincash.production&amp;hl=en_US">Hivr</a> – Hivr is a social network built around a BSV wallet, where users can post, like, or comment for free—without advertisements. The integrated wallet allows you to both spend and earn money for your content sharing. It recently<a href="https://twitter.com/hivrapp/status/1073628985953644545"> announced</a> that it will be running on Bitcoin SV going forward. ▪ <a href="https://bitproton.com/">BitProton.com</a> – a cold-storage and web-wallet solution for safely storing and spending Bitcoin. The project recently <a href="https://twitter.com/prayer0000/status/1073730364026310658">announced</a> that it will move from BTC to BSV before its release.



Before then, many of the top Bitcoin/Bitcoin Cash applications had already announced they are moving exclusively to BSV: ▪ <a href="https://centbee.com/">Centbee</a> – based in South Africa, a BSV-exclusive and user-friendly mobile wallet that allows transacting (and soon also chatting with <a href="https://twitter.com/Centbee/status/1068145720669216769">ChatPay</a>) on the Bitcoin SV blockchain through the mere use of mobile phone numbers. ▪ <a href="https://handcash.io/">HandCash</a> – based in Spain, another BSV exclusive, and one of the easiest-to-use mobile wallets out there. &nbsp;All you need for transacting is a unique $handle, as easy to remember as a user name (so you do not need to deal with long, clumsy Bitcoin addresses). HandCash also enables businesses to easily integrate BSV payments into their applications and games by using its tool <a href="https://cashport.io/">CashPort</a>. &nbsp;For example, check out <a href="http://www.Keyport.tv">Keyport.TV</a>, and earn BSV directly by creating video content, or simply go and watch. ▪ <a href="https://www.cashpay.solutions/wallet/">CashPay Wallet</a> – a BSV-exclusive and user-friendly wallet that allows the purchase of any Amazon product through the in-app tool <a href="http://www.cryptonize.it">cryptonize.it</a>. ▪ <a href="http://pixelwallet.icu/">Pixel Wallet</a> – a first of its kind and one of the most fun wallets, PixelWallet allows you to encrypt and send Bitcoin transactions through a picture file. This means that you can send BSV with any application for sending images: MMS, WhatsApp, WeChat, and more. ▪ <a href="https://simply.cash/">Simply Cash</a> – a BSV-exclusive and user-friendly wallet for simple transactions.



In addition, many multi-coin wallet applications have added support for Bitcoin SV: ▪ <a href="https://atomicwallet.io/">Atomic wallet</a> ▪ <a href="https://bitpie.com/">Bitpie</a> ▪ <a href="https://www.coinomi.com/en/">Coinomi</a> ▪ <a href="https://edge.app/">Edge</a> ▪ <a href="https://guarda.co/">Guarda</a> ▪ <a href="https://hodler.tech/">Hodler Tech</a>



Exchanges



Nearly 50 exchanges now list BSV. &nbsp;These include some of the biggest global exchanges, such as <a href="https://www.binance.com/">Binance</a>, <a href="https://www.bitcoin.de/">Bitcoin.de</a>, and <a href="https://huobi.com/">Huobi</a>.



Recently, <a href="https://ShapeShift.io">ShapeShift.io</a> and <a href="https://simpleswap.io/">SimpleSwap</a> joined the list by adding BSV support.



Applications &amp; Services ▪ <a href="https://www.bitstocks.com/">Bitstocks</a> – the London-based cryptocurrency market advisory and investment firm. &nbsp;In a ground-breaking move, has announced <a href="https://coingeek.com/bitstocks-reveals-gravity-groundbreaking-bitcoin-banking-ecosystem/?utm_content=81350675&amp;utm_medium=social&amp;utm_source=twitter&amp;hss_channel=tw-2800495464">Gravity</a> – &nbsp;a comprehensive Bitcoin banking ecosystem all in a single app. Services will include OTC trading, advisory services, lending, merchant services, purchasing derivates, and simply storing and spending your BSV. To be launched in the first half of 2019, Gravity will become the first fully transparent banking platform – using BSV as its base currency. ▪ <a href="http://www.memo.cash">Memo.cash</a> – the popular blockchain-powered social messaging service now also operates on Bitcoin SV. Users can post, comment, or like posts, which are stored in OP_RETURN field. &nbsp;In addition, users can now search for content on Memo using <a href="https://searchbsv.com/">Search BSV</a>. ▪ <a href="https://twitter.com/POPbyHandCash">POP!</a> – POP! (by HandCash) allows merchants to easily accept BSV payments with a point-of-sale handheld device, which integrates with Pop! &nbsp;HandCash recently showed the usefulness and speed of its integrated solution in this video <a href="https://coingeek.com/handcashs-pop-speeds-up-bitcoin-sv-payments-for-merchants/">here</a>. ▪ <a href="https://bcb-atm.com/">BCB ATM</a> – a digital ATM machine offers easy offline and instantaneous buys of BSV.



Blockchain Explorers



Last week, the popular block explorer<a href="https://blockchair.com/"> Blockchair</a> launched a new <a href="https://blockchair.com/bitcoin-sv">Bitcoin SV explorer</a>. &nbsp;It announced the move with a <a href="https://twitter.com/Blockchair/status/1073233640866361344">tweet</a> declaring that “[we] are launching a Bitcoin SV explorer – the most powerful out there!”



Blockchair joins many other BSV explorers that emerged quickly, including: &nbsp;<a href="https://svblox.com/">svblox.com</a>, <a href="https://bchsvexplorer.com/">bchsvexplorer.com</a>, <a href="https://bitfire.io/blocks">Bitfire.io</a>, <a href="http://whatsonchain.com/">whatsonchain.com</a>, <a href="https://bsvexplorer.io/">Bitcoin Cash SV Explorer</a>, <a href="https://www.bitcoinsvexplorer.com/">Bitcoin SV Explorer</a>, and <a href="https://bsvexplorer.info/">BSV Explorer</a>.[/vc_column_text]



Developer Tools



The Bitcoin developer community is rapidly creating more tools for BSV. &nbsp;These include: ▪ <a href="http://www.bitdb.network">BitDB</a> – “an autonomous database that continuously synchronizes itself with Bitcoin” created by respected independent Bitcoin developer “<a href="https://twitter.com/_unwriter">unwriter</a>.” &nbsp;BitDB helps power other Bitcoin applications, such the <a href="http://www.oyo.cash">oyo.cash</a> and <a href="http://www.trends.cash">trends.cash</a> search engines for the Bitcoin SV blockchain. &nbsp;Unwriter captured attention by writing a powerful Medium blog post on why the developer now chooses to build projects exclusively on Bitcoin SV. Read Unwriter’s statement and reasons for choosing SV <a href="https://t.co/vH4DAXBJFI">here</a>. ▪ <a href="https://blog.moneybutton.com/2018/12/11/introducing-bsv-a-javascript-bitcoin-library-for-bitcoin-sv/">bsv</a> – a Javascript Bitcoin library for Bitcoin SV created by Money Button. bsv provides a library for cryptography, key management, and transaction building on the Bitcoin SV blockchain. It is based on bitcore-lib-cash, which itself is a fork of bitcore-lib. Because BitPay does not currently maintain a javascript library for Bitcoin SV, Money Button decided to maintain the library itself for the Bitcoin SV community. bsv is nearly equivalent to bitcore-lib-cash, except that it defaults to the original Bitcoin address format. ▪ <a href="http://bsvdevs.com/">BSVDevs.com</a> – a developer resource centre which compiles Bitcoin SV tools. &nbsp;Eli Afram described the new site in a recent <a href="https://twitter.com/justicemate/status/1073470811866976256">tweet</a>: &nbsp;BSVdevs.com enables the community to share developer tools, APIs, interesting projects, wallets, and more. Adding your project is easy.



For a more comprehensive list of Bitcoin SV services, applications and developer tools, please visit <a href="https://bitcoinsv.io/services/">https://bitcoinsv.io/services/</a>.



If you would like your application or service listed in a future BSV Weekly update, please email us at info@bcommassociation.com.

Bitcoin SV (BSV) Weekly – Dec 19, 2018

The highly anticipated <a href="https://coingeekweek.com/" target="_blank" rel="noreferrer noopener">CoinGeek Week</a> conference has drawn to a close and to say that it was a huge success is putting it mildly. The conference attracted a slew of individuals that have been, and will continue to be, the primary driving forces behind the only cryptocurrency adhering to the original <a href="https://coingeek.com/original-bitcoin-reborn-bitcoin-sv-bsv-bch-hash-war-ends/" target="_blank" rel="noreferrer noopener">Satoshi Vision</a>, as well as a huge crowd determined to help shape the future. There was a lot of ground covered in the short four days allocated to the conference, with some exciting new projects being announced.



Bitstocks is preparing to introduce Gravity, a banking ecosystem for the cryptocurrency community. Gravity is going to offer an array of products—banking accounts, loans, debit cards, over-the-counter trading and more—and will use <a href="https://coingeek.com/bitcoin-sv-closest-original-bitcoin-protocol-says-ryan-x-charles/" target="_blank" rel="noreferrer noopener">Bitcoin SV</a> as the supporting cryptocurrency. More about the Gravity project can be found in Bitstocks’ <a href="https://www.youtube.com/watch?v=w8I-yRLheXk&amp;feature=youtu.be" target="_blank" rel="noreferrer noopener">YouTube video</a>.



The developers behind the <a href="https://coingeek.com/centbee-wallet-sends-bitcoin-bch-phone-contacts-just-taps/" target="_blank" rel="noreferrer noopener">Centbee wallet</a> have announced a new feature that will be coming soon. It will combine a social network with a wallet, allowing users to send money to their friends while chatting. There is also a merchant software developer’s kit (SDK) in the works, which will allow any merchant to easily integrate Bitcoin SV payments into its point of sale system.



HandCash announced that it is bringing an iOS version of its wallet to market this month. It will also offer HandCash for Apple Watch sometime during the spring of 2019. Developers also discussed <a href="https://coingeek.com/alex-agut-cashport-takes-care-complexities-businesses-bitcoin-bch-video/" target="_blank" rel="noreferrer noopener">CashPort</a>, the system that allows apps and games to connect to <a href="https://coingeek.com/handcash-developers-release-bitcoin-bch-developers-kit/" target="_blank" rel="noreferrer noopener">HandCash</a> in order to allow users to make micropayments.



The White Company, which offers an array of blockchain and crypto products, has announced that it is adding support for Bitcoin SV. The company offers, among other things, a cryptocurrency debit card and has also teamed up with REM, a blockchain-based rewards company, to allow consumers to earn points when they use The White Card. The card is expected to be released before the end of the year.



A new digital ATM offered by BCB ATM was shown off during CoinGeek Week, as well. While a crypto ATM isn’t exactly news, the fact that the company’s new ATM offers 0-confirmation transactions certainly is something worth a great deal of attention.



One of the more exciting revelations was <a href="https://coingeek.com/dr-craig-wright-unveils-game-changing-bitcoin-project-metanet-video/" target="_blank" rel="noreferrer noopener">MetaNet</a>, which was introduced by nChain and Dr. Craig Wright. Metanet is basically one global network that is built on the blockchain. Said Wright, “What we’re going to actually create is a replacement for the Internet. The internet becomes a sidechain. I don’t care how as a peer network you distribute data, I care that you distribute it. If you have HandCash or near-field or IP or private networks or X.25, it’s a value network. The entire global system connected commercially.



Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for <a href="https://coingeek.com/resources/" target="_blank" rel="noreferrer noopener">Bitcoin</a> as fast, frictionless, electronic cash.

NEW, EXCITING BITCOIN SV PROJECTS ANNOUNCED DURING COINGEEK WEEK

20 November 2018 – Bitcoin SV, the new full node implementation for Bitcoin Cash (BCH) mined a 64MB block, the world’s largest ever on a public blockchain. The huge block was mined by CoinGeek Mining, during an on-going Professional Stress Test of the BCH network. Just one hour before, a 38MB block was mined, also using the Bitcoin SV implementation, by SVPool, a personal initiative of nChain’s Chief Scientist Dr. Craig Wright. That 38MB block held the record for largest block mined on a public blockchain until the 64 MB block dwarfed it.



The BCH Professional Stress Test is designed to test the BCH blockchain’s throughput capacity. The 64 MB block came at block height 557335 and the 38 MB block came at block height 557333 on the BCH network. Powered by Play.BCH.cash and organized independently of any BCH full node implementation team, the testing group also ran November 10 pre-test, in which Bitcoin SV mined five 32 MB blocks, which were then the largest ever blocks mined on a public blockchain. Bitcoin SV thus continues to demonstrate its record-setting capabilities, with larger blocks now mined of 64 and 38 MB.



Bitcoin SV is currently in the midst of a “hash war” with Bitcoin ABC to be the leading BCH implementation, with miner votes that began with the November 15 BCH network upgrade. Although Bitcoin ABC has taken an early lead, its support relies heavily upon “rented” hash borrowed by its backers (Bitcoin.com and Bitmain Technologies) from miners on the rival Bitcoin Core (BTC) network ; in contrast, the hash backing Bitcoin SV is sustained Proof of Work from miners committed to support the BCH network on an on-going basis and which should count as legitimate votes for the “Nakamoto consensus” that determines protocol rules according to the original Bitcoin white paper.



The Professional Stress Test results confirmed that Bitcoin SV is correct about its scaling roadmap: the BCH blockchain can handle much larger blocks and quickly scale for big enterprise use. Named for the “Satoshi Vision” of Bitcoin’s creator Satoshi Nakamoto, Bitcoin SV intends to restore the original Bitcoin protocol, keep it stable, and allow it to massively scale to a global network used by billions of people. For the recent November 15 protocol upgrade, Bitcoin SV lifted its default maximum block size to 128MB from the prior 32MB; that opened the door to the record-breaking 64MB and 38MB blocks. In contrast, Bitcoin ABC has kept its default block cap at 32MB, and is taking a slower scaling approach.



Bitcoin SV’s lead developer Daniel Connolly remarks:



“This is the next in a series of record-breaking blocks mined by Bitcoin SV. I believe we will see even bigger blocks reaching closer to our new 128MB default limit, especially when we eventually lift the default block cap altogether so miners can configure their own limits. The Satoshi Vision requires massive blocks, so businesses can do more complex transaction types and miners can earn more transaction fees.”



Bitcoin SV Technical Director Steve Shadders adds:



“For Bitcoin to achieve the Satoshi Vision, major businesses need confidence to build on a blockchain that has block capacity to support enterprise-level applications and projects, not just transactions between individual users. By locking down the protocol we can focus all our attention on scaling solutions that are needed to demonstrate that Bitcoin is ready for serious investment. That is what



distinguishes Bitcoin SV from the other implementations, and is exactly why miners and businesses should choose Bitcoin SV over Bitcoin ABC to unlock Bitcoin’s massive potential.”



The Bitcoin SV project was created at the request of and sponsored by Antiguan-based CoinGeek Mining, with development work initiated by nChain. The project is owned by the Antiguan-based bComm Association on behalf of the global BCH community, and the Bitcoin SV code is made available under the open source MIT license. For more information about Bitcoin SV, visit <a href="https://bitcoinsv.io/" target="_blank" rel="noreferrer noopener">www.bitcoinsv.io</a>.

Bitcoin SV Mines 64 MB Block on Bitcoin Cash, Largest Ever on a Public Blockchain

The upcoming Bitcoin Cash (BCH) hard fork on November 15 will likely cause two branches of the blockchain to exist, at least temporarily. Some actors believe both branches will persist, effectively creating two “coins.” Other observers believe that one chain will die off with the alternate “coin” simply becoming unusable, and leaving a single “coin” once everything is resolved. Regardless of the final outcome, any coins that exist prior to the hard fork will exist on both branches whilst they remain viable.



If a user only does standard transactions with these old coins, the transactions will happen on both branches and wallet contents will remain the same. However, there is a practice being advocated called “coin splitting” which taints coins on one branch with inputs unrecognised on the other branch which effectively severs the connection between coins on either branch.



For the unskilled, this practise is fraught with peril. Even for highly skilled engineers, it is risky and must be tested extremely carefully before using it with live coins. There are several methods that can be used and many permutations of each given the combinations of differing rulesets on each chain, the use of P2SH versus bare scripts and the various quirks of how and when transactions are rejected by a node. There is a VERY high risk of making coins un-spendable on at least one chain using these techniques, rendering the coins burned.



Recommendations:



1. For users and coin holders, the safest way to deal with your coins during the hash war period is simply to have them in a wallet you control and do nothing. After it is resolved, your coins will still be there on whichever chain survives.



2. Do not assume that exchanges will split your coins safely for you. A hard fork without replay protection is a rare scenario and there are many consensus rules unique to this scenario that must be accounted for. Mistakes can happen even on exchanges.



3. Do not use op codes to split coins (e.g. OP_CHECKDATASIG, OP_MUL). The rules around when and if transactions containing these op codes are accepted or rejected are complex and have subtle differences on each chain. The intended goal of this is to create a transaction that will be rejected by one chain leaving two different coins on each chain. However, It is entirely possible (even easy) to create a transaction spending to outputs containing these op codes that will be accepted by both chains. Once this happens, the coins will exist on both chains but be unspendable and effectively burnt on one chain.



4. Exploitation of unexecuted branches of script code to hide illegal op codes from the interpreter should not be assumed to be safe. Not only are these tools needlessly complex and prone to error. There is also an inconsistency in behaviour between disabled versus new op codes that will likely be resolved at a later date. If this is done it will not be retrospective however the proliferation of tools using this technique exacerbates the risk of people using them unwittingly at a later time.



5. If you must attempt to split coins or build tools for others to do so, the safest way is to mix your coins with an input that does not exist on one chain. The most likely source of these single chain inputs is coins mined after the chains diverge as they can only exist on one chain.

Bitcoin Cash (BCH) Protocol Upgrade: Coin Splitting Advisory

We recently received inquiries from several cryptocurrency exchanges about the upcoming November 15 Bitcoin Cash (BCH) protocol upgrade and the role played by Bitcoin SV. There appears to be confusion by some exchanges and other cryptocurrency service providers about Bitcoin SV, perhaps caused by misleading statements made by supporters of other competing BCH implementations (such as Bitcoin ABC).



We provide a Coin Splitting Advisory, which cautions against risks of immediately splitting BCH coins into BCH-SV and BCH-ABC coins until the contentious BCH upgrade is resolved.



In addition, although we previously issued a notice on <a href="https://bitcoinsv.io/2018/11/05/bitcoin-cash-bch-november-15-2018-protocol-upgrade-notice-to-cryptocurrency-exchanges-bitcoin-cash-wallet-operators/">November 5</a>, we again answer questions about Bitcoin SV to clear up any remaining possible confusion.



What is Bitcoin SV?



Bitcoin SV is a new full node implementation for Bitcoin Cash (BCH). We are not intending to create a new Bitcoin variant or token. We are not asking exchanges to list a new Bitcoin SV or BSV token.



Instead, Bitcoin SV gives BCH miners another choice for consensus rules they wish to see implemented in Bitcoin Cash (competing with rule sets offered by Bitcoin ABC, and other existing BCH implementations). As set forth in the original Bitcoin white paper, it is up to miners’ voting with their hash power (the Nakamoto consensus mechanism) to decide rules for the network.



How Much Miner Hash Supports Bitcoin SV?



Bitcoin SV has now crossed well over majority support of total BCH mining hash. According to data on <a href="https://cash.coin.dance/blocks" target="_blank" rel="noreferrer noopener">Coin.dance</a>, as of November 14, it is estimated that 72-78% of total BCH network hash power supports Bitcoin SV, compared to 12-22% support for Bitcoin ABC. (ABC is tied for 3rd place with Bitcoin Unlimited, which is remaining neutral and is compatible with both SV and ABC). This means Bitcoin SV stands a strong chance of becoming the dominant implementation for BCH.



<h3>Coin Splitting Advisory</h3>



We have seen that some exchanges and other service providers are discussing plans to split BCH coins into BCH-SV and BCV-ABC coins. The following caution is offered to actors in the Bitcoin Cash space who are intent on splitting coins. There are numerous techniques to do this with various levels of complexity and many carry a very high risk of making coins unspendable.



Recommendations:



1. For users and coin holders, the safest way to deal with your coins during the BCH hash war period is simply to have them in a wallet you control and do nothing. After it is resolved, your coins will still be there on whichever chain survives.



2. Do not use op codes to split coins (e.g. OP_CHECKDATASIG, OP_MUL). The rules around when and if transactions containing these op codes are accepted or rejected are complex and have subtle differences on each chain. The intended goal of this is to create a transaction that will be rejected by one chain leaving two different coins on each chain. However, it is entirely possible (even easy) to create a transaction spending to outputs containing these op codes that will be accepted by both chains. Once this happens, the coins will exist on both chains but be unspendable and effectively burnt on one chain.



3. Exploitation of unexecuted branches of script code to hide illegal op codes from the script interpreter should not be assumed to be safe. Not only are these tools needlessly complex and prone to error. There is also an inconsistency in behaviour between disabled versus new op codes that will likely be resolved at a later date. If this is done, it will not be retrospective however the proliferation of tools using this technique exacerbates the risk of people using them unwittingly at a later time.



4. If you must attempt to split coins or build tools for others to do so, the safest way is to mix your coins with an input that does not exist on one chain. The most likely source of these single chain inputs is coins mined after the chains diverge as they can only exist on one chain.



<h3>Additional Advisory</h3>



<ul><li>No transaction replay protection is in place on Bitcoin ABC or Bitcoin SV.</li><li>Unlike past BCH protocol upgrades, the November 15 upgrade will be contentious, and it is uncertain how long it will take before a dominant chain emerges between Bitcoin SV and Bitcoin ABC.</li><li>You should evaluate risks and consider whether to suspend Bitcoin Cash deposits/withdrawals, and possibly trading, until one chain emerges as dominant.</li><li>We highly recommend installing a Bitcoin SV node to be prepared in the case that SV becomes dominant so that your exchange can continue Bitcoin Cash trading with minimal delay and disruption. At our <a href="https://bitcoinsv.io/" target="_blank" rel="noreferrer noopener">BitcoinSV.io</a> website, you can find out more information about the Bitcoin SV implementation, and a link to our <a href="https://github.com/bitcoin-sv/bitcoin-sv/releases" target="_blank" rel="noreferrer noopener">GitHub repository</a> where your team can download the Bitcoin SV code.</li></ul>



Because miners’ vote decides, we believe exchanges, wallet and service providers should not pick a side or take any public position in favor of or against any competing implementation. Instead, it is in your users’ best interests for your company to publicly remain neutral. For example, <a href="https://www.bitfinex.com/posts/310" target="_blank" rel="noreferrer noopener">Bitfinex</a> has taken an appropriately neutral stance, informing users that it “will not advocate for or against any particular fork, and miners have full prerogative to commit their hashing power to whichever projects they choose.” While remaining neutral until a dominant BCH chain emerges, you should also prepared by running a Bitcoin SV node now.



We are committed to the success of Bitcoin Cash, and look forward to the hash vote of legitimate sustained mining hash ultimately deciding the future direction of BCH.



— Bitcoin SV project team

Bitcoin SV Notice to Cryptocurrency Exchanges, Wallet & Service  Providers:  Advisory about BCH Protocol Upgrade and Coin Splitting

On November 15, 2018, the Bitcoin Cash (BCH) network will undergo a scheduled protocol upgrade. This protocol upgrade has been different to previous upgrades due to differences in opinion as how best to evolve the Bitcoin Cash network to continue to meet the demands of enterprises and consumers who support Bitcoin Cash. We have developed Bitcoin SV, a new full node implementation for Bitcoin Cash, designed to support the original “Satoshi Vision” of Bitcoin. We are asking BCH miners to vote for the Bitcoin SV implementation over competing implementations (such as Bitcoin ABC) using their hash power under Nakamoto consensus rules. As the November 15 date nears, we provide exchange operators and wallet providers this update about Bitcoin SV and the protocol upgrade’s short-term material impact on their operations.



<h3>What is Bitcoin SV?</h3>



With Bitcoin SV, we are not seeking to create a new Bitcoin variant and we are not intending to create a new Bitcoin SV token. Instead, Bitcoin SV merely gives BCH miners another choice of implementation (competing with Bitcoin ABC and other existing BCH implementations) for miners who want to support the original Satoshi Vision for Bitcoin.&nbsp;&nbsp; As set forth in the original Bitcoin white paper, it is up to miners’ voting with their hash power (the Nakamoto consensus mechanism) to decide rules for the network.



At our <a href="https://bitcoinsv.io">BitcoinSV.io</a> website, you can find out more information about the Bitcoin SV implementation, and a link to our <a href="https://github.com/bitcoin-sv/bitcoin-sv/releases" target="_blank" rel="noreferrer noopener">GitHub repository</a> where the Bitcoin SV code can be downloaded.



<h3>What Will Happen After the November 15 Protocol Upgrade?</h3>



<ul><li>A temporary Bitcoin Cash chain split is imminent on November 15th between Bitcoin SV and Bitcoin ABC. (Bitcoin Unlimited, another key BCH implementation, intends to remain neutral and be compatible with both Bitcoin SV and Bitcoin ABC rule sets, as a configurable option.)</li><li>There will likely be a period of time before this temporary chain split is resolved, while miners are voting with their hash power.</li><li>Significant miner hash power (over 40% of the current BCH hash total) is supporting Bitcoin SV. Therefore, the Bitcoin SV consensus rules stand a very strong chance of becoming the dominant implementation on the BCH blockchain.</li><li>No transaction replay protection is in place on Bitcoin ABC or Bitcoin SV.</li></ul>



<h3>Which Chain Should be Recognized as Bitcoin Cash?</h3>



We believe that exchanges, as well as other BCH business operators, should recognize as Bitcoin Cash (and the ticker symbol BCH) the longest chain with the most legitimate, sustained Proof of Work. The Nakamoto consensus procedure is how Bitcoin’s decentralized system is meant to work, rather than leaving the Bitcoin Cash name and BCH ticker symbol forever in the control of any group(s) who may have initiated it or claim to control it. We do not ask exchanges to pick a side between Bitcoin SV, Bitcoin ABC or other implementations. In fact, exchanges should remain neutral because their function is not to decide the technical roadmap for Bitcoin Cash or choose between implementations of BCH.



<h3>Exchanges: What Should They Do Before the November 15 Protocol Upgrade?</h3>



<ul><li>Immediately install a Bitcoin SV node: We highly recommend that exchanges immediately install a Bitcoin SV node to be prepared in the case that SV becomes dominant so that exchanges can continue Bitcoin Cash trading with minimal delay and disruption to users.</li><li>Consider suspending BCH deposits/withdrawals. Neither Bitcoin SV nor Bitcoin ABC have implemented transaction replay protection, as the intention is for only one chain to survive. We recommend that exchanges evaluate risks and consider, as a precaution, whether to suspend Bitcoin Cash deposits/withdrawals until one chain emerges as dominant. If exchanges continue to operate during this period, it is highly recommended that transactions continue to support existing consensus rules and are broadcast to both chains until such time a dominant chain emerges.</li></ul>



<h3>Wallet Operators: What Should They Do for the November 15 Protocol Upgrade?</h3>



<ul><li>Immediately install a Bitcoin SV node. We highly recommend that BCH wallet operators also immediately install a Bitcoin SV node to be prepared in the case that SV becomes dominant to avoid disruption to users.</li><li>Notify Users of Possible Delays. It would be prudent to notify users that they may experience some delays in sending and receiving BCH after the protocol upgrade and resulting hard fork.</li><li>Risks of Wallets Accepting DSV Transactions.&nbsp;&nbsp;Bitcoin.com has announced intention for its wallet to run the new Bitcoin ABC v 0.18.2 client after the protocol upgrade and before one chain emerges as dominant. The new Bitcoin ABC client adds a controversial new OP_code (OP_DATASIGVERIFY). In its official statement posted November 2, 2018, Bitcoin.com stated that “All services on Bitcoin.com” will send BCH originating from an output using the new OP_code. We understand Bitcoin.com may be updating its statement to&nbsp;either correct or more explicitly specify whether its wallet service will continue to broadcast transactions without the new OP_code during the upgrade. Our recommendation remains that all wallet services should support existing consensus rules, which will ensure transactions are supported by both chains until a dominant chain emerges. Wallet operators who run Bitcoin ABC 0.18.2 and include this contentious OP_code as default run a real risk of users losing their funds if the chain supporting OP_DATASIGVERIFY does not eventually survive.</li></ul>



[Updated, 6 November 2018]



The Bitcoin SV project is committed to the success of Bitcoin Cash and fulfilling the original Satoshi vision for Bitcoin. Our team members stand ready to answer any questions you may have. Please email support@bitcoinsv.io with any questions.

BITCOIN CASH (BCH) NOVEMBER 15, 2018 PROTOCOL UPGRADE – NOTICE TO CRYPTOCURRENCY EXCHANGES & BITCOIN CASH WALLET OPERATORS

The wait is over— public Bitcoin BCH mining pool SVPool is now open for business.



Effective today, <a href="https://svpool.com/" target="_blank" rel="noreferrer noopener">SVPool</a> is open to all public miners on the Bitcoin BCH network. The public BCH mining pool is a personal initiative of nChain Chief Scientist Dr. Craig S. Wright. SVPool (meaning Satoshi Vision Pool) is for BCH miners who support the original Satoshi Nakamoto vision for Bitcoin and want to generate more long-term revenue. BTC miners who believe in Bitcoin’s original vision are also invited to begin mining BCH with SVPool.



SVPool will initially offer zero fees to miners, and launches with initial Pay-per-last-N-shares (PPLNS). It plans to add more features and Pay-per-share plus (PPS+) options in November.



At press time, hundreds of miners and mining groups have already pre-registered for SVPool. Demonstrating truly global interest, the pre-registrants come from the United States, China, United Kingdom, Canada, Australia, India, Spain, South Africa, Brazil, Germany, South Korea, Japan, Malaysia, and many other countries.



SVPool mined its first BCH block on October 10. Since then, during an invitation-only beta period, it has already mined over 50 blocks. On a seven-day basis ending October 21 with just beta users, SV Pool already accounts for approximately 3% of BCH blocks mined, according to Coin.dance data.



<figure class="wp-block-image size-full"><img loading="lazy" width="877" height="585" src="https://theoffgrid.net/wp-content/uploads/2022/04/Pools-Hashrate.png" alt="" class="wp-image-974" srcset="https://theoffgrid.net/wp-content/uploads/2022/04/Pools-Hashrate.png 877w, https://theoffgrid.net/wp-content/uploads/2022/04/Pools-Hashrate-300x200.png 300w, https://theoffgrid.net/wp-content/uploads/2022/04/Pools-Hashrate-768x512.png 768w" sizes="(max-width: 877px) 100vw, 877px" /></figure>



SVPool proudly runs Bitcoin SV, the new full node implementation of Bitcoin BCH designed to fulfil the original Satoshi white paper’s vision for Bitcoin. Other competing BCH implementations (such as Bitcoin ABC) seek to experiment with unnecessary technical changes to the Bitcoin protocol, which will disturb the economic genius of Satoshi’s system. In contrast, Bitcoin SV’s roadmap is easy to understand: restore the original Satoshi protocol, keep it stable, enable the BCH network to massively scale, and professionalize Bitcoin. Aimed at business users, the SV implementation will allow global enterprises to confidently operate and build their major projects on a stable, scalable BCH protocol. It’s time for Bitcoin to grow up, and this path will generate more revenue for miners. To learn more, visit the Bitcoin <a href="https://bitcoinsv.io/">SV website</a>.



Dr. Craig S. Wright explains:



“If you believe in Bitcoin’s original vision, you believe in Bitcoin SV and SVPool. For too long, developer groups have repeatedly tried changing Bitcoin. The original Satoshi protocol for Bitcoin does not need to be fixed. It has everything BCH needs to massively scale, support tokenization, smart contracts and other advanced features, and become the only global public blockchain. Just like the Internet has a stable protocol, Bitcoin needs a stable protocol so businesses can build upon a rock solid foundation rather than constantly moving sand. That is why we are restoring the Satoshi Vision through BCH, and I ask miners of the world to join me in SVPool.”



SVPool also supports Bitcoin SV’s plan to immediately begin massive scaling, by increasing the default maximum block size to 128MB as a step to even bigger blocks. Bitcoin SV will also allow miners to configure their own maximum “accept” block size to create a competitive marketplace. Increased scaling now is critical to reach GB and bigger size blocks, which will enable higher BCH transaction volume by major enterprises and more transaction fees for miners. This will ensure long-term profit for miners to compensate for the next block reward halving in 2 years (reducing the block reward from 12.5 to 6.25 BCH) and every four years after that.



Like Bitcoin SV, SVPool has a “miners choice, miners first” philosophy. Miners are put first by stabilizing the BCH protocol, rather than repeatedly debating feature changes imposed by developer groups.



Dr. Wright further observes: “We must end this thinking that developer groups are in charge of Bitcoin, and that developers can make experimental changes to the protocol when they have little or no investment in hashing power. Miners have by far the most money invested in BCH and provide the network’s computing power and security. It is time for miners to stand up, use their hash power voice, and take their rightful place to direct the future of Bitcoin BCH.”



With its miner focus, SVPool strives to ensure miners have a great experience. This includes providing a world-class highly responsive customer service team in both English and Chinese languages. SVPool will also listen to customers to learn what additional pool features are important to miners. SVPool is proudly managed by CoinGeek Mining. Taras Kulyk, CEO of CoinGeek Mining, states:



“CoinGeek stands behind Craig Wright, Bitcoin SV, and SVPool in the knowledge that BCH is the only true Bitcoin that fulfills the Satoshi Vision.&nbsp; We are proud&nbsp;to support SVPool, and invite all Bitcoin miners of the world to join us, and help make Bitcoin what it was always meant to be.”



In addition, CoinGeek invites all miners to the CoinGeek Week Miners Day, which is part of the <a href="https://coingeekweek.com/" target="_blank" rel="noreferrer noopener">CoinGeek Week</a> Conference in London this November. The SVPool and CoinGeek Mining team will be on-hand to discuss how you can do your part in making Bitcoin BCH realize its full potential. Secure your seat today via <a href="https://www.eventbrite.co.uk/e/coingeek-week-blockchain-cryptocurrency-conference-london-tickets-49939393069" target="_blank" rel="noreferrer noopener">Eventbrite</a> for the three-day conference that’s shaping up to be the essential Bitcoin BCH conference this fall.

SVPool is open for business for Bitcoin miners

nChain, the global leader in research and development of blockchain technologies, announces the creation of Bitcoin SV, a new full node implementation of the original Bitcoin protocol now restored in the form of Bitcoin Cash (BCH).&nbsp; Reflecting its mission to fulfil the vision of Bitcoin’s founder Satoshi Nakamoto, the project name represents the “Satoshi Vision” or SV.&nbsp;&nbsp; Created at the request of leading BCH mining enterprise CoinGeek and other miners, Bitcoin SV is intended to provide a clear BCH implementation choice for miners who support Bitcoin’s original vision, over implementations that seek to make unnecessary changes to the original Bitcoin protocol.



Earlier this week, CoinGeek made a&nbsp;<a href="https://coingeek.com/statement-calvin-ayre-coingeek-bitcoin-protocol/">clear statement</a>&nbsp;about using its BCH hash power to support a Bitcoin protocol direction that is consistent with the Satoshi Vision.&nbsp; CoinGeek’s announcement made clear that it will not support implementations or projects that make unnecessary changes to the original Bitcoin protocol.&nbsp; &nbsp;CoinGeek founder Calvin Ayre explains:



“Because miners should drive the roadmap in the Bitcoin space, CoinGeek and other miners asked nChain to create a professionally-driven implementation of the Bitcoin full node software (for use on BCH) that restores the original Bitcoin protocol.&nbsp; CoinGeek is sponsoring the project and intends to mine with Bitcoin SV.&nbsp; We invite other BCH miners to join us in using Bitcoin SV to voice their support for the Satoshi Vision.”



nChain Group CEO Jimmy Nguyen comments:



“Answering the call of miners, nChain is happy to provide technical capabilities needed to support Bitcoin SV.&nbsp; Once the Bitcoin protocol is fully restored and maintained, global businesses and developers can reliably build robust applications, projects and ventures upon it – just as they reliably build upon the long-stable Internet protocols.&nbsp; The future of Bitcoin is big blocks, big business, and big growth.&nbsp; Bitcoin SV is an important step toward that big future by advancing the professionalization of Bitcoin.”



<h2>Roadmap</h2>



A comprehensive roadmap is in development, but the first goal is to have the initial Bitcoin SV release ready for testing by first week of September 2018.&nbsp; The code will be based off Bitcoin ABC v0.17.2. &nbsp;The initial release will contain as minimal a changeset as possible to support the November 15, 2018 BCH protocol upgrade because the first priority for Bitcoin SV is to establish security and QA best practices.



For the first release of Bitcoin SV, these planned changes will bring BCH significantly closer to the original Bitcoin protocol:



<ol><li>Restoring more original Satoshi op codes:&nbsp; OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT</li><li>Removing the limit of 201 op codes per script</li><li>Raising the maximum block size to 128 MB</li></ol>



Once ready, code and supporting information will be available at the new Bitcoin SV repository on&nbsp;<a href="https://github.com/bitcoin-sv">Github</a>.&nbsp;&nbsp; Bitcoin SV will be made available for open source usage under the&nbsp;<a href="https://opensource.org/licenses/MIT">MIT License.</a>



In addition to leading the Bitcoin SV project for CoinGeek, nChain will continue developing its previously-announced Teranode project for longer term deployment.&nbsp;&nbsp; Teranode will be an enterprise-level BCH full node implementation, employing a micro-services architecture approach to target terabyte+ block capacity.



<h2>Developer Team</h2>



The Bitcoin SV team has been constructed with a view to realizing industry best practices, in order to deliver and maintain a full node implementation with an unprecedented commitment to quality assurance and stability.



The Lead Developer will be Daniel Connolly, who joined nChain after 20 years in enterprise systems and IT positions for United Nations agencies.&nbsp; Daniel contributed anonymously to Bitcoin for several years, and has contributed to the Electron Cash project and is a primary contributor to the BitcoinJ-Cash project.&nbsp; nChain’s Steve Shadders will act as Technical Director, providing project oversight and liaison with sponsors.&nbsp; Steve began contributing to Bitcoin in 2011, authoring one of the first open source mining pool engines and was one of the earliest contributors to BitcoinJ.&nbsp; Additionally, the team will begin with a pool of 5 C++ developers with over 95 collective years of development experience, a part time Dev Ops resource, a full time QA engineer and range of business support personnel.



The project team is looking to hire additional C++ developers with either direct Bitcoind experience or infrastructure experience.&nbsp; Applicants are invited to submit their expression of interest to&nbsp;<a href="mailto:careers@nchain.com">careers@nchain.com</a>.



CoinGeek will provide Bitcoin SV with resources to support this professionalization of BCH development.



<h2>Quality program</h2>



The Bitcoin SV project will reinforce its commitment to stringent quality with several measures.



Firstly, the team will implement best practice change management processes and will seek to engage external QA expertise from other security-sensitive industries to monitor and audit these processes



Secondly, the project will engage the services of an industry-leading blockchain security audit firm.&nbsp; This outside team will serve two purposes:



<ol><li>Complete a full security audit of the Bitcoin SV code base scheduled to begin in mid- October.&nbsp; This audit will cover not only the code itself but also development practices and processes to assist in building the most robust node development team in the industry.</li><li>Provide ongoing review and threat analysis of all code changes as and when they are submitted as candidates.</li></ol>



Using such an outside security audit firm requires significant expense, but CoinGeek and nChain are willing to contribute such costs for the good of the entire BCH ecosystem.



Third, the Bitcoin SV project will offer a generous bug bounty program to motivate and mobilize security researchers around the world to find and report security vulnerabilities.&nbsp; The team will engage expert service providers in the field to develop an industry best practice “Responsible Disclosure Program.”



In order to demonstrate its commitment to rewarding responsible bug disclosures, the Bitcoin SV team will begin by offering the highest tier reward of USD $100,000 (sponsored by CoinGeek and of course, payable in BCH) to Cory Fields, a security researcher who found and&nbsp;<a href="https://medium.com/mit-media-lab-digital-currency-initiative/http-coryfields-com-cash-48a99b85aad4">responsibly disclosed a potential BCH chain-splitting bug in May of this year</a>.&nbsp; The result of this anonymous disclosure was a rapid and professional response that ensured the vulnerability was patched quickly and the network secured.&nbsp;&nbsp; Through its bug bounty program, the Bitcoin SV project wants to encourage more professional disclosures like that to help strengthen BCH.



<h2>Competitive engagement</h2>



More node implementations and more competition are good for Bitcoin.&nbsp; Therefore, the Bitcoin SV project welcomes engagement from other implementation developer teams that choose to support the consensus changes proposed by Bitcoin SV.&nbsp; The Bitcoin SV team invites collaboration with those teams and encourages cooperation on testing and consensus code sharing.



nChain Group CEO Nguyen adds:



“This is an exciting, but also critical, time for the progress of Bitcoin BCH.&nbsp;&nbsp; We look forward to collaborating with groups around the world on projects such as Bitcoin SV to achieve our common goal:&nbsp;&nbsp; &nbsp;making the original Satoshi Vision for Bitcoin a global reality.”

Bitcoin SV Full Node Implementation Launched to Fully Restore Original Bitcoin Protocol

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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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><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>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><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>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>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>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>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>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>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>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>Response to Block Withholding Attacks</h2>



<h3>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>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>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>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>Specific Changes</h2>



<h3>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>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>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>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>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>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>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>Performance Improvements</h2>



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



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

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>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>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>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>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>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="noreferrer noopener">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>Services</h2>



<h3>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>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>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>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>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>Endpoints</h2>



<h3>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>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>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>Roadmaps</h2>



Further features are planned for both services.



<h3>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>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>The full list of v1.0.1 enhancements and fixes below:</h3>



<h4>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>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="noreferrer noopener">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>Highlighted Changes</h2>



<h3>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="noreferrer noopener">bitcoinsv.io website</a>.



<h4>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>Consensus Changes</h3>



<h4>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>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>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>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>Other Required Change</h3>



<h4>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>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>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>List of changes since beta1</h1>



<h3>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>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">bitcoin-sv github</a> and the signed binaries are available <a href="https://download.bitcoinsv.io/bitcoinsv/0.2.2.beta/">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://github.com/bitcoin-sv/bitcoin-sv">bitcoin-sv github</a> and the signed binaries are available <a href="https://download.bitcoinsv.io/bitcoinsv/0.2.1/">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

BitcoinSV Releases

Bitcoin SV Node software – Upgrade to v1.0.11 Release

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

Articles