SoloMining with CGMiner against Bitcoind / Bitcoin Core v0.18.1

[Sledge0001]

Okay so my efforts came up empty with the solomining using CGMiner 4.1.12 on the latest Bitcoin Core v22.  So since this info seems to be difficult to come by I figured i would continue my journey and attempt to document it and ask questions along the way:-)

So.... I decided to try my luck with getting BitcoinCore v0.18.1 running which I seem to have accomplished a good portion but still could use guidance....

Here were my steps:
1. I downloaded v0.18.1 https://bitcoincore.org/bin/bitcoin-core-0.18.1/ and synced the full node. It took just over 26 hours to fully sync.

2. After what feels like waiting for an eternity I have my full node running on an internal static IP of 192.168.50.151 and my Miner is running on a static IP of 192.168.50.217

3. To get the miner on my LAN to connect to the full node here is what I added to my Bitcoin.conf file
(Obviously your network settings and username / passwords will most likely be different):

Code:

server=1
listen=1
daemon=1
rpcuser=USER
rpcpassword=PASS
rpcallowip=192.168.50.217
rpcallowip=192.168.50.0/255.255.255.0
rpcallowip=127.0.0.1
rpcbind=192.168.50.151
rpcport=3333

Some notes:
*Without the rpcbind= in the Bitcoin.conf file I was only able to mine locally on the full node. I was not able to mine from any remote hosts on my LAN. So if you are only interested in mining directly on the full node you can do so by creating the CGMiner startup batch with the following:

Code:

cgminer -o http://localhost:3333 -u USER -p PASS --btc-address YOURBITCOINADDRESS

Now by adding the rpcbind=192.168.50.151 it broke the ability to mine locally to localhost however I found out I was then able to still mine locally on the full node as well as mine to the full node on remote machines by using the full nodes IP address of 192.168.50.151 in the startup batch like this:
  

Code:

cgminer -o http://192.168.50.151:3333 -u USER -p PASS --btc-address YOURBITCOINADDRESS

The rpcallowip= sections essentially whitelists the IP addresses you are allowing to connect to your full node for the purposes of mining. I would suggest keeping these IP addresses limited to your LAN.

Now with these settings I do believe I have CGMiner connecting correctly to BitcoinCore as I am seeing activity on the miner side however I am not seeing Accepted shares or Rejected shares. I understand this is due to not having a result sent back from an actual mining pool.

I can now see that I am submitting shares (I belive this is correct) since I can now see the best share number as seen here:



Now in most of the solomining threads or videos I came across I see people use the generate=true command in the CLI to enable mining however this doesn't seem to work for me as I get a json error. The results of running this command are:

Code:

The wallet generate rpc method is deprecated and will be fully removed in v0.19. To use generate in v0.18, restart bitcoind with -deprecatedrpc=generate.
Clients should transition to using the node rpc method generatetoaddress
 (code -32)

Here is what my getmininginfo results looks like:


Would love to know if anyone has recommendations on if I am on the right path!!!!

[100knot2dae]

Your setup looks quite good.  But note that cgminer does not support BECH (bc1...) addresses for solo mining, so stick to legacy addresses p2pkh (1...) here.

In general, I would suggest to first mine some low diff bitcoin-forked altcoin (for example Bitflate or Widecoin) for testing purposes. So that you can verify your setup and make sure that you actually find blocks.

To avoid having the rpc password stored in plaintext in the bitcoin.conf config file, you can use rpcauth.py to generate a salted password hash, see https://github.com/bitcoin/bitcoin/blob/master/share/rpcauth/rpcauth.py

[Biffa]

I guess the true test will be if you find a block, hopefully no-one else finds it at the same time and you can propogate the results out the rest of the network fast enough so that it recognizes your result before anyone elses.

[Sledge0001]

Your setup looks quite good.  But note that cgminer does not support BECH (bc1...) addresses for solo mining, so stick to legacy addresses p2pkh (1...) here.

In general, I would suggest to first mine some low diff bitcoin-forked altcoin (for example Bitflate or Widecoin) for testing purposes. So that you can verify your setup and make sure that you actually find blocks.

