st 19. 3. 2025 v 10:04 odesílatel Sjors Provoost napsal: > Antoine Poinsot wrote: > > The given rationale for a difficulty reset was to let developers > occasionally mine blocks on their laptop. But you cannot have your cake and > eat it too: either the network is permissionless (PoW) or you assign > identities and privileges to some (Signet). By trying to do both at the > same time testnet4 created a loophole for abuse. As a result it failed on > both count: it neither mimics mainnet nor allows developers to mine active > blocks on their laptop. > > > Let me clarify why developers can't mine on their own laptop with testnet4. > > The way you would do that is to move your computer clock forward by 20 > minutes (or use faketime), at which point the difficulty drops to 1. You > would then mine your (presumably non-standard transaction) and broadcast it > to the network. > > This is also the strategy used to acquire more testnet coins if you don't > have an ASIC and don't want to use a faucet. > > On testnet3 the latter wasn't very productive because at height 4 million > the block subsidy is under 10k sats. > > But on testnet4 every block yields 50 tBTC. So several people try to mine > such a block, leading to the many parallel forks. > > If you're a developer trying to mine a non-standard transaction, you have > to be fast, well connected and lucky to be the first block picked up by the > rest of the network. > > But why mine just one if you can mine many? > > Some CPU miners are now mining as many testnet4 blocks as they can by > bumping their clock 20 minutes not just once, but several times in a row. > Until they run against the limit other nodes put on how far a block can be > in the future, namely two hours. So when a real difficulty block appears, > you may see 5 blocks on top of it instantly. > > This behavior is even worse from the point of view of a developer trying > to mine a non-standard transaction. Because the tip of your node is always > going to be about two hours in the future, when you mine on top of that by > moving your clock even further, it will be rejected by your peers. > > So this use case of CPU mining non-standard transactions is simply dead as > long as this behaviour exists. We might as well reduce code complexity. > > That said, testnet will never mimic mainnet. It has no value, or worse, > very little value. So the incentives are different, which leads to > different behavior. That's a whack-a-mole game, which we should probably > not dedicate time to. > The question I’ve had for some time is why spoofed blocks on testnet4 come in batches of: - 6 blocks -20-minute intervals - A maximum lead time of 2 hours If these values were set for early Bitcoin network reasons, would it make sense to tweak them for testnet4 to improve functionality? Reducing the maximum lead from 2 hours to 1 hour and limiting batches to 3 blocks instead of 6 seems like it could mitigate some of the observed issues while maintaining testnet’s purpose. Would this be feasible? > > - Sjors > > > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/2064B7F4-B23A-44B0-A361-0EC4187D8E71%40sprovoost.nl > > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYhLNTbA%3DqMuQ5W63jxwUoa2%2Bmpn020NC31JqGzbk0wPF-A%40mail.gmail.com.