Reorgs on SigNet - Looking for feedback on approach and parameters



Summary:

The discussion on the Bitcoin Signet was centered around how to make testing simpler, especially with regards to re-org behavior. The aim of Signet is to allow software to use it without modification, which would require keeping the header format the same to let SPV clients function without significant modification. While one goal is to enable clients to opt in or out of the reorg chain at will, the motivation for Signet was that testnet deviated erratically from mainnet behavior, which meant it wasn't conducive to normal testing of applications. Therefore, the default Signet was designed to resemble mainnet as much as possible, but some users may prefer a more reliable simulation of mainnet behavior. Testing proposed soft forks in advance of activation by introducing a dimension of complexity that may be hard to manage, so it is advisable to keep other dimensions as vanilla as possible.One suggestion made during the discussion was that the existing block producers each generate a new key, and only sign reorgs with those keys. Users would be able to set a flag to indicate whether they want to accept signatures from either sets of keys and see reorgs or only want signatures from the non-reorg keys and will consider the reorg keys-signed blocks invalid. This suggestion was seen as reasonable since it would not require users to sign blocks themselves or introduce any additional complexity to the casual tester experience. Overall, the discussion aimed to find the best way to simulate mainnet behavior while allowing for easy testing of applications.


Updated on: 2023-06-15T01:31:52.806039+00:00