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.
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/
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
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
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
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
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
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
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
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 - 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
It was originally planned for Genesis and subsequently moved due to lack of testing.
https://twitter.com/unreal_someone/status/1346027070506209282
- What protocol changes (if any) will Terranode require?
Thanks for the write-up!
What I'm also wondering about for quite some time is whether
OP_CODESEPARATORtoday 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.