setting up testnet4 in a container

I've decided to revamp the containers to make them even safer and easier to manage. To keep this convo focused on the new container images, I'm starting a new thread here. If you have questions about the old discussion that aren’t covered here, just send me a PM or jump over to the new thread! Hey everyone, thought I’d share what I'm working on right now. I was part of a previous thread discussing a possible switch to testnet4. In that convo, I quickly figured out how to merge the pull request for testnet4, but then I realized I want to make this more reproducible... So, I went ahead and created a docker image you can run easily yourself. You can either build the image on your own (it should work for you), or you can grab the one I built from Docker Hub. After that, just make a simple docker-compose.yml file. Just remember to update the volume path to one that exists on your machine and change the rpc user and password. Then all you have to do is run "docker-compose up -d" to fetch the image and start bitcoind. Once it’s up, connect to the container and set up a wallet. Here’s a testnet4 tipping address: tb1qumlhr8tn9gsdyujy464jkk4c5r488u8kxteyx5 (only send testnet4 tBTC!)

I have tried to put a "mining" image together aswell: you can build it yourself, or get if from dockerhub mocacinno/btc_testnet4:cpuminer if you use this docker-compose.yml to start: you can afterwards log in to the running container like this: and start cpu mining like this (replace my address by yours offcourse) the problem is the only vps i currently have is slooooooooooooooow (it's a small vps from hostnamaste and they seem to have overloaded their hosts. Logging in takes about 2 minutes, let alone running a cpu miner)... I barely get 20 Mhashes per second (really, not kidding......). I have no idear if the mining actually works, since at this hashrate i will not find anything. update it seems like somebody is running an asic on the testnet4... hashrate is 425 Th, so my 22Mh is < 1/19.000.000 of the current network hashrate... On average, i'd hit one block every >300 years. I just hope this asic-miner turns off his asic from time to time to give the cpuminers a chance... Maybe i have to dust off my old geccoscience compaq... If i remember correctly it hashed somewhere at the 50 Gh range??? At least i'd have 1/8500 of the total network hashrate, and i would be able to mine a block every couple of months... ~sigh~

That will continue to be an issue forever with anything that is 'low use' and has a mining algo that has asics for it. There are so many 2 or 3 gen out miners that are just sitting there that it's not a big deal to mine something worthless with it. The difference in loss for the cost of power between something that has $0 value and the potential profit of mining BTC (or LTC or whatever) that has value but a difficulty that is that high is just about nothing. Back to this, has anyone been able to compile this for windows? I tried last night and got a bunch of errors. Was exhausted and doing it remotely and just went to bed. Didn't even record the errors. -Dave

Great job mocacinno, you automate the full process. Now people can start working with Testnet 4 in an easy way. And it would be if user could mine with CPU, but as you say, 1 modern iner would kill that option for all. It would be fun to include a rule on the node setting a limit for miners. But i know that's not possible because that would not only affect the big engines, but would affect the pools too.  This gives me the idea of opening a mining pool for tBTC 4, that way even if users do not have the hardware, they could get a small piece of the cake with their CPU. But tBTC4 is still green, let's give it some time to mature. And again, thanks for the apport.

I built (yet another) image that is including c-lighting + a simple walktrouh I've updated the info on dockerhub: https://hub.docker.com/repository/docker/mocacinno/btc_testnet4/general If anybody is interested, i'm running two bitcoin nodes on testnet4, and two testnet4 lightning nodes on top of my bitcoin testnet4 node... I'll be AFK during the weekend, but when i get back on monday, i'll see if there are people interested in connecting to my testnet4 lightning node, creating some funded channels and creating some invoices the Dockerfile itself is as follows:

Thank you very much. I am launching the testnet4 docker container in live. Great work! 🔴 [Live] The Note block explorer is currently syncing with the BTC Testnet4. We've throttled the speed to one block per second so you can observe this process in real-time. Check it out here:  https://testnet4.noteprotocol.org And For the main network https://explorer.noteprotocol.org

new image available: mocacinno/btc_testnet4:ckpool you can either pull this image, or build your own... The Dockerfile is available from my git repo: https://github.com/mocacinno/btc_testnet4/tree/ckpool currently running @ my vps IN SOLO MINING MODE with 2% donation... example cpuminer command to mine on this testnet4 pool: or if you prefer minerd: offcourse, exchange my testnet addy by yours i give no guarantee whatsoever, not even that i configured this pool correctly... It's testnet guys... The pool will run untill the vps crashes (i rented this vps for the sole purpose of testnet4 containerisation, so when my work is done, i'll no longer pay for it). no user interface or stats available... you either trust me to run the pool, or you run your own (which is really easy using the container image provided).

Is there an option to always get block headers with minimal difficulty? Or maybe you use just the default settings, and those CPU miners are trying to compete with ASICs, and their difficulty? Edit: If you use just the default settings, then I guess manual adjustment of time and difficulty would work, and would form a proper share, right? The main question is: if I would fetch some 80-byte header, and change those two fields, to make it CPU-mineable, and submit a share at difficulty one, then it would be accepted or not?

I'm not completely sure about the inner workings of ckpool to be honest... I did set the minimum share diff to 1, aswell as the starting diff. I'm cpu mining myself, and every share i've sent was valid if it had a diff of >= 1. I did solve two blocks whilst solo mining with my cpu on my own solo pool, but by the time they got relayed they were already stale. If no block is found for 20 minutes on the testnet, the diff resets to 1, and you have a very brief window before one of those ASIC miners solves and relays a block at diff 1. It's a longshot tough, and so far my 2 "solved" blocks did not make it into the blockchain.

The window to mine it is quite wide. The window to broadcast it is shorter, but only if the network is two hours in the future, like testnet3. For testnet4, as long as you don't see blocks from the future, you can safely submit them, and get them confirmed, even if you mine them on your CPU. Example modification in Bitcoin Core, that could help mining blocks on CPU: Then, each and every call to "getblocktemplate" will return the minimal difficulty. And also, if you replace for example "2 hours rule" with "20 hours rule", then you can work on blocks, which are not yet broadcasted, but will be, as the clock in other nodes will get there.

ELI5 for me garlonicon: does this mean you're always mining at difficulty 1, so you have a block ready the moment the difficulty drops after 20 minutes without a block?

Yes. Because if you have a field in the block header called "difficulty", then you have to put something there. And you have a choice: putting the real difficulty, or the minimal one. If you have an ASIC, you can put the real one. But: if you mine for example a half-baked block with your ASIC, then you cannot submit "the best header you did", because it does not meet the network difficulty. After 20 minutes, even if you have ASIC, you have to switch to the minimal difficulty, and mine it separately. So, the conclusion is: all is left to the network propagation. Both CPU and ASIC miners have their blocks with minimal difficulty, prepared in advance. And then, the winner is not the one, who can mine it faster. The winner is the one, who can propagate it faster. And for that reason, you can compete with ASICs, and mine some blocks even on your CPU. But obviously, this method is not bulletproof. First, if you have some ASIC, then you can decide to reorg all CPU-mined blocks, and nobody will stop you. Second, you have to mine and propagate a block. Serious miners are well-connected, so if your propagation is worse, then you will get a block, but it will be stale. Edit: One more thing: obviously, if someone is mining with CPU-only difficulty, then the time of the block is set to 20 minutes. But the real difficulty is set to 10 minutes. So, it is normal to have ASICs in-between. Another observation is that mining on top of some ASIC block is the easiest thing to do, because ASICs usually set the real time in their blocks, while CPU miners are working on the future, for example one or two hours forward (so after some ASIC block, there is a wider room for propagating new CPU blocks).

I'm searching for a guinea pig... I just upgraded lightning core from 24.02.2 to 24.05 in my development container image... However... I'm already renting 2 VPS's right now with the sole purpose of testnet4 containerisations and they're both running a container image i modified and not yet saved, so i'm unable to test the new version out without renting yet another vps (unless i start messing with ports, which is a hassle) On dockerhub, i'm keeping the stable versions, so if you pull from dockerhub, you should always get a working setup. On github, i have a CI/CD pipeline that automatically builds when i commit to my master branch. So on github, i have the "unstable/untested" versions (like the latest version containing the core lightning upgrade). Is there anybody willing to pull v0.0.3 from github and test core lightning? The build process is completely transparent and automatic, so you can verify i didn't mess with the image you can see the dockerfile for this image here: https://github.com/mocacinno/btc_testnet4/blob/main/Dockerfilethe actual build of the image is here: https://github.com/mocacinno/btc_testnet4/actions/runs/9512334263and the resulting image is here: https://github.com/mocacinno/btc_testnet4/pkgs/container/btc_testnet4/229974487?tag=latest Offcourse, you're welcome to just take the dockerfile and build it yourself. Basically, i'm looking for somebody to follow the following walktrough: https://github.com/mocacinno/btc_testnet4/tree/lightning, but when the step "edit the docker-compose.yml file" is suggested, also replace the image on dockerhub by ghcr.io/mocacinno/btc_testnet4:latest On my modified node, i also have core lightning 24.02.2, so i only need one person to test out the new image, since the "guinea pig" can just connect to my node to open a channel. Offcourse, i'll send some tBTC (testnet4) to cover channel creation to whoever volunteers I'm going to Susecon in Germany for most of next week, so i'll be AFK starting this evening up untill next thursday. If i cannot find a volunteer by this evening, i'll have to postpone the testing untill friday the 21st of june.

I decided to completely re-design the containers to make them (even more) safe and to make them easyer to maintain. In order not to clutter this discussion and focus on the new container images, i started a new thread: https://bitcointalk.org/index.php?topic=5501093 If you have any questions about this old discussion that isn't solved in the new thread, shoot me a PM or switch to the new thread instead!