Topic: [Guide] Solo mine testnet bitcoins with cgminer, Bitcoin Core, and a Compac F (Read 1898 times)

All getting a bit off-topic here...  

Perhaps best to export these S9 questions to a separate thread?

At least, i don't remember any change or update since it's created on 2012. Meanwhile Stratum V2 exist, although AFAIK the adaption is very slow.


There's possibility some mining pool may use Bitcoin Core's GBT to create block they'll mine. But Stratum doesn't know or care how it's created.


At a glance, your config seems to be right. Have you tried checking debug.log file created by Bitcoin Core? It may give some hints why public-pool unable connect to Bitcoin Core.

Hi ABCbits,

Sorry jumping on your thread updates here.

Is GBT outdated? I didn't think it was. Perhaps I've misunderstood something all this time but isn't Stratum just a bridge between Bitcoin core GBT and pool services?

Thanks

G.

You're welcome. I've spent days chasing typo's before it can get real frustrating.

Good you got it working.

Thank you sooooooooooo very much for this! I spent days trying and trying and couldn't find what I missed. It works now.

Try your local net address instead of what I think you have mistyped.

127.0.0.1 not 172.0.0.1

I bought a second hand red compac F miner, and followed your instructions. I need help to get it working.

Bitcoin Core, cgminer and the compac F are installed on the same system.

I use this:



I think I can skip this because the code on github is updated already:
.
I use this (last comma removed, thanks n0nce)

It doesn't work. I get:
A minute later:
2 minutes later:

Why can't cgminer connect to Bitcoin Core? What do I have to change?

The changes aren't that difficult to do if you're careful patching them into the correct locations. If I recall most of it is in cgminer.c and there's only a handfull of functions that are affected.

I'm no expert on driving GIT otherwise I'd create my own branch with the adaptations already done.

I don't know if Kano is interested in porting in the GBT mods from cmmodtools, they released these updates quite a long time ago and its never made it back into the master branch.

Nice, I wonder if kano would be OK bringing those changes upstream.

At least for me, @kano branch of cgminer is the one that I use whenever I build cgminer after CKolivas stopped development.

Hopefully there is only one branch with all the required changes.

A bash script to mine coins on derived addresses, to improve privacy:
Of course, instead of bitcoin-cli, the same trick can be used to mine on mining pools. However, note that many pools require producing at least N shares before paying anything, so make sure you produce enough, before you switch to some other address. But: as far as I understand it, that method of switching addresses seems to be good enough, right?

I also thought about mining on silent payment addresses, but I have to think about deriving it properly, because existing clients don't understand "sp1q" addresses.

I have something of my own creation a somewhat overclocked (725Mhz) BM1397 that averages 480GH/s, its using about 18Watts at the DC port including the power for the fan and the RaspberryPI Zero 2W thats controlling it.

Presently its pointing at CK pool, but I had it running on my local node for about a week without any issue.

Updating Kano's CGMiner is a bit of a chore but its achievable provided you follow the differences carefully.

Good luck!

Thanks for the reply, I am going to get a bitaxe supra I think and do this method. What is giving you 500G/H? How much power?

Goodluck!

I don't think the nodes connected to other nodes is any different to any other machine connecting to a server elsewhere on the net, it still has to traverse the same gateways, routers, switches and other network infrastructure.

Bitcoind looks like it handles all of the node to node connections automatically anyway. In that respect it looks no different from any other DNS lookup or TCP/IP communication.

Presently I just can't see anything to support the claim that mining solo to a pool is any better than mining directly to bitcoind beyond the fact that someone else has taken the time to set-up and maintain the pool and all the backend side of it reducing the initial technical hassles.

Once I have a couple more mining boards built, I'll point them at my bitcoind server and let them run indefinately, if by chance (and it is a remote chance) they hit a block I'll celebrate that here!

Cheers

G.

Aside from latency, i also hear claim that node run by mining pool connected to other node which belong to different mining pool and node run by major company. Anyway, i agree the biggest reason to use them is we don't have to setup and maintain stuff.