To avoid having the rpc password stored in plaintext in the bitcoin.conf config file, you can use rpcauth.py to generate a salted password hash, see https://github.com/bitcoin/bitcoin/blob/master/share/rpcauth/rpcauth.py

Noted and changed the BTC address. Thank you for this!

I'm not overly concerend with the RPC call showing the password in plain text as the LAN is isolated from the WAN and world so the plain text password doesn't concern me too much but I will look into modifying this in the future.

I guess the true test will be if you find a block, hopefully no-one else finds it at the same time and you can propogate the results out the rest of the network fast enough so that it recognizes your result before anyone elses.

Dedicated Fiber internet so I think I would be good on the network side.

I am most concerned if I have my setup correct!

[philipma1957]

The odds of finding a block with 22 th are about 1 in 144 years.

Assuming we stay flat.

It would be funny if the op beats those odds and gets orphaned , but the likely hood of hitting the block and getting orphaned

would be once every 1440 to 7220 years.

Assuming 10 to one up to 50 to one for the Orphan. x the 1 time in 144 years for the block.

[100knot2dae]

Your setup looks quite good.  But note that cgminer does not support BECH (bc1...) addresses for solo mining, so stick to legacy addresses p2pkh (1...) here.

In general, I would suggest to first mine some low diff bitcoin-forked altcoin (for example Bitflate or Widecoin) for testing purposes. So that you can verify your setup and make sure that you actually find blocks.

To avoid having the rpc password stored in plaintext in the bitcoin.conf config file, you can use rpcauth.py to generate a salted password hash, see https://github.com/bitcoin/bitcoin/blob/master/share/rpcauth/rpcauth.py

Noted and changed the BTC address. Thank you for this!

I'm not overly concerend with the RPC call showing the password in plain text as the LAN is isolated from the WAN and world so the plain text password doesn't concern me too much but I will look into modifying this in the future.

I guess the true test will be if you find a block, hopefully no-one else finds it at the same time and you can propogate the results out the rest of the network fast enough so that it recognizes your result before anyone elses.

Dedicated Fiber internet so I think I would be good on the network side.

I am most concerned if I have my setup correct!

Probably the easiest way to verify your setup is to run testnet (testnet=1). But use a different BTC address then and backup your synced mainnet blockchain first, not sure if this wouldn't get overwritten by the testnet sync.
In regards to the shares, the "Accepted" value will only increase when a block was found. On solo, it's all or nothing

Last but not least, you can also try to run a more recent version of the bitcoind with cgminer, using my coinbaseaux flag patches (which include some display optimizations for solo mining): https://github.com/vthoang/cgminer/pull/12
Haven't tried yet if these patches apply cleanly also on the lastest cgminer code with GSF support, but probably it will work just fine.

[Sledge0001]

The odds of finding a block with 22 th are about 1 in 144 years.

Assuming we stay flat.

It would be funny if the op beats those odds and gets orphaned , but the likely hood of hitting the block and getting orphaned

would be once every 1440 to 7220 years.

Assuming 10 to one up to 50 to one for the Orphan. x the 1 time in 144 years for the block.

Come on Philipma that's bad mojo and hopefully that won't happen!!!  

I have been in IT for years and have successfully been mining Eth, RVN and Zil for quite some time. Currently I have 48 GPU's pushing over 3.5Gh/s and fully understand that with solo mining BTC the odds are against me.

The idea behind this is not only to run sidehacks USB miners but also to expand to actually mine BTC going forward. However the USB miners are a great way for me to hopefully show a solid proof of concept.

I'm litterally looking at commercial warehouse spaces in Nevada for this next phase of my expansion.

So try to help a brother out with encouraging words!

[Biffa]

What you're doing is fine as long as its a learning experience and you don't expect any returns.

None of us know your background, Phil is just letting you know that if you are doing it with the expectation of making it rich, well thems the odds

Otherwise, carry on brother, looks like you are having fun and learning along the way.

[Sledge0001]

By the end of next week I should have a total of 25 x Compaq F's and 6 x 2Pac Miners chewing away. 

