|
Title: Requesting Testnet4 tBTC Post by: bc1plainview on June 07, 2024, 02:30:00 AM I am looking to set up testnet4 to begin testing my current project without needing to index all the testnet3 blocks. However, I haven't been able to find a testnet4 faucet yet. Would anyone be willing to share some tBTC with me at the following address?
tb1preru33xeap6v33g0jaypn7x2dsuheyny0n0hh48wany8h8kz98us8l9rv9 Thanks in advance! Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on June 07, 2024, 05:13:31 AM Quote However, I haven't been able to find a testnet4 faucet yet. Why would anyone run a faucet for the network, which is not yet finalized, and can be resetted at any time?Quote Would anyone be willing to share some tBTC with me at the following address? Why you need a faucet, if you can mine a block on your CPU? For example, note how many blocks were mined by wiz: https://mempool.space/testnet4/mining/pool/wizOne of the latest blocks: https://mempool.space/testnet4/block/0000000012bfe95b1e2fcdccf0f855792a051e2412287869c758491a5cacdbf7 See? Those blocks have just the minimal difficulty. You need only CPU to mine it. Title: Re: Requesting Testnet4 tBTC Post by: punk.zink on June 08, 2024, 02:53:32 AM I am looking to set up testnet4 to begin testing my current project without needing to index all the testnet3 blocks. However, I haven't been able to find a testnet4 faucet yet. Would anyone be willing to share some tBTC with me at the following address? It seems that you are not serious enough to find out about the testnet4 faucet site. If you really need testnet4 tBTC, you can get some tBTC from the sites https://coinfaucet.eu/en/btc-testnet4/ https://mempool.space/testnet4/faucet https://testnet4.anyone.eu.org/ As explained above, the testnet4 network https://mempool.space/testnet4 is not final, and it may not be this network that will be used later. Title: Re: Requesting Testnet4 tBTC Post by: ercewubam on June 09, 2024, 02:53:36 PM Test coins are weird: some of them are free (https://mempool.space/testnet4/tx/8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf), some of them are burned (https://mempool.space/testnet4/tx/c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf). But it seems you got (https://mempool.space/testnet4/tx/ffa3f9949b1c6cafc1b8aa8780eb0d6ed92c101c577fb3cc4b3babc45053dd0b) what you wanted anyway.
Title: Re: Requesting Testnet4 tBTC Post by: bc1plainview on June 10, 2024, 05:45:31 AM Test coins are weird: some of them are free (https://mempool.space/testnet4/tx/8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf), some of them are burned (https://mempool.space/testnet4/tx/c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf). But it seems you got (https://mempool.space/testnet4/tx/ffa3f9949b1c6cafc1b8aa8780eb0d6ed92c101c577fb3cc4b3babc45053dd0b) what you wanted anyway. to whoever did this, thanks a ton! Title: Re: Requesting Testnet4 tBTC Post by: mocacinno on June 10, 2024, 06:02:42 AM Why you need a faucet, if you can mine a block on your CPU? For example, note how many blocks were mined by wiz: https://mempool.space/testnet4/mining/pool/wiz Just for your information: no, you can't... The diff is already sky-high (well, not sky-high compared to the main net, but sky-high compared to a cpu-mining setup)... I did the math a couple of weeks ago, and at that time, on average, it would take several hundreds of years to mine a block using your cpu on testnet 4. I have no idear why people would run ASIC's on a testnet, but apparently, they do... EDIT: here are the current stats from my testnet4 node... A lot lower than a couple weeks ago, but still waaaaaaaaay to high for cpu mining: Code: {Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on June 10, 2024, 06:45:59 AM Quote Just for your information: no, you can't... Yes, I can, and I did. It is always a lottery, but I can put something in the next coinbase, if you want. There is always a chance, that it will take some time, because of frequent chain reorganizations, but it is possible.Quote The diff is already sky-high The diff for CPU mining is always one. Obviously, I won't try mining any more difficult blocks on CPUs.Also see: https://bitcointalk.org/index.php?topic=5468925 Connected topic: https://blog.lopp.net/griefing-bitcoin-testnet/ And note, that on testnet4, some tricks are easier to achieve, than on testnet3 (as long as the basic block reward is still quite high). Title: Re: Requesting Testnet4 tBTC Post by: mocacinno on June 10, 2024, 07:23:46 AM I have mined on testnet3 in the past, i'm well aware of the fact that the difficulty can reset to 1. But still, when you cpu mine at a couple dozen Mh/s, you're still vastly outnumbered against a multi Terrahash/second asic that's also mining at the same difficulty.
When i created my testnet4 node container, i tested out the cpuminer that i included into my image for 2 weeks to see if it was stable, and i did not solve a single block... Sure, it might not be impossible, but your odds are really low. EDIT: truth be told, based on the info i got from my node, it does seem like a lot of people did turn off their ASIC's since i last tested my container.... A couple weeks ago, my node estimated the total network hashrate to be >400Th/s, whilst now it's only >70 Th/s, and i do indeed see blocks being mined at difficulty 1 (which was not the case a couple weeks ago). So yes, maybe at the moment it might be possible to mine a couple testnet4 blocks with your cpu if you're really lucky. Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on June 10, 2024, 10:09:12 AM Quote But still, when you cpu mine at a couple dozen Mh/s, you're still vastly outnumbered against a multi Terrahash/second asic that's also mining at the same difficulty. It is obvious, that you have to prepare some blocks in advance (for example in testnet3, you have everything filled, up to 2 hours in the future). And then, it is more related to network connections, than to the computing power. You just prepare a block, and you have your block with difficulty one, vs some ASIC block, also with difficulty one. Then, it is not about "who will mine it faster", but rather about "who will propagate it faster".And of course, ASIC miners rule that world of test chains, so you have to mine your blocks around theirs. But still, it is possible to propagate some block faster, than some ASIC will do, because both players will prepare them in advance, and then the competition is related only to network connections. Another thing is that ASIC miners potentially could always reorg CPU-mined blocks, but for some reason they don't. It is more profitable to mine a strong, regular block on top of them, because then, you can pick any block time you want. In case of CPU block times, it is more restricted. Quote i tested out the cpuminer that i included into my image for 2 weeks to see if it was stable, and i did not solve a single block... It should mine at least some blocks, but they probably were reorged. If that's the case, then you have to improve the code for your node, not for your mining equipment. For example, to mine testnet blocks easily, I slighttly modified Bitcoin Core, and since then, it works on my CPU.Quote So yes, maybe at the moment it might be possible to mine a couple testnet4 blocks with your cpu if you're really lucky. I repeated the same thing on testnet3, just to be sure. Now, I can mine on CPU in both networks, but testnet4 is more stable. However, mining in testnet3 is still quite good idea, if you want to test block rewards, based on transaction fees.Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on June 10, 2024, 04:41:23 PM Quote Just for your information: no, you can't... Sure, but my node, and some block explorers think otherwise:https://mempool.space/testnet/address/tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx https://mempool.space/testnet4/address/tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx Public key: 0261c2c04c8133b863d9df2ef4082c21074f8849ef86ddf54b13e07d6c828faac6 Legacy address: mpNxT11hJpGH2YhUgQKZm2S1rBnnieWbHr Segwit address: tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx Code: verifymessage "mpNxT11hJpGH2YhUgQKZm2S1rBnnieWbHr" "IORhFfwQl/VK8NU6sQrRxQ6pqoGjHTElUirU+H0lrsyPKE+cOYUZ3TNx3JF8WM69TvhfwZ9iafDk2f6WK1tZZMg=" "June 10, 2024, 04:13:45 PM: I am Garlo Nicon, and I confirm in topic 5499150 on bitcointalk, that I can mine new blocks in testnet3 and testnet4, by using address tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx. All of those blocks have minimal difficulty, equal to one, and were mined on my own CPU." Title: Re: Requesting Testnet4 tBTC Post by: detmm244 on June 10, 2024, 06:32:50 PM Quote Just for your information: no, you can't... Sure, but my node, and some block explorers think otherwise:https://mempool.space/testnet/address/tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx https://mempool.space/testnet4/address/tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx Public key: 0261c2c04c8133b863d9df2ef4082c21074f8849ef86ddf54b13e07d6c828faac6 Legacy address: mpNxT11hJpGH2YhUgQKZm2S1rBnnieWbHr Segwit address: tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx Code: verifymessage "mpNxT11hJpGH2YhUgQKZm2S1rBnnieWbHr" "IORhFfwQl/VK8NU6sQrRxQ6pqoGjHTElUirU+H0lrsyPKE+cOYUZ3TNx3JF8WM69TvhfwZ9iafDk2f6WK1tZZMg=" "June 10, 2024, 04:13:45 PM: I am Garlo Nicon, and I confirm in topic 5499150 on bitcointalk, that I can mine new blocks in testnet3 and testnet4, by using address tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx. All of those blocks have minimal difficulty, equal to one, and were mined on my own CPU." how to mine testnet4 useing cpu please guide me step by step how to cerate testnet4 address i am using to create testnet address https://www.bitaddress.org/bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html?testnet=true example Bitcoin testnet Address mk4Lmwd1g787twjQYbswdotpYDz9XVD3hH Private Key cPLfGZGNgVsYvGfUTP62JdPBzHhL3jjqQ82RobkamETm7WzdgcGE this testnet mk4Lmwd1g787twjQYbswdotpYDz9XVD3hH adderess also use to testnet4 ?? Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on June 10, 2024, 08:05:18 PM Quote how to mine testnet4 useing cpu Code: $ cat mining4.sh Quote please guide me step by step 1. Download, build and run Bitcoin Core, made by fjahr, from branch 2024-04-testnet-4-fix: https://github.com/fjahr/bitcoin/tree/2024-04-testnet-4-fix2. Generate some new address (or import it into Bitcoin Core). 3. Start mining. Most likely, your blocks will be ignored, but you will see them in your GUI, if you use Bitcoin Core as a wallet. Quote how to cerate testnet4 address Code: getnewaddress Quote this testnet mk4Lmwd1g787twjQYbswdotpYDz9XVD3hH adderess also use to testnet4 ?? Yes: https://mempool.space/testnet4/address/mk4Lmwd1g787twjQYbswdotpYDz9XVD3hHTitle: Re: Requesting Testnet4 tBTC Post by: garlonicon on August 05, 2024, 05:28:26 AM BIP for Testnet4 is now officially merged: https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki
Edit: Quote I did the math a couple of weeks ago, and at that time, on average, it would take several hundreds of years to mine a block using your cpu on testnet 4. This sentence didn't age well, because now I can produce something around 10% of testnet4 blocks, and all of them are CPU-mined.Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 05, 2024, 11:42:06 AM This sentence didn't age well, because now I can produce something around 10% of testnet4 blocks, and all of them are CPU-mined. Can you get me an Eli5 for this? I tried for testnet3 in the past, but didn't mine anything after a week and gave up.Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on August 05, 2024, 04:53:39 PM My comment in testnet4 pull request: https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2218329966
My code changes: https://bitcointalk.org/index.php?topic=5496494.msg64205870#msg64205870 How to reproduce: 1. Go to: https://github.com/fjahr/bitcoin/tree/2024-04-testnet-4-fix 2. Execute "git clone" on this repo, or get source code in any other way. 3. Edit "src/chain.h" and "src/node/miner.cpp" exactly as I presented on forum. 4. Build Bitcoin Core from source code. 5. Apply vjudeu's scripts from above in your terminal (they are for Bash on Linux, but you can use "Git Bash for Windows", or modify it slightly, to get it working under Windows). 6. See increasing nonces in your terminal, and observe mined blocks. Quote but didn't mine anything after a week and gave up If you use my method, and your block will have the minimal difficulty, and will be valid, then it is guaranteed to always see it in your Bitcoin Core client, as long as your private keys are properly imported. It may be stale, it may be not accepted by other nodes, but it will be always visible.Also, if you want to see any block, then you can use a simple shortcut: 1. Open Bitcoin Core. 2. Type "generatetoaddress 1 <address> 100000000". 3. Repeat it several times manually (or use bitcoin-cli). As long as your difficulty is set into the minimum, you should get a block after around 4 billion hashes (or 40 nonces, if you use that line above inside some loop). Long time ago, when I started, I simply used "generatetoaddress" command manually, and modified my system clock, to set it 20 minutes after the last block. But: if you think about a stable environment, then modifying the source code is easier, because then your node will report the correct time, and you will not see a lot of warnings saying that "please check your system clock, because it may be set incorrectly". Also, if some blocks will already be in the future, you won't be forced to mine blocks with the real difficulty (by the way, once per 2016 blocks, the real difficulty is used anyway; you can of course run your CPUs 24/7, but I usually turn off my miners, and wait for ASICs to do that job). Also, a good starting point is regtest, or signet with signetchallenge set to OP_TRUE. Then, you will always see some generated blocks. So, to sum up: you can always mine blocks, on testnet, mainnet, signet, regtest, just everywhere. Command line and "generatetoaddress" is your friend. The hardest part is just setting your system clock 20 minutes after the last block. But if you can cover that, or if your Bitcoin Core can give you future timestamps in your block templates, then you are good to go. Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on August 05, 2024, 05:27:41 PM Quote Can you get me an Eli5 for this? Baby steps: run mainnet in offline mode, without any connections, start from the Genesis Block, and mine a single block, on top of that, by using Bitcoin Core. For example:Code: $ ./bitcoin-qt -noconnect Title: Re: Requesting Testnet4 tBTC Post by: pooya87 on August 06, 2024, 03:46:34 AM If you can get it right, then you can mine blocks with the minimal difficulty, and we can go further. This simple exercise is what I started with, long time ago, when I was curious, how to mine blocks with Bitcoin Core. Using RegTest is far better since the fixed difficulty there is a lot lower than the minimum difficulty in both MainNet and TestNet. This means you don't want to waste time waiting for your computer to compute millions of hashes to find the next block at difficulty one. On RegTest you'd generate blocks almost immediately. Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on August 06, 2024, 05:45:43 AM Quote This means you don't want to waste time waiting for your computer to compute millions of hashes to find the next block at difficulty one. But that's the whole point! You want to do that, to make sure, that you are ready for testnet3 or testnet4 mining. For example, you want to abandon the idea of using unoptimized Python code for testnet mining. Or: a similar idea of using "sha256sum", running in a bash loop (and creating and destroying the whole ELF stack for computing every single hash).1. If you mine with regtest difficulty, then you don't know, if you hit correct blocks by accident or not. Then, you can even manually increase nonce, and use "submitblock", to mine anything there. 2. In regtest, you have no difficulty adjustments, so you don't know, how many testnet blocks you could mine, with your current setup. You have to soft-fork that feature, or switch to signet, to learn it. 3. If your tests require more than 15k coins, then you won't do that on regtest. All other networks have 21 million coins. You need to cycle 15k coins, 1400 times, to reach similar outcome. 4. You cannot measure the actual effort of mining blocks with regtest. You can mine with maximum speed of 43,200 blocks per two hours, and increasing your computing power won't change it. Also, I wonder, if I should create a pull request, which will bring CPU-only mining into Bitcoin Core, as a feature. Then, it could be similar to grinding blocks from bitcoin-util: it will always give you a block, matching the minimal difficulty, on all networks, including mainnet. Because in general, that's how testnet should probably work: you have a mainnet chain, up to the block 789,012, and then you say "I want to mine a block 789,013, with those transactions, and test that scenario". Because if testnet blocks are not stale, then they always have a chance to get some value, and be traded on centralized exchanges. Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on August 29, 2024, 07:12:03 AM Quote but it's easier to just wait for testnet3 to be shredded and replaced by the new version by default New version released: https://groups.google.com/g/bitcoindev/c/EmAOO-NbmzwIt is release candidate, but it contains fully working testnet4 implementation. Of course, for CPU-based mining, some modifications are needed, but I think grinding coins with bitcoin-util should still be possible. I will think about some kind of such implementation. Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 29, 2024, 07:53:11 AM Test coins are weird: some of them are free (https://mempool.space/testnet4/tx/8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf) Can you explain this one?Title: Re: Requesting Testnet4 tBTC Post by: BlackHatCoiner on August 29, 2024, 08:14:59 AM Test coins are weird: some of them are free (https://mempool.space/testnet4/tx/8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf), some of them are burned (https://mempool.space/testnet4/tx/c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf). Both the "free" and the "burned" link to the same transaction. I get that the coinbase reward is burned, because it is sent to OP_RETURN, but where are the free coins?Of course, for CPU-based mining, some modifications are needed, but I think grinding coins with bitcoin-util should still be possible. I will think about some kind of such implementation. What's the recommended way to mine testnet4 with CPU? Is it possible directly from Core with generatetoaddress? And, is there mining software for testnet that is configurable with GPUs?Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 29, 2024, 08:30:17 AM Test coins are weird: some of them are free (https://mempool.space/testnet4/tx/8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf), some of them are burned (https://mempool.space/testnet4/tx/c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf). Both the "free" and the "burned" link to the same transaction."free": 8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf "burned": c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on August 29, 2024, 08:35:52 AM Quote Can you explain this one? Those coins were sent to OP_TRUE. Which means, that anyone could sweep them, as it was done here: https://mempool.space/testnet4/tx/09096e1e6fb31f33f3de40b9a1d76908e565e9646e5aed4e0813e0a2a799fc4cAs you can see, no signatures were provided. Similar case was in https://mempool.space/testnet4/tx/3a72c025a8995fe94af9ec00d61046f55fe18133ebb98f290f81aa68f3bc8fc1 The previous script was simply OP_TRUE, but that one was P2WSH, with OP_TRUE, which made it standard. Quote Both the "free" and the "burned" link to the same transaction. Huh?First link: https://mempool.space/testnet4/tx/8f4cf55da2abc21ac4f5d176bd5aefcfdc91852343dbfe91215d7c8afa966baf Second link: https://mempool.space/testnet4/tx/c3750456a633ddc6493b26fd5ef288b339e84f231f31128fd6d84276b8871abf They are different. But yes, those free coins are now taken, so you have to find something else. Quote What's the recommended way to mine testnet4 with CPU? The easiest way is to make two small changes in the source code (https://bitcointalk.org/index.php?topic=5496494.msg64205870#msg64205870), and just recompile it. But there are also other ways.Quote Is it possible directly from Core with generatetoaddress? Yes, if your Bitcoin Core implementation will always give you the block template, moved forward by 20 minutes.Quote And, is there mining software for testnet that is configurable with GPUs? You have regular Bitcoin Core node. You can connect CPUs, GPUs, FPGAs, ASICs, whatever. The most difficult part is to get the block header, which has the minimal difficulty. For example, if you call "getblocktemplate", you should see this:Code: $ ./bitcoin-cli -testnet4 getblocktemplate '{"rules": ["segwit"]}'In general, I can see two options: 1. Modifying Bitcoin Core. 2. Having unmodified Bitcoin Core, getting original block template, and modifying it in your mining software, or just before passing it to your mining software. I think it is easier to recompile Bitcoin Core, but it is possible to get for example some 80-byte block header, and then write some code, to replace block time and difficulty, and then pass it into some mining software. Also, mining with Bitcoin Core is easier, because then you don't have to worry about dumping the whole block, making a proper Segwit commitment, and so on. Title: Re: Requesting Testnet4 tBTC Post by: BlackHatCoiner on August 29, 2024, 08:43:56 AM I could swear that both these links sent me to the same transaction. SMF bug? ... Anyway, thanks, I'll try to mine a block and let you know.
Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 29, 2024, 11:19:45 AM If you can get it right, then you can mine blocks with the minimal difficulty, and we can go further. This simple exercise is what I started with, long time ago, when I was curious, how to mine blocks with Bitcoin Core. This worked:Code: {3. Edit "src/chain.h" and "src/node/miner.cpp" exactly as I presented on forum. If this is ELI5, I may need ELI4....Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on August 29, 2024, 12:01:57 PM Quote If this is ELI5, I may need ELI4.... If you can get a single block, after the Genesis Block, then it means, that you have enough computing power, to mine on testnet4.Quote Edit "src/chain.h" and "src/node/miner.cpp" exactly as I presented on forum. Those code changes are simple:1. Go to "src/chain.h". 2. CTRL+F "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 2 * 60 * 60;" 3. Replace it with: "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 20 * 60 * 60;" 4. Save changes. 5. Go to "src/node/miner.cpp". 6. CTRL+F "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch<std::chrono::seconds>(NodeClock::now()))};" 7. Replace it with: "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, pindexPrev->GetBlockTime() + consensusParams.nPowTargetSpacing*2 + 1)};". 8. Save changes. As I said: you can do that, and recompile Bitcoin Core, then all "generateXYZ" commands will give you easier blocks. The alternative is to not touch Bitcoin Core at all, but then, you have to extract the whole block, save it somewhere, replace time and difficulty, and then pass your 80-byte header to your mining software. But for me, recompiling Bitcoin Core is easier. Quote Long time ago, when I started, I simply used "generatetoaddress" command manually, and modified my system clock, to set it 20 minutes after the last block. This is another way, if you don't want to touch your source code. You can simply set your system clock 20 minutes into the future. But then:1. You will get some warnings, that "your clock is different, than in other nodes". 2. It will work only for a single block. When you mine it, then you won't mine a second block on top of that, because you will need to move your time again, 20 more minutes forward, or you will be mining with the real difficulty. 3. If any other CPU miner will produce a block, then you will mine again with the real difficulty. 4. Your browser will tell you, that HTTPS connection is insecure, because your system time will be set differently. 5. Other programs, or even your Operating System, may try to update your time, and set it automatically, if you don't disable it. So, by manually tweaking your system clock, and using unmodified Bitcoin Core, you can mine a block or two, but it quickly becomes tedious. But of course, if you have nothing else, then you can start with that. If you change your system clock manually, and then restart Bitcoin Core, you should be able to mine a block on your CPU, if your block template will give you "1d00ffff". Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 29, 2024, 03:55:27 PM Quote If this is ELI5, I may need ELI4.... If you can get a single block, after the Genesis Block, then it means, that you have enough computing power, to mine on testnet4.Quote Edit "src/chain.h" and "src/node/miner.cpp" exactly as I presented on forum. Those code changes are simple:1. Go to "src/chain.h". 2. CTRL+F "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 2 * 60 * 60;" 3. Replace it with: "static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 20 * 60 * 60;" 4. Save changes. 5. Go to "src/node/miner.cpp". 6. CTRL+F "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch<std::chrono::seconds>(NodeClock::now()))};" 7. Replace it with: "int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, pindexPrev->GetBlockTime() + consensusParams.nPowTargetSpacing*2 + 1)};". 8. Save changes. Code: ./bitcoind --testnet4 -prune=25000 Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on August 29, 2024, 05:23:09 PM Also: Quote This branch is 360 commits behind bitcoin/bitcoin:master. So, I guess using official code is better now. At the time of writing, it was not yet merged, so there was no other way.Or: you can also use https://github.com/bitcoin/bitcoin/tree/28.x because this is what you can get, if you download release candidate for v28. But usually I just stick with the master. Edit: Quote Code: ./bitcoind --testnet4 -prune=25000 Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 29, 2024, 07:13:07 PM Or: you can also use https://github.com/bitcoin/bitcoin/tree/28.x because this is what you can get, if you download release candidate for v28. But usually I just stick with the master. I'll try this next, thanks.Quote Edit: Both work. Bitcoin Core isn't so picky. That's why I got sloppy with the dashes.Quote Code: ./bitcoind --testnet4 -prune=25000 Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on August 30, 2024, 05:35:45 AM Quote Invalid parameter --testnet4 Which version? Both master and v28.0 should have it.Code: $ ./bitcoind --version Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 30, 2024, 06:55:45 AM Quote Invalid parameter --testnet4 Which version? Both master and v28.0 should have it.One more question: how do I get one of those cute little Miner tags "LoyceV was here" (just like Portland.HODL (https://mempool.space/testnet4/block/000000000000001f403a7b9a65736686ca90c6ffc051e0b6f98d5a2db141368f))? That would be a cool thing to have before I turn this off again :) I tried Googling it, but couldn't find it. Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on August 30, 2024, 07:18:50 AM Quote how do I get one of those cute little Miner tags "LoyceV was here" Do you want to get only some message, or something special? Usually, I just change the code, for example:Code: // Create coinbase transaction. Edit: Let's see: https://mempool.space/testnet/tx/5e739e2a69fe22f8b3f7536c35cbb710ddb725e5660f3996e902ee6eeb36c21a Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 30, 2024, 08:32:55 AM Code: coinbaseTx.vin[0].scriptSig = CScript() << nHeight << ParseHex("4c6f79636556207761732068657265");https://loyce.club/other/testnet4.png I don't know why there's ] and | in front. Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on August 30, 2024, 08:37:40 AM Quote I don't know why there's ] and | in front. Because of block height, which is mandatory, since BIP-34 (https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki). And because mempool.space decodes block height as ASCII, it is what it is.Also note, that there are more mining pools, marked as "Unknown". The list of tags is probably centrally managed by mempool.space, so you can ask them about it. Or try to format it in the same way as "wiz" did. Title: Re: Requesting Testnet4 tBTC Post by: BlackHatCoiner on August 31, 2024, 12:43:55 PM Is it possible to run bitcoin-cli generatetoaddress in multiple threads? I wrote a C program which calls 12 forks, each having its own thread, but it doesn't get all the CPU power. It's strange; it only takes 33% of the CPU. (My total threads are 12.)
Code: #include <stdio.h> Everything seems to be executing properly: Code: $ ./exec2 I know that there is already some CPU mining software out there for multiple-thread mining, but I want to write my own. It's also made for testing purposes, since we're in testnet. Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 31, 2024, 02:12:08 PM Is it possible to run bitcoin-cli generatetoaddress in multiple threads? I wrote a C program which calls 12 forks, each having its own thread, but it doesn't get all the CPU power. It's strange; it only takes 33% of the CPU. (My total threads are 12.) Here, it tops off at 400.0% CPU (so 4 cores). I'm not sure how useful it is though: sometimes different threads find the same block, and sometimes they find different blocks.Title: Re: Requesting Testnet4 tBTC Post by: BlackHatCoiner on August 31, 2024, 02:32:52 PM Here, it tops off at 400.0% CPU (so 4 cores). In Linux Mint, CPU usage goes up to 100%. If you have 12 cores, and the program uses 8.3% of the CPU, it means it uses 1 core. If it uses 33%, it means it uses 4 cores. So, it perhaps depends on the architecture of the OS. (I guess that the fact that it's using the same number of cores in both of us, is a good sign.)I'm not sure how useful it is though: sometimes different threads find the same block, and sometimes they find different blocks. That's a problem, indeed. You can avoid it by using different Bitcoin address in each thread, but it makes everything more complicated for no reason. An extra nonce field in generatetoaddress would solve this problem.Edit: Just solved the same block four times :D Code: $ ./exec2 Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on August 31, 2024, 03:01:05 PM You can avoid it by using different Bitcoin address in each thread, but it makes everything more complicated for no reason. That's easy to fix:Code: address=$(shuf -n1 addresses.txt) Title: Re: Requesting Testnet4 tBTC Post by: BlackHatCoiner on August 31, 2024, 03:59:01 PM Added --debug=http, and here's what I get:
Code: 2024-08-31T15:50:25Z [http] Received a POST request for / from 127.0.0.1:37146 It uses only 4 cores, because it calls CreateNewBlock() only 4 times, whereas I'm calling it 12. (It does receive all 12 requests though.) There has to be an internal function in Bitcoin Core which blocks me from running CreateNewBlock more than 4 times in parallel. BTW, another problem is mempool. For some reason, it's empty to me. (And that's why I mine empty blocks.) Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on September 02, 2024, 04:37:27 AM Quote Is it possible to run bitcoin-cli generatetoaddress in multiple threads? Yes, sure, bitcoin-util has the "grind" command, which does exactly that. The hardest part is getting 80-byte block header, and passing it correctly. But if you can:1. Dump the whole block. 2. Extract the block header. 3. Pass that header to bitcoin-util. 4. Submit mined block to the network. Then it can work. But currently, I had some cases, where I had six future blocks in a row, and then needed to slow down my miners, so I am not planning to get more power out of it, because after passing two hours limit, the risk of getting your block reorged is increased (because if you don't re-submit your block properly, then it won't be broadcasted automatically, if you mine it too fast). Quote You can avoid it by using different Bitcoin address in each thread, but it makes everything more complicated for no reason. It can be simpler than that. See bitcoin-util implementation (or just use it, by passing your block headers there). If you have nonces from 1 to 100, and you have two threads, then the first thread can check 1,3,5,7, and the second one can check 2,4,6,8, at the same time. Then, you have "i+=2" in both cases, and you use "i=startRange+threadId" as a starting point.Quote Just solved the same block four times Yes, for that reason, I use a different address in each generatetoaddress call, or assign different range of nonces for each call.Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on September 02, 2024, 07:07:05 AM Then it can work. But currently, I had some cases, where I had six future blocks in a row, and then needed to slow down my miners, so I am not planning to get more power out of it, because after passing two hours limit, the risk of getting your block reorged is increased (because if you don't re-submit your block properly, then it won't be broadcasted automatically, if you mine it too fast). Code: 2024-09-02T05:25:52Z UpdateTip: new best=000000000000004ac75332dec3b2ed28f2e94a2a2a978b9373b9dd3e9e1dfa11 height=42334 version=0x27ba0000 log2_work=70.828749 tx=781363 date='2024-09-01T21:29:08Z' progress=0.999425 cache=0.3MiB(16txo) Checking older logfiles, this happened last night: Code: 2024-09-02T02:06:09Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465 As far as I understand the code changes, it changes the "window" from 2 to 20 hours. And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally? I wiped the testnet4 blockchain and restarted it, with the same result: Code: 2024-09-02T07:07:59Z UpdateTip: new best=00000000a5b18671cb77a85ed98cf64a3a9f97d3c5a3f661465f6bbe1e97a250 height=42327 version=0x20000000 log2_work=70.827931 tx=781321 date='2024-09-01T21:08:13Z' progress=0.999277 cache=75.7MiB(589834txo) What happened here? Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on September 02, 2024, 07:39:29 AM Quote And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally? Yes, it should be probably reverted back into 2 hours, if your goal is to have a stable environment, running 24/7. I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that. However, if you will change it into "2 hours 20 minutes" or "3 hours", then it may work better. I guess "20 hours" is definitely too much. But it was fine for me, because I didn't put enough mining power, to really reach those limits.Also, if you mine any block, which is moved forward beyond those two hours, then when it will fall back into two hours window (because time is naturally moving forward), then you probably have to re-submit such block, because it won't be submitted automatically. So yes, in general, if you are further than two hours in the future, then there is a huge risk of mining a chain, which will be reorged anyway. But: if you want to measure your mining power, then you need some way of doing that, and by having a secret, longer chain, you can measure, how many of your CPU-mined blocks will be reorged, when a single ASIC block will appear. And also, if you have a GUI version, then you will see all of those blocks as "stale" or "generated, not confirmed", or something like that. Quote Mempool.space is at block 42391 already. The funny thing is that if you have a full P2P node, then you should also notice, that mempool.space is not some centralized source of truth anymore. If you have only CPU blocks in conflicting chains, then you should probably see, on top of which chain, you have more chainwork, and more ASIC blocks. Because for example, I thought that "mempool.space confirmed? Then safe", but I stopped thinking in that way, when I successfully reorged mempool.space, and when ASIC miners started to build new blocks on top of my history, and not theirs. If you are a node runner, then you are really P2P peer, and you should focus on chainwork, and not "just some centralized block explorer".Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on September 02, 2024, 08:00:40 AM Quote And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally? Yes, it should be probably reverted back into 2 hours, if your goal is to have a stable environment, running 24/7. I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that. However, if you will change it into "2 hours 20 minutes" or "3 hours", then it may work better. I guess "20 hours" is definitely too much. But it was fine for me, because I didn't put enough mining power, to really reach those limits.Code: 2024-09-02T07:52:57Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=0 Quote Also, if you mine any block, which is moved forward beyond those two hours, then when it will fall back into two hours window (because time is naturally moving forward), then you probably have to re-submit such block, because it won't be submitted automatically. So you'll kinda need to "manually" keep track and upload them?Quote So yes, in general, if you are further than two hours in the future, then there is a huge risk of mining a chain, which will be reorged anyway. But: if you want to measure your mining power, then you need some way of doing that, and by having a secret, longer chain, you can measure, how many of your CPU-mined blocks will be reorged, when a single ASIC block will appear. And also, if you have a GUI version, then you will see all of those blocks as "stale" or "generated, not confirmed", or something like that. I don't want to measure mining power, I just wanted to feel the fun of mining blocks that I missed out of in 2009 ;)Quote Mempool.space is at block 42391 already. The funny thing is that if you have a full P2P node, then you should also notice, that mempool.space is not some centralized source of truth anymore. If you have only CPU blocks in conflicting chains, then you should probably see, on top of which chain, you have more chainwork, and more ASIC blocks. Because for example, I thought that "mempool.space confirmed? Then safe", but I stopped thinking in that way, when I successfully reorged mempool.space, and when ASIC miners started to build new blocks on top of my history, and not theirs. If you are a node runner, then you are really P2P peer, and you should focus on chainwork, and not "just some centralized block explorer".[/quote]I used mempool.space as an example, because I always assumed Bitcoin Core would follow the longest chain automatically. I'm still surprised it got stuck that many blocks in the past. I've wiped my .bitcoin directory again, to see if the unpatchedk Bitcoin Core now goes for the longest testnet4 chain. Update: it doesn't: Code: 2024-09-02T08:04:19Z UpdateTip: new best=0000000000000021760623041a7a1b78f92d80beec504f43a46edf27a8993787 height=42326 version=0x2c94e000 log2_work=70.827931 tx=781320 date='2024-09-01T20:48:12Z' progress=0.999185 cache=75.7MiB(589833txo) I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that. At the moment, testnet3 doesn't have 6 blocks in the future, it has someone who mines a block 2 hours ahead all the time:https://loyce.club/other/testnet3.png (source (https://mempool.space/testnet/mining/pool/unknown)) The ones with the long Coinbase tag look like ASIC miners. The ones with the short Coinbase tag have a Timestamp about 2 hours in the future. It looks like the ASIC Timestamp is also ahead, but less.It looks like this 2 hour ahead thing blocks your code changes. Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on September 02, 2024, 08:28:18 AM Quote Shouldn't it reorg on it's own to follow the longest chain? Maybe some developers are testing "7200 seconds rule" or "600 seconds rule"? If CPU miners push the time too much into the future, then after Median Time Past (MTP), miners have no chance to adjust the time backwards, and put the current time in their blocks. Which can cause some additional inflation, if it happens around difficulty adjustment.Quote So you'll kinda need to "manually" keep track and upload them? Only those, which are above two hours. And only if you use different settings, than most of the network. Because if 99% nodes would use 20 hours rule, then it would be "de facto standard", and if the heaviest chainwork would be there, then 2 hours rule would simply be lifted. Because there is no centralized source of time: if you have a brand new node, and it tries to download the whole chain history, it doesn't know, if the chain with 2^70 chainwork contains many years of history, or are there just two 2^69 blocks, with today's timestamp (and a lot of smaller ones, to adjust the difficulty).Quote I just wanted to feel the fun of mining blocks that I missed out of in 2009 After reaching two hours limit, you have those options:1. Stick to two hours rule, and stop mining, waiting for some ASIC block, to put the current time. 2. Stick to two hours rule, and still try to mine something, but with ASIC difficulty on CPU, which will likely just burn that power for nothing. 3. Produce a secret, longer chain, and do your testing, knowing that after a while, a new ASIC block will come, and destroy your chain (but in the meantime, you will have a fully working playground, to test non-standard transactions, mining power, or anything else). Also note, that when there was almost no competition, and we were mining CPU blocks alone, or with a few friends, or when it was "my first node vs my second node" or even "garlonicon's node vs vjudeu's node" then we didn't need to think about all of those consequences, and implications of those rules. But now, when more bitcointalk users will try CPU mining, we will probably encounter more issues, than we found, when we were alone, or with some small, closed and well-coordinated group of friends. We simply didn't put enough CPU power, to test some corner cases, like "more than 51% of blocks, mined by CPUs". To sum up: it is nice to see some competition: if more bitcointalk users will start mining testnet coins, then maybe some people will get some knowledge, for example "how hard is to CPU-mine things at difficulty one". Title: Re: Requesting Testnet4 tBTC Post by: garlonicon on September 02, 2024, 08:47:35 AM Quote it has someone who mines a block 2 hours ahead all the time Yes, I put "20 minutes and 1 second" for a reason: in this case, you can mine six CPU blocks for two hours. However, if you put instead "1 hour 59 minutes 59 seconds", or something like that, then your single CPU block will knock every CPU miner out, for the next 20 minutes. But: there is a catch: if someone will mine more CPU blocks in a row, then that single block will be reorged. So, if some CPU miner will send one block with "20 minutes 1 second", and second block with "40 minutes 2 seconds", then those two blocks will knock out that "1 hour 59 minutes 59 seconds" block.So, it is a game of CPU-mined chain reorgs. But: winning the game, and picking an optimal strategy, is a big challenge. Because the default implementation is definitely not the best one, and can be beaten by someone, who will write a better code, specifically for testnets. Edit: One more thing: any CPU miners can be easily stopped by ASIC miners, if they will simply change their strategy, to fully fill the queue of easy blocks, and only then mine their ASIC blocks on top of that. The fact, that CPU miners still have some chances, is a signal, that ASIC miners are just sticking with unmodified Bitcoin Core, and are not trying to get the maximum number of blocks, out of it. Or: maybe they don't have enough knowledge, to write a better code, and they don't want to risk mining invalid ASIC blocks. Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on September 02, 2024, 09:26:50 AM I started my default bitcoin-qt on testnet4:
Code: Number of blocks left: Unknown. Syncying Headers (42335, 99.8%)... Quote Shouldn't it reorg on it's own to follow the longest chain? Maybe some developers are testing "7200 seconds rule" or "600 seconds rule"? If CPU miners push the time too much into the future, then after Median Time Past (MTP), miners have no chance to adjust the time backwards, and put the current time in their blocks. Which can cause some additional inflation, if it happens around difficulty adjustment.Quote Only those, which are above two hours. And only if you use different settings, than most of the network. Because if 99% nodes would use 20 hours rule, then it would be "de facto standard", and if the heaviest chainwork would be there, then 2 hours rule would simply be lifted. Because there is no centralized source of time: if you have a brand new node, and it tries to download the whole chain history, it doesn't know, if the chain with 2^70 chainwork contains many years of history, or are there just two 2^69 blocks, with today's timestamp (and a lot of smaller ones, to adjust the difficulty). This goes right over my head. It's amazing Bitcoin has been working without major problems all those years.Quote After reaching two hours limit, you have those options: I think the 20 * 60 * 60 code changes did #3 by default, right? But then why doesn't it find new blocks anymore after block 42335?1. Stick to two hours rule, and stop mining, waiting for some ASIC block, to put the current time. 2. Stick to two hours rule, and still try to mine something, but with ASIC difficulty on CPU, which will likely just burn that power for nothing. 3. Produce a secret, longer chain, and do your testing, knowing that after a while, a new ASIC block will come, and destroy your chain (but in the meantime, you will have a fully working playground, to test non-standard transactions, mining power, or anything else). Quote Also note, that when there was almost no competition, and we were mining CPU blocks alone, or with a few friends, or when it was "my first node vs my second node" or even "garlonicon's node vs vjudeu's node" then we didn't need to think about all of those consequences, and implications of those rules. But now, when more bitcointalk users will try CPU mining, we will probably encounter more issues, than we found, when we were alone, or with some small, closed and well-coordinated group of friends. We simply didn't put enough CPU power, to test some corner cases, like "more than 51% of blocks, mined by CPUs". It's interesting to see though. I'm still flabbergasted my standard testnet4 node is stuck because of what looks like miners running non-standard code.Quote To sum up: it is nice to see some competition: if more bitcointalk users will start mining testnet coins, then maybe some people will get some knowledge, for example "how hard is to CPU-mine things at difficulty one". Considering how long it still takes to mine a block at difficulty 4 on a 5 years old Xeon CPU, this must have been much longer in 2009.Quote it has someone who mines a block 2 hours ahead all the time Yes, I put "20 minutes and 1 second" for a reason: in this case, you can mine six CPU blocks for two hours. However, if you put instead "1 hour 59 minutes 59 seconds", or something like that, then your single CPU block will knock every CPU miner out, for the next 20 minutes. But: there is a catch: if someone will mine more CPU blocks in a row, then that single block will be reorged.Quote So, it is a game of CPU-mined chain reorgs. But: winning the game, and picking an optimal strategy, is a big challenge. Because the default implementation is definitely not the best one, and can be beaten by someone, who will write a better code, specifically for testnets. Do I get it right that this only works on testnet because of the difficulty drop after 20 minutes? Wouldn't it be better to change the default rules, let's say the difficulty drops only after 3 hours, so normal mining isn't affected? Or reduce the time difference between miners to no more than 10 minutes instead of 2 hours?Quote Edit: One more thing: any CPU miners can be easily stopped by ASIC miners, if they will simply change their strategy, to fully fill the queue of easy blocks, and only then mine their ASIC blocks on top of that. The fact, that CPU miners still have some chances, is a signal, that ASIC miners are just sticking with unmodified Bitcoin Core, and are not trying to get the maximum number of blocks, out of it. Or: maybe they don't have enough knowledge, to write a better code, and they don't want to risk mining invalid ASIC blocks. Thanks for the explanation. I'm still amazed people have been burning ASIC power on testnet for years.@garlonicon's signature: I still can't wrap my head around dealing with private keys in descriptor wallets, so brainwallets aren't really an option at the moment. I'll give it a try when Electrum supports testnet4. It turns out I did mine block 42335 (https://mempool.space/testnet4/block/00000000542792e54a720567ba66157d48cdae7bfd01c1b678d0f07a2ed56e99). How come multiple nodes can't get passed this block? Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on September 02, 2024, 10:10:19 AM Quote I think the 20 * 60 * 60 code changes did #3 by default, right? It starts with #3, and then, it rejects your own blocks, which is the same, what happens, if you run out of two hours. By changing from 2 to 20 hours, you just accept more blocks, but in general, if they are CPU-mined, then there is a huge risk, that they will be reorged.Quote But then why doesn't it find new blocks anymore after block 42335? Because the difference between block 42335 and block 42336 is 11 minutes and 6 seconds. And if you enforce 600 seconds rule, then this ASIC block doesn't meet it. Which means, that if you enable BIP 94, then you land on a shorter chain.So: do you want to disable 600 seconds rule? Quote Code: if (consensusParams.enforce_BIP94) {For now, I simply use some version without those timewarp protections. I don't know, what will happen after block 42335: maybe the current chain will be reorged, or maybe it will be grandfathered in, and the activation of all BIP 94 rules will come later. Who knows, time will tell. So, if you want to switch to a longer chain, then upgrade your master, switch MAX_TIMEWARP from 600 to 7200, or use some version, where it is entirely disabled, like probably mempool.space is doing. Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on September 02, 2024, 11:09:42 AM Because the difference between block 42335 and block 42336 is 11 minutes and 6 seconds. And if you enforce 600 seconds rule, then this ASIC block doesn't meet it. Which means, that if you enable BIP 94, then you land on a shorter chain. I take it BIP 94 is enabled already by default. I read bip-0094.mediawiki (https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki):Quote To protect against the time warp attack, the following rule proposed as part of The Great Consensus Cleanup[5] is enforced: "The nTime field of each block whose height, mod 2016, is 0 must be greater than or equal to the nTime field of the immediately prior block minus 600. For the avoidance of doubt, such blocks must still comply with existing Median-Time-Past nTime restrictions." I won't claim to understand it entirely, but it looks like the problem arose because 21*2016=42336. And that block gets rejected.But, if that's the default, how come most nodes continue nonetheless? I guess this does explain why mining 20 minutes in the future is no longer possible. Quote So, if you want to switch to a longer chain, then upgrade your master, switch MAX_TIMEWARP from 600 to 7200, or use some version, where it is entirely disabled, like probably mempool.space is doing. I guess this is the path to go. I don't want it to be stuck until someone changes something.Code: vi test/functional/mining_basic.py Title: Re: Requesting Testnet4 tBTC Post by: sjors on September 02, 2024, 12:11:27 PM The timewarp attack mitigation for testnet4 requires the first block of a new difficulty adjustment period to have a timestamp later than that of the last block of the previous period.
Initially there was a 7200 second (2 hour) grace period. This was changed to 600 seconds (10 minutes) two weeks ago: https://github.com/bitcoin/bitcoin/pull/30647 (matching the original Great Consensus Cleanup proposal). This change is effectively a soft fork on testnet4, but with no activation mechanism. Anyone who runs the v28.0rc1 release candidate, or a very recent master, will enforce it. Anyone who runs an older version won't enforce it. My guess is that most miners on testnet4 haven't updated yet. Even if they did that today, the node won't automatically go back to validate old blocks. If enough miners switch to v28.0(rc...) and call `invalidateblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` followed by `reconsiderblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` they will reject the block at height 42336. This will lead to a one day reorg, or more if it's done later. An alternative approach would be to change Bitcoin Core to enforce the modified timewarp rule from a certain flag height in the future, but that seems like a lot of complexity for a test network that hasn't even been released yet. As an aside: the SegWit soft fork did have a mechanism for handling this situation. If a user upgrade their pre-segwit node to a segwit node sometime after activation, it would roll back the chain and check everything again. Title: Re: Requesting Testnet4 tBTC Post by: sjors on September 02, 2024, 12:17:25 PM By the way, I think what happened here is that someone tried to CPU mine coins on testnet by setting their clock > 20 minutes into the future.
Such a block would be accepted by all nodes (upgrade or not). But v28 nodes then require the next block to be >10 minutes in the future, whereas before they would allow 1 hour and 50 minutes in the past (which includes the present). v28.0rc1 contains a fix for the Bitcoin Core miner code (getblocktemplate, etc) that ensures timestamps are adjusted: https://github.com/bitcoin/bitcoin/issues/30614 --- Update: the above invalidateblock / reconsiderblock sequence won't work (https://github.com/bitcoin/bitcoin/issues/30786#issuecomment-2324677976). The only way to get an upgraded node to re-check the timewarp rules is: Code: bitcoind -tesnet4 -reindex Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on September 04, 2024, 06:50:31 AM I'm not sure what's the best thread, so I'll just post it here: testnet3 (https://mempool.space/testnet)'s mempool is currently empty. For the past months, mempool was full and fees where high. It looks like the "data spam" suddenly stopped, while ASIC miners and "20 minute miners" have halved the block time.
Amazingly, that means testnet3 can now actually be used again for testing :) Title: Re: Requesting Testnet4 tBTC Post by: vjudeu on September 04, 2024, 07:47:34 AM Quote testnet3's mempool is currently empty It's nothing new. There are waves of transactions: sometimes mempools are full, sometimes they are empty. And the cost to fill up the whole 300 MB is quite low.And note that even if mempool.space shows you a fully filled mempool, then it doesn't mean, that you have to pay that much. For example: if some CPU mining node is just starting up, then it could have an empty mempool, and fetching all of those transactions in P2P way is quite slow process, and if you can see a low block health, then it doesn't always mean censorship: it could mean as well, that this particular miner just turned on its node, and it was turned off recently, for whatever reason. And during that time, you can get your transactions confirmed cheaper, if you send it to that particular node. Which means that again: the default fee estimation is far from being optimal, because it doesn't consider such details. Quote that means testnet3 can now actually be used again for testing You can always mine future blocks, and prioritize your own transactions. And you can pay zero fee in your own transactions, if you are a miner. And even if there is some opportunity cost, then statistically, sometimes blocks are not fully filled, and in a general case, it makes a lot of sense to send and mine your own transactions with a low feerate (also because if you use less than 1000 sat/kvB, then you can "cancel" that easier, in case of mistakes).Also note, that if you want to mine some coins, then you can do that on signet, too: https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937 Title: Re: Requesting Testnet4 tBTC Post by: ercewubam on September 04, 2024, 10:33:38 AM Quote Amazingly, that means testnet3 can now actually be used again for testing Not only that. It also means, that mining testnet3 is now less profitable, and switching into testnet4 is a better idea. But a short while before that, it was the opposite, when it was not certain, if testnet4 will be reorged or not. Now we know, that those, who consider 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 as a valid block, are simply mining coins, which will vanish, after upgraded ASICs will mine an alternative chain, on top of 0000000000000016be66ab39af9f97e1294080c94d0a34cc304e391794a481bd.In general, we are about to see at least 360 blocks reorg, at the time of writing. I guess it could be 500 blocks reorg, or even 1000 blocks reorg, depending on how many people will mine blocks, when using some older version. Title: Re: Requesting Testnet4 tBTC Post by: ABCbits on September 04, 2024, 10:59:32 AM I'm not sure what's the best thread, so I'll just post it here: testnet3 (https://mempool.space/testnet)'s mempool is currently empty. For the past months, mempool was full and fees where high. It looks like the "data spam" suddenly stopped, while ASIC miners and "20 minute miners" have halved the block time. Weird, since yesterday testnet3 was busy where mempool.space recommend over 500 sat/vB for high priority TX. I wonder if most ordinal/rune created on testnet3 no longer have value. Amazingly, that means testnet3 can now actually be used again for testing :) Although i wonder how easy is it to obtain testnet3 coins now (aside from mining). Tesnet faucet was abused on many occurrence. Title: Re: Requesting Testnet4 tBTC Post by: LoyceV on September 04, 2024, 11:03:08 AM Weird, since yesterday testnet3 was busy where mempool.space recommend over 500 sat/vB for high priority TX. I wonder if most ordinal/rune created on testnet3 no longer have value. Just like I've speculated about it on real Bitcoin, I think here the ordinal spam also comes from only one person. That explains why all transactions are in the same style, and start and stop at the same time too. |