I know, alledgedly pools are supposed to have lower latency.

TBH I'm not so sure given I have a low latency GBit fibre connection to the internet I cant see why it'd be any less effective than a server in a data centre somewhere that only has a 400Mbit capped link tied to it. Unless the other bitcoin nodes are located in the same data centre, the latency between nodes would be similar.

Anyway, this was purely a fun experiment and technical exercise to see if I could get it to work.

I merged the changes from https://github.com/cmmodtools/cgminer into the last maintained version of cgminer 4.12.1 https://github.com/kanoi/cgminer/ and getting it to build, that was technical exercise 1.

Then the challenge was getting bitcoind running and accepting RPC connections for testnet, that worked ok then moving over to mainnet.

Once I'd figured that the named block in the config file was [main] not [MainNet] or [mainnet] it all started to work as it did for testnet, although it did take nearly 3 days to sync the blockchain.

Its been running overnight and statistically its performing similar to that of a pool looking at the volume of data exchanged and the current best share.

There's nothing presently that makes me think solo mining to a pool has any advantage, of course I dont know how things would perform should it hit a block and if the block would successfully propagate. Like I said it could be a very long time before I found out.


Never the less with that said, I guess it's easier to rely on someone else's technical expertise in setting up the bitcoind and maintaining the back-end of things.

Aside from low hashrate, you probably better use solo mining pool (such as ckpool or kano) which supposed to offer better block propagation speed.

I know I'm late to the party with this one but, for mainnet you have to change the [test] to [main] as well as removing testnet=1


Anyone's guess as to if it'll actually mine a valid block, but it does seem to be running.


With 500GH/s pointed at it, I guess I'll be waiting a while to find out.  

Actually, I got maybe 6 or 7 'regular difficulty' (67.108.864 - only 30% lower than what it should probably be) blocks in just a couple of days now. I have to check the numbers, but it seems very unlikely to be this lucky this often.

I believe so, too. Even a CompacF takes just a fraction of a second.
Actually, one reason that might explain how I'm able to get almost every single 1-difficulty block is that 'regular' miners connect to a pool, meanwhile with nullama's method, we connect to our own full nodes. This should surely result in a smaller delay.

I'll run some numbers as soon as I can; likelihood of mining a 67M block (normal distribution), as well as ratio of 1-diff blocks I was able to scoop up vs. the total number in a given period of time.

There's no point in trying, if it's once in a million (or maybe billion). That means it will probably never happen, and that's what makes CPU mining futile.

At difficulty 1, getting the data from your pool may already take more time than an ASIC miner needs to find the next block.

Well, your gains will be always proportional to your power, in the long-term perspective. Which means, CPU-based miners will lose that battle very, very often, but once per N blocks, they could win. Or rather, to make it realistic: a pool of CPU miners could win.

Also, for that reason I left mining testnet3, and tried merged-mining with mainnet difficulty, but in a model, where each miner has its own difficulty, and is always rewarded every 10 minutes. Because one of the problems with testnet3 is that so much power is "wasted" into mining worthless coins. In that case, merged-mining fits better, because you can get coins that are almost worthless, but not quite. And you can easily test that kind of things inside LN, where normally you would have to pay, but if you are a miner, you can use your computing power as your currency. Also, because normally nodes don't want to pay you, what you can focus on is cheaper transactions: a node can give you some discount, or process some transactions for free, if you show your shares.

It is simple: if you have any mining power, then mathematically, you can always hit a block. Your blocks are as good as produced by any huge miner. So, instead of hitting some block every 10 minutes, you can hit it every day, every week, or even every month. But it also means, once per year you can hit three blocks in a row, or something like that. But then, you should not fall into gambler's fallacy, and think that you will hit the next block in the same day, if you were extremely lucky for a while.

It is not something you can fix. Your calculations are correct. But the very low probability, close to zero, does not mean that something will not happen. Even if you reach zero in your calculations, you could still encounter such situation in the real world.