Both BCH and BSV chains have had fairly regular “upgrades” that include various changes. The BSV genesis upgrade is the culmination of changes BSV has been making since the original BCH split in August 2017. The two major items they’ve focused on are 1) removing limits on data, both for blocks as a whole and for individual transactions and 2) restoring the original OP codes and enabling non-standard scripts.
The block size is the most well known data limit, which was upgraded from 1mb to 8mb in August 2017, to 32mb in May 2018, 512mb in Nov 2018, 2gb in 2019 and now is removed completely in the genesis upgrade. Each node operator sets their own soft and hard block size limits.
The second item, restoring OP codes and enabling non-standard scripts is also big. Bitcoin uses a stack based scripting language for processing transactions. When you send someone Bitcoin you are actually locking those coins within a script and when you spend them you are providing inputs to that script that include your signature.
There are only a handful of accepted scripts allowed anymore, the most popular being pay-to-pub-key-hash (P2PKH). But in theory any script is possible. A long time ago the ability to create bitcoin transactions with any script was removed due to performance and vulnerability concerns. This has been reversed and the full scripting power of bitcoin is now unlocked in BSV.
There are more limits which have been removed and other changes, details here and here.
Time is always limited and I did not have much time to test out BSV 1.0 prior to its activation on February 4, 2020. Most previous upgrades have gone seamless and I expected this one to be seamless as well. This, however, was not the case.
The first major problem I ran into was that BSV 1.0 wouldn’t run on my system. It required a newer version of GLIBC than my system had. Unfortunately you cannot just upgrade GLIBC, you have to upgrade the entire operating system. A lot of work goes into a new OS (security hardening, etc), so this was a big roadblock.
Their recommendation was to use a Docker container. After some issues with networking and storage, this option eventually worked and I was able to get the node running on my existing machine.
The next problem I ran into was what looked like additional network errors. The Memo software would connect to the node, VerAck, and then get a peer disconnect error (104). After lots of digging and troubleshooting, it turns out the library the Memo software is using, BTCD, was causing these disconnects.
This was because there is a new message type in the network protocol, called "protoconf". The BTCD software was unaware of this new message type and would disconnect thinking there was an error with the server.
It turns out protoconf was added to allow nodes to increase the size of messages between peers. A simple message, but handling needed to be added.
Now two major issues are resolved. The genesis software is running and the Memo software is able to connect to it. The final issue was the change to OP_RETURN. Last year the BSV team announced that all OP_RETURNs should be prepended with OP_0, meaning that something must be on the stack to return. However, in many places they indicated they would maintain legacy support for OP_RETURN without the OP_0 prepend.
What I did not understand was that even though OP_RETURN without OP_0 may be allowed, it would now require an output value to be valid. Using straight OP_RETURN with no value now gives a dust error. Adding 546 satoshis to every OP_RETURN would be a waste, this means for Memo to continue working on BSV it needed to conform to the new OP_0 OP_RETURN standard format.
With this third issue fixed, memo.sv is fully functional again. One major difference now is that unsplit Memos are no longer supported. Before, if you had the same UTXO on both the BCH and BSV chains you could create a Memo post and it would be valid on both chains. Now BCH requires regular OP_RETURN and will reject OP_0 OP_RETURN, while BSV is the opposite, requiring OP_0 OP_RETURN and rejecting regular OP_RETURN. So now Memo BCH and Memo BSV exist completely independently.