To be perfectly clear I have no expectations on a financial return with my current setup or hitting a block. My ETH mining has already left me very well positioned so figured time to expand!

It would be incredibleto hit a block don't get me wrong but since my hash power is small when you compare it to the network hashpower and those 110TH (and soon to be 140TH) commerical miners.

This is truly a learning experience mixed in with yeah a lottery ticket.

I figured might as well learn as much as I can over the next month or so before I migrate my gear to a new place and then look to scale up once i'm more confident with my knowledge base with much more expensive gear.

[kano]

...

I guess the true test will be if you find a block, hopefully no-one else finds it at the same time and you can propogate the results out the rest of the network fast enough so that it recognizes your result before anyone elses.

Dedicated Fiber internet so I think I would be good on the network side.
...

Alas a "Dedicated Fiber internet" doesn't mean your block gets out to the rest of the world fast.
(even I don't consider my home Gbit fiber internet to help me much in that respect)
You need to get it to all the large pools fast, since while they don't have your block, they are mining something else.
You need nodes around the world and a faster way to distribute blocks.
e.g. on my pool it takes a tiny network packet of around 200 bytes to distribute (only) my pool's blocks all over the world, and that starts at the node you (must be) mining directly to.

[Sledge0001]

...

I guess the true test will be if you find a block, hopefully no-one else finds it at the same time and you can propogate the results out the rest of the network fast enough so that it recognizes your result before anyone elses.

Dedicated Fiber internet so I think I would be good on the network side.
...

Alas a "Dedicated Fiber internet" doesn't mean your block gets out to the rest of the world fast.
(even I don't consider my home Gbit fiber internet to help me much in that respect)
You need to get it to all the large pools fast, since while they don't have your block, they are mining something else.
You need nodes around the world and a faster way to distribute blocks.
e.g. on my pool it takes a tiny network packet of around 200 bytes to distribute (only) my pool's blocks all over the world, and that starts at the node you (must be) mining directly to.

Kano,

I was mining to your solo pool to begin with. I chose to go this route is because I kept getting logged out of your pool and with me gifting 2 co-workers Compaq F sticks we all couldn't login from the same network without getting locked out.

Any chance you can whitelist a static IP for me so we can all login simultaneously? If so I will come back!

IP address sent in a PM..

[kano]

...
Kano,

I was mining to your solo pool to begin with. I chose to go this route is because I kept getting logged out of your pool and with me gifting 2 co-workers Compaq F sticks we all couldn't login from the same network without getting locked out.

Any chance you can whitelist a static IP for me so we can all login simultaneously? If so I will come back!

IP address sent in a PM..

Miners don't get locked out that way.

You may get locked out of viewing the web site if you like pounding the refresh button, or keep accessing the API with invalid information, though that doesn't affect mining.
The IP you sent me doesn't show up anywhere.
You'd need to PM me a username (or tell me in discord)
There are no 'whitelisted' IP addresses on the pool at all.

[o_solo_miner]

Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalk.org/index.php?topic=5355470.msg58276516#msg58276516

I'll look into solo working with 0.21 when I get to doing that - give it a little while Smiley
But no, it's far from ideal to use a version of bitcoin prior to 0.21, since when taproot activates next month, you must be running 0.21 or later.

Using a non taproot activated bitcoind (even with the fix in cgminer from golden-guy) will not produce a valid block.
Using a taproot activated bitcoind will also not produce a valid block due to the lack of taproot support in cgminer.

[Sledge0001]

Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalk.org/index.php?topic=5355470.msg58276516#msg58276516

I'll look into solo working with 0.21 when I get to doing that - give it a little while Smiley
But no, it's far from ideal to use a version of bitcoin prior to 0.21, since when taproot activates next month, you must be running 0.21 or later.

Using a non taproot activated bitcoind (even with the fix in cgminer from golden-guy) will not produce a valid block.
Using a taproot activated bitcoind will also not produce a valid block due to the lack of taproot support in cgminer.

That's the info that I needed to hear!

I have moved my miners back to Kano's solo pool.

Thank you.

[100knot2dae]

Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalk.org/index.php?topic=5355470.msg58276516#msg58276516

I'll look into solo working with 0.21 when I get to doing that - give it a little while Smiley
But no, it's far from ideal to use a version of bitcoin prior to 0.21, since when taproot activates next month, you must be running 0.21 or later.

Using a non taproot activated bitcoind (even with the fix in cgminer from golden-guy) will not produce a valid block.
Using a taproot activated bitcoind will also not produce a valid block due to the lack of taproot support in cgminer.

That's the info that I needed to hear!

I have moved my miners back to Kano's solo pool.

Thank you.

That info is just plain wrong though... Solo mining on bitcoind 22.0 with cgminer indeed produces valid blocks. I have just mined 2 blocks on testnet3 (which has taproot enabled) : https://www.blockchain.com/btc-testnet/address/miFe5wH65oHbLsp8hXzahyPe4aqtwcCMaK

[o_solo_miner]

Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalk.org/index.php?topic=5355470.msg58276516#msg58276516

I'll look into solo working with 0.21 when I get to doing that - give it a little while Smiley
But no, it's far from ideal to use a version of bitcoin prior to 0.21, since when taproot activates next month, you must be running 0.21 or later.

Using a non taproot activated bitcoind (even with the fix in cgminer from golden-guy) will not produce a valid block.
Using a taproot activated bitcoind will also not produce a valid block due to the lack of taproot support in cgminer.

That's the info that I needed to hear!
I have moved my miners back to Kano's solo pool.
Thank you.

That info is just plain wrong though... Solo mining on bitcoind 22.0 with cgminer indeed produces valid blocks. I have just mined 2 blocks on testnet3 (which has taproot enabled) : https://www.blockchain.com/btc-testnet/address/miFe5wH65oHbLsp8hXzahyPe4aqtwcCMaK

ok, thanks for the info.

Did you modify cgminer any further then adding golden-guys comit?
I now sync the testnet and try it, just to confirm it.

I was thinking that taproot has to be implemented as segwit was.
My concern was, that the version bits have to be valid for taproot.

[100knot2dae]

ok, thanks for the info.

Did you modify cgminer any further then adding golden-guys comit?
I now sync the testnet and try it, just to confirm it.

I was thinking that taproot has to be implemented as segwit was.
My concern was, that the version bits have to be valid for taproot.

I just updated cgminer 4.11.1 with the golden-guy patches, fired up bitcoind 22 and synced testnet3. So even without any change on the version bit (in regards to signalling taproot support) the solo-mined blocks are accepted and confirmed on the blockchain just fine. I have yet to find any implication on the mining software that might have been introduced by the taproot changes.

EDIT: According to the getblocktemplate response as returned by bitcoind 22, the client (i.e. cgminer) may just disregard the "taproot" rule and can continue using the existing blocktemplate as-is. Which basically means as long as there are non-taproot transactions added to the mempool, it will just continue to create valid blocks. As can be seen and verified on testnet.

[NotFuzzyWarm]

Perhaps if you read about what Taproot is and does you'll understand the implications. AFAIK non-taproot blocks will be rejected by the majority of nodes as they have all updated to the latest version of Core that triggered it.

[100knot2dae]

Did you read it? That's what I got from my readings:
There is no such thing like a taproot block, since taproot is applied on transaction level. Legacy and segwit transactions will always continue to be supported - only a hard fork could change that. And as such, a miner that is mining these legacy and segwit transactions - like cgminer in its current state - will continue to be supported. At least up until the very day when everybody has switched to taproot, leaving only taproot transactions in the mempool.

I might be utterly wrong here, so please tell me. But I want proof then

[jack1cryptotalk007]

getblocktemplate and submitblock cmd in bitcoin core seem not affected by taproot stuff. bitcoin core code has no modified.


I wonder if cgminer can work without using midstate in its work->data  with BM1387 or 1389
driver.gekko.c use midstate in init_task(). Has anybody tried before?

If don't use midstate, what is the cmd sent to usb?  now, it is 0x21.  (info->task[0] = 0x21)

In gbt_solo mode, it is better not use midstate. There is a problem in data flip or big endian order byte issue.
It seem different using midstate to meet data from bitcoin core.