Published on: 2021-10-15T04:41:50+00:00
The discussion on the Bitcoin Signet revolved around simplifying testing and addressing re-org behavior. The aim of Signet is to replicate mainnet as closely as possible, allowing software to use it without modification. However, there were suggestions for improving the simulation of mainnet behavior.One proposal suggested having existing block producers generate new keys and only sign reorgs with those keys. This would give users the option to accept signatures from both sets of keys or only non-reorg keys, providing a more reliable simulation of mainnet behavior. Importantly, this suggestion wouldn't require users to sign blocks themselves.There was a debate about the frequency of reorgs on the default Signet. Some argued for more regular reorgs (e.g., every 8 hours) to test applications' ability to withstand different flavors of re-orgs. Others believed that making reorgs too frequent would deviate significantly from mainnet behavior and recommended testing normal mainnet behavior before focusing on reorgs.Another proposal was to introduce a version bit for blocks, requiring users to sign blocks. However, the added complexity of this approach was questioned, as the default Signet currently leaves block signing to network block signers. It was suggested that a flag set via a configuration argument could be used instead, with no-reorgs or 8-hour re-orgs as the default.To further resemble mainnet, the random generation of batches of transactions to fill up blocks and create a fee market was proposed. This would facilitate testing features like RBF and Lightning unhappy paths on the default Signet in the future.The discussions also explored various aspects related to reorgs on Signet. One proposal suggested using a version bit flag for blocks that won't end up in the most work chain, giving users the choice to opt-out of reorgs. The frequency and depth of reorgs were debated, with suggestions for frequent reorgs (e.g., every block) or less frequent ones (e.g., once per week). The depth of reorgs was considered, with different depths serving different testing purposes. It was proposed that the depth of reorgs be deterministically random within a minimum and maximum range based on block hash or nonce.Two scenarios were suggested for testing reorg handling: a race between two chains and a chain rollback scenario. Questions arose regarding the frequency of reorgs on the default Signet and how engineers currently test their applications' reorg handling.Developers sought feedback on implementing support for planned chain reorganizations in Signet. Two scenarios were proposed: races between chains and chain rollbacks. Users would have the option to opt-out of reorgs by setting a version bit flag on affected blocks. The frequency and depth of reorgs would depend on user needs, considering users across different time zones. The first step would be to implement the race scenario and set up a public test-Signet. If there is interest, chain rollbacks could be implemented, and conflicting transactions could be included in the branches.Overall, the discussions aimed to find the best approach to simulate mainnet behavior while providing an easy testing environment for applications. Feedback from developers and users was crucial in determining the optimal parameters for reorgs and ensuring a reliable testing environment for Bitcoin developers.
Updated on: 2023-08-02T04:41:16.248558+00:00