Timed testing [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2014-04-17T17:43:35+00:00


Summary:

The author of the email expresses gratitude for the explanations provided on using regtest to reproduce example scenarios. They decide that a private mode would not be useful for testing and will work on private chains separately from bitcoind without creating a pull request. The author brings up Sipa's complaints about regtest being too specific and suggests that some behaviors should be specified as independent parameters instead of chainparams attributes. They propose implementing the blocktime parameter as an independent parameter without the need for a new mode.In an email exchange between Jorge Timón and Gavin Andresen, they discussed the implementation of a new mode in Bitcoind. Timón suggested that the private mode only makes sense if it's useful enough for network attack simulations, which is still an open question. Andresen responded by proposing that the same effect could be achieved with -regtest by controlling node connectivity. He provided a simulation method where two nodes are started, connected to each other, and mine a -regtest chain they both agree on. After restarting them so they're not connected, one node mines normally while the other simulates an attack. To simulate launching the attack, they are connected together again, and the two chains compete to see what happens.Running a private server involves various processes like listening to the p2p network for incoming transactions, validating them and organizing mempool, performing transaction selection, and relaying blocks to auditors. These processes are not tested in a reindex. However, a reindex can give an optimistic upper bound if one wants to measure validation performance. If someone wants to measure the number of peak tps that could be processed without taking block sides or network latency into account, they can simply reindex or replay the chain. This process has been done many times before according to Mike Hearn who asked this question on April 17th, 2014.In an email exchange on April 17th, 2014, Mike Hearn asked how to measure validation performance, specifically the number of peak transactions per second (TPS) that could be processed. It was suggested that reindexing and replaying the chain would provide an accurate measurement, which had been done many times before. The timedtest mode was considered unnecessary, except for the blocktime parameter defaulting to zero. ChainParams' bool MineBlocksOnDemand() may be refactored into a parameter, possibly genproclimit, allowing periodic block generation and generation on demand to use the same regtest mode. A new mode would only make sense if the -private mode is useful enough for network attack simulations. However, this remains an open question.To measure validation performance and get the number of peak TPS (transactions per second) without considering block sides or network latency, reindexing or replaying the chain can be done. This process has been carried out multiple times by others in the past.In a communication dated April 17, 2014, Gavin Andresen asked about the difference between running in -regtest mode and running in -timedtest mode, which generates a new block automatically every second instead of having to manually request one. The response was that there is no difference, and that perhaps the value in creating a new mode is not enough to justify it. However, the proposed -private mode could provide a way to simulate proof of work attacks. The author asks questions about simulating a pow race situation without actually doing any pow and how to measure validation performance to get the number of peak tps that can be processed without taking block size or network latency into account. The author wonders if anyone has tried these things before.Jorge Timón, a Bitcoin developer, has shared his implementation of a new testing mode that produces blocks periodically. The code is available on GitHub and can be used to run simulations with different mining policies and stress tests for performance bottlenecks. Timón aims to implement the concept of private chains described in Freimarkets for hardfork or double-spend attack simulations without calculating any pow, and he seeks feedback from Bitcoin developers on how invasive this would be to Bitcoin's source code. He believes that if done properly, it could result in more readable code.In a thread on the Bitcoin Development mailing list, Gavin Andresen questioned the validity of using the -regtest mode in Bitcoin nodes to generate blocks after a few seconds. He asked how this was different from just running in -regtest mode and requesting the nodes to create a block after a short period of time. The discussion revolved around the potential implications of this approach, with some suggesting that it could lead to reduced security and increased vulnerability to attacks. Others argued that it could be useful for testing purposes, but only if done carefully and with appropriate safeguards in place. Overall, the conversation highlighted the need for caution and careful consideration when experimenting with new approaches to Bitcoin development.A new testing mode for Bitcoin has been implemented which produces blocks periodically and can be accessed on GitHub.


Updated on: 2023-08-01T08:47:56.434738+00:00