Skip to content

Instantly share code, notes, and snippets.

@synfonaut
Last active August 1, 2023 15:22
Show Gist options
  • Save synfonaut/ae01f0e27925d3b41c3752d2f66959e1 to your computer and use it in GitHub Desktop.
Save synfonaut/ae01f0e27925d3b41c3752d2f66959e1 to your computer and use it in GitHub Desktop.
Bitcoin SV Stable Protocol Restoration

Bitcoin SV Stable Protocol Restoration

These are the pending changes to Bitcoin SV's stable protocol — many of these were changed/removed by BTC/BCH and are being restored carefully or in ways that fix the original issues. Other changes are primarily scaling parameters or optimizations.

Remove dust limit & 0-satoshi utxos

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

This limit will be removed entirely by the end of the year allowing even 0 value outputs.

https://bitcoinsv.io/2020/09/16/beyond-micropayments-the-rise-of-nano-services/

OP_VER

Enables secondary consensus rules

https://twitter.com/cryptoAcorns/status/1345936373669367819/photo/1

Scheduled to be re-enabled in Chronicle update (expected early-mid 20201)

https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script

OP_VERIF

Version check

Scheduled to be re-enabled in Chronicle update (expected early-mid 20201)

https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script

OP_VERNOTIF

Version check

Scheduled to be re-enabled in Chronicle update (expected early-mid 20201)

https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script

OP_2MUL

The input is multiplied by 2.

Scheduled to be re-enabled in Chronicle update (expected early-mid 20201)

https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script

OP_2DIV

The input is divided by 2.

Scheduled to be re-enabled in Chronicle update (expected early-mid 20201)

https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script

IP2IP

The original version of the Bitcoin node client had the facility to conduct IP to IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the payee's client and request a public key for the payment to be addressed to. This payment method had valid security concerns, but rather than addressing these concerns, the mechanism was removed. New payment processes are in development which draw from this original idea and will allow network peers to interact securely using cryptographically verified IP addresses.

https://wiki.bitcoinsv.io/index.php/Payments_in_Bitcoin

Difficulty Algorithm Adjustment

Where we are is, as a minority hash fork it's impossible to go to old DAA. It results in a chain death attack vector as difficulty can be pushed upwards to such a degree that it cannot be feasibly reduced over a short time period.

To get back to old DAA, we must become the majority hash chain. To do this in the short term, a massive price increase for $BSV, likely paired with a massive price decrease for $BTC and $BCH, are required.

To do this in the long term, a massive increase in TX volume, enough to offset the price difference, would be required.

-Snugg2

I don't agree that we can't move back to the original DAA today. It will not result in chain death, that is a 1mb block idea. If there is no (functional) ancestor limit, and no (functional) block size limit, what would be chain death at 1mb becomes a zero-sum game to collect huge fees mining gigantic blocks; that is to say, it creates the sawtooth pattern of fewer blocks, but with a much higher portion of the reward in mining fees. The original DAA also has significant advantages when it comes to being able to verify proof of work for SPV. The current DAA more or less requires that you to store chainwork, an additional 32 bytes per block, which bloats the header store implementation by ~40%. -deanmlittle

It is proposed that Bitcoin will move back to the original difficulty adjustment algorithm (still used by Bitcoin Core - BTC) in the future.

https://wiki.bitcoinsv.io/index.php/Target

P2P Network

The P2P Protocol can be changed and there are plans among Miners to modify the implementation in future. It is conceivable that at a certain point, several different inter-node communication protocols may be in-use to propagate block and transaction information between Miners, and optimising this aspect of the network is strongly incentivised by the economics of Bitcoin mining. A large amount of the innovation that scales Bitcoin SV has been and will, in future, be done by improving the P2P protocol.

https://wiki.bitcoinsv.io/index.php/Protocol

Other Data Type values are considered reserved for future implementations.

https://wiki.bitcoinsv.io/index.php/Peer-To-Peer_Protocol

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and Script for more information)

Maximum Transaction Size

Maximum Transaction Size - The size of a transaction is the size in bytes of the serialised form of the transaction. The maximum size of a transaction is 1GB (1,000,000,000 bytes). This limitation is expected to be lifted in the future.

https://wiki.bitcoinsv.io/index.php/Genesis_upgrade

Revert to the original sighash algorithm and remove the FORKID bit

It was originally planned for Genesis and subsequently moved due to lack of testing.

https://twitter.com/unreal_someone/status/1346027070506209282

Open Questions

  • What protocol changes (if any) will Terranode require?
@shilch
Copy link

shilch commented Jan 4, 2021

Thanks for the write-up!
What I'm also wondering about for quite some time is whether OP_CODESEPARATOR today really works the way it was supposed to work originally: It allows specifying which part of a bitcoin script gets signed by a signature. However, while it seems that it was intended to be usable in scriptSig (I don't find the original code to be really clear about that), today it can only be used in scriptPubKey.

@deanmlittle
Copy link

Kill the following:

  • Low-S, also known as BIP-146 (consensus)
  • Minimal encoding (policy)

My $0.02 on the rest:

IP2IP is not a part of the Bitcoin protocol. It's something wallets can choose to implement themselves if they wish, but just because it was built into the initial node software, doesn't mean we need to put it back there any more than we need to resurrect the poker client to be feature complete.

I don't agree that we can't move back to the original DAA today. It will not result in chain death, that is a 1mb block idea. If there is no (functional) ancestor limit, and no (functional) block size limit, what would be chain death at 1mb becomes a zero-sum game to collect huge fees mining gigantic blocks; that is to say, it creates the sawtooth pattern of fewer blocks, but with a much higher portion of the reward in mining fees. The original DAA also has significant advantages when it comes to being able to verify proof of work for SPV. The current DAA more or less requires that you to store chainwork, an additional 32 bytes per block, which bloats the header store implementation by ~40%.

@joan4jays
Copy link

joan4jays commented Jan 6, 2021

If this page is inaccurate or missing information send @synfonaut an update and earn $10.
...
Scheduled to be re-enabled in Chronicle update (expected early-mid 20201)

Several places "20201"... did you intend "2021" :-).

@jdh7190
Copy link

jdh7190 commented Jan 26, 2021

Agree with @deanmlittle on IP2IP. Has nothing to do with the protocol.

Additionally the dust limit is not a consensus rule, is up to the miners and was part of the original client per Craig.

dust

@rt121212121
Copy link

All standard script requirements

  • Revert pushdata only in scriptsig (to the extent it is safe to do this).
  • Remove CLEANSTACK constraint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment