BTC SV Node update: 10x
4 min read [ad_1]
Remember Christmas? nChain CTO and SV Node Lead Developer Steve Shadders let us all know that the final, major piece of the puzzle in BSV’s scaling domination was being lifted as a Christmas gift to the users of BTC SV, and we all rejoiced! But the celebration may have been a bit premature.
The “Ancestor Limit” before the previous node release would only allow for 50 “children” to be spent from an unconfirmed “parent” transaction—which was not nearly enough for long Twetch threads about Jesus and Flat Earth, slingin’ $SHUA coin all day on the REX or aping into the Gorilla DAO with the proceeds of trading $tendies. Brave new world…
Early this year, the limit was lifted to 1,000 transactions with Shadders encouraging miners to quickly adopt the change and seek to remove the limit altogether. Amid the celebration, many people were excited to use the applications which had been waiting for the change. One of the most anticipated applications of this release was CryptoFights by FYX Gaming, which was built from the ground up to utilize BTC SV transactions for every aspect of the game play. Unfortunately, within a few days of the release, it became evident that CryptoFights needed even more child transactions because basic gameplay would reach the new ancestor limit in three to five rounds of the game—requiring a block confirmation to proceed, which was a huge detriment to the user experience of the game.
After the celebration of the release, it was big bummer to have to take a step back to the drawing board to attempt to engineer a solution again.
Enter SV Node Version 1.0.8
“But Kurt, isn’t the protocol set in stone?”
YES. Software is NOT protocol. These changes don’t change BTC rules, nor consensus rules, and there is nothing except changes to miner policy settings. There are a number of important (and some granular) changes to this release. The ancestor limit has been increased by 10X to 10,000 transactions. Again, Shadders noted the desire to get this limit removed altogether as soon as possible!
Almost immediately upon release, CryptoFights lead developer, David Case, took to Twitter to express his desire to see the honest nodes of BSV adopt the new version. If you recall, the Node team works on behalf of the BTC Association to propose software changes, but it is up to the individual nodes of the network to adopt the upgrade. This is typically an exercise in coordination because if too many versions of the software are trying to come to consensus, there can be increased risks for splits, orphans or other problems.
BTC SV block producers… Please upgrade to 1.0.8 ASAP!
Thanks,
¯_(ツ)_/¯— David Case u/114 @114 (@shruggr) May 12, 2021
With this new version, resource-hungry applications like CryptoFights should be able to make their complete debut with no practical limits, and we should begin to see some very big blocks! When asked for comment, Case said, “…this was the last limit in place in the mining software which blocked real interactivity between objects on chain. Now that it has been lifted, and the previous bugs have been resolved, we are finally able to move CryptoFights onto mainnet!”
This is HUGE news, as FYX Gaming is expected to bring in a tidal wave of users to the network and start to make some very important use of BSV’s exclusive superlatives.
What else was included in the updates?
The new “getmerkleproof2” RPC call has been added to aid in the implementation of SPV, new double-spend alert tools also made an appearance presumably to get ready for an increased volume of small payments, and there was also a bunch of housekeeping related to the ancestor limit change.
One curious change is the addition of a dust return script added as a new standard transaction type. According to the release:
“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.”
That is all well and good, but as I understand it, every “OP_FALSE OP_RETURN” already does this with standard validation rules, but previously, a user could also do the occasional consolidation transaction and keep their own dust for a nominal fee. Shadders was kind enough to explain the thought process behind the change. Turns out, the change is specifically focused on privacy and mitigating the risks of doxing users with dusting attacks.
He stated, “Normal op return transactions still incur fees. So if the dust isn’t enough to pay the fee, you’d have to include another input to be able to cover the fee which is exactly what the attacker wants.”
“Consolidation might be another way to do this but you’d have to join all dust and wait until you had enough to meet the stricter criteria (which you may never do if it’s a one off attack).”
“Dust return can be done instantly with one dust input and is much simpler to implement on a user wallet.”
Get ready to see big blocks full of long chains of transactions, big blockers! Because we are about to see another big step as complex applications make their way to the main net!
New to BTC? Check out CoinGeek’s BTC for Beginners section, the ultimate resource guide to learn more about BTC—as originally envisioned by Satoshi Nakamoto—and blockchain.
