Author

Topic: SoloMining with CGMiner against Bitcoind / Bitcoin Core v0.18.1 (Read 2565 times)

legendary
Activity: 2898
Merit: 1041
Thank you. I'll try to do this in Linux.
hero member
Activity: 630
Merit: 731
Bitcoin g33k
Quote
My own favorite is github.com/phaenomenon/cgminer, which is quite up-to-date (version 4.12.1)...

There is a ready-made assembly for Windows?

I don't think so. As far as I see this is *nix only so Windows won't be an option. However feel free to check out and read the documentation which is quite detailed and will potentially answer all of your questions. Good luck and happy mining!
legendary
Activity: 2898
Merit: 1041
Quote
My own favorite is github.com/phaenomenon/cgminer, which is quite up-to-date (version 4.12.1)...

There is a ready-made assembly for Windows?
hero member
Activity: 630
Merit: 731
Bitcoin g33k
what patch do you guys recommend for solo mining on bitcoind?

See here:
https://bitcointalksearch.org/topic/m.61461437

So that you don't do anything wrong when enabling the solo mining functionality and risk misconfiguration, I would highly recommend you to use ready-made cgminer versions that already contain this patch. There are several Github repositories. My own favorite is github.com/phaenomenon/cgminer, which is quite up-to-date (version 4.12.1) and includes many other useful things besides the actual Golden Guy patch. For example, it automatically checks the given payout address for correctness, only then the mining process starts at all. If you accidentally entered a Bech32 for solo mining, cgminer warns you at startup and aborts with an error message so you can correct it. Also, you can mine not only in mainnet but also in testnet. In testnet you need to provide a legacy address that starts with "m" or "n" and this is also handled by the input validation. The README contains useful information under "SOLO mining" and there are also very cool start scripts included, so you can get started right away.

I also highly recommend reading those two How-To's from nullama which explains how to mine on testnet using a GekkoScience Compac-F USB miner or even with a GPU/CPU:
[Guide] Solo mine testnet bitcoins with cgminer, Bitcoin Core, and a Compac F
[Guide] Solo mine testnet bitcoins with bfgminer, Bitcoin Core, and a CPU/GPU
newbie
Activity: 4
Merit: 0
what patch do you guys recommend for solo mining on bitcoind?
legendary
Activity: 2898
Merit: 1041
Hello. Can't start solo mining Bitcoin :-(
My configuration: computer with Windows 7, full node Bitcoin Core 0.18.1, cgminer 4.12.   USB Miner BitForce Jalapeno 7.5 GH/s

bitcoin.conf:
listen=1
daemon=1
server=1
rpcuser=xxxxxx
rpcpassword=xxxxxxxx
rpcallowip=127.0.0.1
rpcport=3333

cgminer command:

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

newbie
Activity: 1
Merit: 0
Your setup looks quite good.  Cool 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! Smiley
jr. member
Activity: 50
Merit: 11
Thank you.
This one compiled with no issues... Smiley
member
Activity: 100
Merit: 29
This is the sequence I used:
git clone https://github.com/kanoi/cgminer
cd cgminer
./autogen.sh
CFLAGS="-O2 -Wall -march=native -fcommon" ./configure --enable-ants3
make
That's an ancient build target, and not actively supported anymore. Try an older version that should build fine, e.g. https://github.com/vthoang/cgminer
jr. member
Activity: 50
Merit: 11
This is the sequence I used:
git clone https://github.com/kanoi/cgminer
cd cgminer
./autogen.sh
CFLAGS="-O2 -Wall -march=native -fcommon" ./configure --enable-ants3
make
member
Activity: 100
Merit: 29
Hi all,

I cannot install the cgminer on my Ubuntu 20.04.5 LTS. I keep on getting this error message:

make[2]: *** [Makefile:999: cgminer-cgminer.o] Error 1
make[2]: Leaving directory '/home/user/bitcoin_testnet/cgminer'
make[1]: *** [Makefile:1894: all-recursive] Error 1
make[1]: Leaving directory '/home/user/bitcoin_testnet/cgminer'
make: *** [Makefile:808: all] Error 2

I have installed and updated all the libraries and tried to do the whole process over and over but I get the same end result.

Any thoughts on this issue?


Some more log lines would be helpful, but I assume it's the issue with GCC 10+ which needs the CFLAGS=-fcommon to compile the cgminer code.
jr. member
Activity: 50
Merit: 11
Hi all,

I cannot install the cgminer on my Ubuntu 20.04.5 LTS. I keep on getting this error message:

make[2]: *** [Makefile:999: cgminer-cgminer.o] Error 1
make[2]: Leaving directory '/home/user/bitcoin_testnet/cgminer'
make[1]: *** [Makefile:1894: all-recursive] Error 1
make[1]: Leaving directory '/home/user/bitcoin_testnet/cgminer'
make: *** [Makefile:808: all] Error 2

I have installed and updated all the libraries and tried to do the whole process over and over but I get the same end result.

Any thoughts on this issue?

hero member
Activity: 630
Merit: 731
Bitcoin g33k
And for this you have created a new forum account? Well then, congratulations on your virgin post  Grin
newbie
Activity: 1
Merit: 0
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.
hero member
Activity: 630
Merit: 731
Bitcoin g33k
I don't know what kind of content you are ingesting, but you have a whole different set of problems.

You let the questioner run into the dark just like all other readers who stumble upon this thread. You knew at all times the cause and effect and are aware that this could be fatal for one if he would not use a bitcoin address with prefix 1. In spite of everything, you kept it quiet willfully in order to portray yourself as a "hero" afterwards. This becomes clear through such reactions:

Quoted for posterity, coz that's a pretty specific statement you make there.
You should get yourself checked out and take professional medical and psychological help, that's some well meaning advice.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
I said it quite clearly, learn english.

Be aware that the patch mentioned above will not send the coins to your address but a random address under certain circumstances.
Most people don't like thoroughly testing patches, so yeah too bad about that hey.

You have enabled other code that wont always work.

Rather simple and obvious actually for a programmer.

All this ranting about me coz he came to my pool, solo mined using MRR, MRR used some miners that are blocked by my pool, and then MRR kept some of his BTC coz some were blocked.

So what this is all about is Renegade seems to think that I don't have the right to block miners on my pool that have always violated MY cgminer license.

Oh well. Glad you left. Pity you stalk the discord channel under another name.

I posted that info in discord 15/12/2022 01:33 UTC
You then posted your post
Quote from: citb0in on December 18, 2022, 12:50:37 PM
hero member
Activity: 630
Merit: 731
Bitcoin g33k
You have enabled other code that wont always work.
Rather simple and obvious actually for a programmer.

Be aware that the patch mentioned above will not send the coins to your address but a random address under certain circumstances.
Most people don't like thoroughly testing patches, so yeah too bad about that hey.

you said that after applying this patch cgminer will not send the coins to your address but a
random address under certain circumstances.What code does the patch enable?
can you please be more specific with your reply?

No, coz in your case you are advertising code for free to people claiming it will work, without testing it properly,
with clearly no understanding of what you are doing, and people are silly enough to listen to you and some of them, if they find  a block, will not get the reward.

Yeah this place is full of hackers that think they know what they are doing but wont be found when the shit hits the fan.

If you were to actually test it properly you would 'likely' spot the obvious issue.

who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Hiding important information when it could knowingly lead to a fatal outcome for others is simply shameful for Kano.

[...]
You are of course welcome to apply the golden-guy patch. As it was already suggested to you, you could clone the current cgminer version from Kanos' github repository and then apply the golden-guy patch. As mentioned here in the thread, there are also numerous other github repositories that include this patch, which unlocks solo mining functionality. What you should pay attention to when you manually apply the golden-guy patch --> you must NOT specify a bech32 address (begins with bc1q...) as payout address but you should exclusively use a legacy P2PKH address (begins with 1...). If you would use a bech32 as payout address (eg. bc1qxyz123abc...) then cgminer would seem to run without any problems at first sight, but if you should really hit a block, then the coinbase transaction would be erroneous and the reward would not be transferred to your specified bc1q.... (Bech32) address but to a random bitcoin address. Your reward would be lost, that would be fatal and nobody wants that. This is what Kano means with his incomplete statement and although he knows the risk, he resists to post this information here publicly, so that he can claim himself as a prophet afterwards full of glee (by actions like that). Such behavior is anything but exemplary.
[...]

Meanwhile, as most now know, coz I pointed out why in discord weeks ago, and that info has spread, indeed 100knot2dae was telling people to use a patch that would fail if any address you used didn't start with 1.
All new wallets by default do not use 1 address.

After the explanation for all understandably was revealed Kano tries in vain with such clumsy apology attempts to get up. Kano has once again successfully demonstrated his rotten and abysmal character. Congratulations.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.
Quoted for posterity, coz that's a pretty specific statement you make there.
Meanwhile, as most now know, coz I pointed out why in discord weeks ago, and that info has spread, indeed 100knot2dae was telling people to use a patch that would fail if any address you used didn't start with 1.
All new wallets by default do not use 1 address.
Let it be Kano...
https://bitcointalksearch.org/topic/m.58531767
https://bitcointalksearch.org/topic/m.61436321
Yet you posted here about it and didn't point out that problem anywhere here before I pointed out the random address issue ...
You even then followed up as can be seen above "And I have tested this with lots of different addresses by now." <- which will fail with most address.
Then you didn't even bother replying with the issue but instead post shit about me - lol.
Yeah fine you mentioned it once last year, but then go around telling people here it's OK to use it without pointing out that for most of them it will fail.
You had your chance to shine on this topic for a long time, but decided against. That was your decision.

However, by now everybody who had serious interest in the solo mining topic was aware of this fact. It is with reason that e.g. the golden-guy version of cgminer has added a bitcoin address check (https://github.com/golden-guy/cgminer/commit/90d03dd12f4b7d800eb9976356875c9c003aac2e for P2PKH addresses when solo mining.

Nothing else to say here. So please stop this senseless discussion, at least I will now.
The patch you and others quoted to use
https://bitcointalksearch.org/topic/m.61184493
does NOT include that fix and you didn't point out the 1 address requirement.
That post says to use this patch:
https://github.com/golden-guy/cgminer/commit/168a1bdfedb1408a690f5387e04e3c9af7842c5e.patch
That was the reason for my post after those posts.
You fucked up and I pointed out it would generate a random address payment.
Seriously, get your facts straight.

As I said:
Be aware that the patch mentioned above will not send the coins to your address but a random address under certain circumstances.
Most people don't like thoroughly testing patches, so yeah too bad about that hey.
member
Activity: 100
Merit: 29
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.
Quoted for posterity, coz that's a pretty specific statement you make there.
Meanwhile, as most now know, coz I pointed out why in discord weeks ago, and that info has spread, indeed 100knot2dae was telling people to use a patch that would fail if any address you used didn't start with 1.
All new wallets by default do not use 1 address.
Let it be Kano...
https://bitcointalksearch.org/topic/m.58531767
https://bitcointalksearch.org/topic/m.61436321
Yet you posted here about it and didn't point out that problem anywhere here before I pointed out the random address issue ...
You even then followed up as can be seen above "And I have tested this with lots of different addresses by now." <- which will fail with most address.
Then you didn't even bother replying with the issue but instead post shit about me - lol.
Yeah fine you mentioned it once last year, but then go around telling people here it's OK to use it without pointing out that for most of them it will fail.
You had your chance to shine on this topic for a long time, but decided against. That was your decision.

However, by now everybody who had serious interest in the solo mining topic was aware of this fact. It is with reason that e.g. the golden-guy version of cgminer has added a bitcoin address check (https://github.com/golden-guy/cgminer/commit/90d03dd12f4b7d800eb9976356875c9c003aac2e for P2PKH addresses when solo mining.

Nothing else to say here. So please stop this senseless discussion, at least I will now.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.
Quoted for posterity, coz that's a pretty specific statement you make there.
Meanwhile, as most now know, coz I pointed out why in discord weeks ago, and that info has spread, indeed 100knot2dae was telling people to use a patch that would fail if any address you used didn't start with 1.
All new wallets by default do not use 1 address.
Let it be Kano...
https://bitcointalksearch.org/topic/m.58531767
https://bitcointalksearch.org/topic/m.61436321
Yet you posted here about it and didn't point out that problem anywhere here before I pointed out the random address issue ...
You even then followed up as can be seen above "And I have tested this with lots of different addresses by now." <- which will fail with most address.
Then you didn't even bother replying with the issue but instead post shit about me - lol.
Yeah fine you mentioned it once last year, but then go around telling people here it's OK to use it without pointing out that for most of them it will fail.
member
Activity: 100
Merit: 29
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.
Quoted for posterity, coz that's a pretty specific statement you make there.
Meanwhile, as most now know, coz I pointed out why in discord weeks ago, and that info has spread, indeed 100knot2dae was telling people to use a patch that would fail if any address you used didn't start with 1.
All new wallets by default do not use 1 address.
Let it be Kano...
https://bitcointalksearch.org/topic/m.58531767
https://bitcointalksearch.org/topic/m.61436321
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.
Quoted for posterity, coz that's a pretty specific statement you make there.
Meanwhile, as most now know, coz I pointed out why in discord weeks ago, and that info has spread, indeed 100knot2dae was telling people to use a patch that would fail if any address you used didn't start with 1.
All new wallets by default do not use 1 address.
newbie
Activity: 72
Merit: 0
hero member
Activity: 630
Merit: 731
Bitcoin g33k
seems like bech32 was only implemented in the CKpool but not included in cgminer for other reasons then.

What it is important to note --> bech32 is not supported by cgminer for solo mining and to read the previous important information and suggested solution to enable solo mining funtionality in cgminer. That is was the topic here is about.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Well, wrong, look here:
I think it should be native segwit (bech32), I corrected it

Seriously shitc0in - facts please.
You make up shit all the time.

Git commit to add bc1 addresses to ckpool code February 2018

Con Kolivas committed 61513a7
2018-02-06
Implement native bech32 segwit address support.
https://bitbucket.org/ckolivas/ckpool/commits/61513a765b12947fae30535179194b1672dc82b5

His last commit into cgminer December 2018

https://github.com/ckolivas/cgminer/commits/master
Commits on Dec 6, 2018
    Merge pull request #734 from Johnson-Fan/master
   @ckolivas ckolivas committed on Dec 7, 2018
hero member
Activity: 630
Merit: 731
Bitcoin g33k
Well, wrong, look here:
I think it should be native segwit (bech32), I corrected it
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
@citb0in yes we all know how much you love me.
but please stop stalking my discord channel,
when you openly say you wont mine on my pool Smiley
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
Segwit didn't exist when CK implemented solo mining in cgminer those times and as explained before cgminer was put in archive mode by CK.

Well, wrong, look here:

https://bitcointalksearch.org/topic/m.17594456
Quote
23 January 2017, 13:34:48
   
New release: Version 4.10.0 - 23rd January 2017
http://ck.kolivas.org/apps/cgminer/
Lots of driver updates and numerous accumulated fixes and improvements.

Human readable changelog:
The very short version:
Avalon 4/5/6/7 support
Compac gekko support
Solo mining segwit support
Updated build to use system libusb
Updated build to latest jansson library
Lots of low level fixes and reliability improvements
Pool failover handling improvements
Diff handling improvements
Extra block change information
Other configuration options
See full changelog for unlisted items.

member
Activity: 100
Merit: 29
A very good wrap-up, it's good to see people here keeping up the solo mining spirit. Note that the aspect on running a performant node in a data center cannot be emphasized enough, if you want to stand a realistic chance to get your block pushed out to the network fast enough.
hero member
Activity: 630
Merit: 731
Bitcoin g33k
Hello yoshitmitsu,

you can solo mine on your own full node (bitcoind) without hesitation. Don't be put off by Kano's statements. He is constantly bashing other pool operators because he sees everyone as a rival. As you note, he also doesn't even address your questions that you understandably asked, instead he also attacks you for supposedly promoting the patch that unlocks solo functionality. He doesn't like that thousands of solo-mining enthusiasts out there could mine on their own full-node because that would mean even fewer participants on his pool. As you may know cgminer was developed by Con Kolivas (-Ck) and Kano had participated there as a developer. Kano especially developed the driver parts. CK kicked Kano out many years ago and banned him from development because of personal disputes between the two. Since then, Kano has been constantly ranting on CK and everything that has to do with him. However, this bashing does not exist the other way around. CK stopped the development of cgminer a long time ago and made it public. Kano has been managing cgminer on his own since then and has his own fork at github.com/kanoi/cgminer. There he maintains e.g. the latest drivers, especially those from Gekkoscience. He sees himself as a god, everyone else is a loser in his opinion.

About your questions and your intention. You are of course welcome to apply the golden-guy patch. As it was already suggested to you, you could clone the current cgminer version from Kanos' github repository and then apply the golden-guy patch. As mentioned here in the thread, there are also numerous other github repositories that include this patch, which unlocks solo mining functionality. What you should pay attention to when you manually apply the golden-guy patch --> you must NOT specify a bech32 address (begins with bc1q...) as payout address but you should exclusively use a legacy P2PKH address (begins with 1...). If you would use a bech32 as payout address (eg. bc1qxyz123abc...) then cgminer would seem to run without any problems at first sight, but if you should really hit a block, then the coinbase transaction would be erroneous and the reward would not be transferred to your specified bc1q.... (Bech32) address but to a random bitcoin address. Your reward would be lost, that would be fatal and nobody wants that. This is what Kano means with his incomplete statement and although he knows the risk, he resists to post this information here publicly, so that he can claim himself as a prophet afterwards full of glee (by actions like that). Such behavior is anything but exemplary.

Bech32 didn't exist when CK implemented solo mining in cgminer those times and as explained before cgminer was put in archive mode by CK. Kano still deliberately avoids unlocking solo functionality in his current versions, and he tries to justify this in the sense that it would be foolish to mine on a dedicated full-node. Of course, it should be clear to everyone that a full node and mining on such a full node requires certain minimum requirements and how important performance is in the context of the mining process. A possibly found valid block must finally find its way into the blockchain in the shortest and fastest way and reach many nodes at ultra-fast speed, otherwise one runs the risk of stale shares and orphan blocks. Not only a high-performance full node is important, but also the speed to the Internet plays a role, as well as the routers and hops in between. At best, everything runs in a data center with high-quality devices and top performance with an extremely fast Internet connection. Keep in mind the sheer amount of data (some TBs per month) just for the GBT traffic so running this at a data center makes only sense if your miner is located on-site, too. This information could all be mentioned, explained and ultimately left to the user's free decision to solo-mine on a full-node.

So that you don't do anything wrong when enabling the solo mining functionality and risk misconfiguration, I would highly recommend you to use ready-made cgminer versions that already contain this patch. There are several Github repositories. My own favorite is github.com/phaenomenon/cgminer, which is quite up-to-date (version 4.12.1) and includes many other useful things besides the actual Golden Guy patch. For example, it automatically checks the given payout address for correctness, only then the mining process starts at all. If you accidentally entered a Bech32 for solo mining, cgminer warns you at startup and aborts with an error message so you can correct it. Also, you can mine not only in mainnet but also in testnet. In testnet you need to provide a legacy address that starts with "m" or "n" and this is also handled by the input validation. The README contains useful information under "SOLO mining" and there are also very cool start scripts included, so you can get started right away.

I also highly recommend reading those two How-To's from nullama which explains how to mine on testnet using a GekkoScience Compac-F USB miner or even with a GPU/CPU:
[Guide] Solo mine testnet bitcoins with cgminer, Bitcoin Core, and a Compac F
[Guide] Solo mine testnet bitcoins with bfgminer, Bitcoin Core, and a CPU/GPU

In case you use a GekkoScience Compac F, the installation process is as follows.

Code:
# clone the repository
git clone https://github.com/phaenomenon/cgminer

# rename it to a meaningful name so you can distinguish it in case you want to try other cgminer versions, too.
mv cgminer cgminer_phaenomenon

# enter directory
cd cgminer_phaenomenon

# compile it
CFLAGS="-O2 -march=native -fcommon" ./autogen.sh --enable-gekko
make

# look at the provided three start scripts *.sh and *.conf files and adjust to suit your needs, here I choose testnet for the initial test
vi start_solomining_ownFullNode_testnet.sh

# ensure your bitcoind is running testnet and then launch cgminer
./start_solomining_ownFullNode_testnet.sh

Logs are written to the subfolder "logs\" which I find very convenient. After you have successfully mined your first block on testnet and received succesful your block reward, you could switch to mainnet.

Hope this guide is helpful for everyone. Good luck and happy solo-mining

citb0in
member
Activity: 100
Merit: 29
i'd like to mine with r909 gekkoscience compac f asic miner chip without any pool in between just cgminer and bitcoind in its latest versions

https://github.com/golden-guy/cgminer is 12 commits ahead of vthoang:master

golden-guy cgminer version is not up-to-date cgminer and I think it does not support gekkoscience compac f chip.Can I just install latest version https://github.com/kanoi/cgminer and then manually apply those 12 commits of golden-guy?
what is the best way to do this?

For solo mining you basically only need that single patch, so just clone the git and apply the patch. And be sure to use a 1xxxx address (p2pkh).
newbie
Activity: 72
Merit: 0
i'd like to mine with r909 gekkoscience compac f asic miner chip without any pool in between just cgminer and bitcoind in its latest versions

https://github.com/golden-guy/cgminer is 12 commits ahead of vthoang:master

golden-guy cgminer version is not up-to-date cgminer and I think it does not support gekkoscience compac f chip.Can I just install latest version https://github.com/kanoi/cgminer and then manually apply those 12 commits of golden-guy?
what is the best way to do this?
member
Activity: 100
Merit: 29
IMHO there is no downloadable "plug and play" pool software for the novice miner which is a shame... I'm working on correcting that.

Indeed. But seems like you can build your own ckpool solo instance as docker image now, using this repo: https://github.com/golden-guy/docker-ckpool
It's looks really simple, just install Docker and use the Dockerfile to build the image.

EDIT: Always use at your own risk.
full member
Activity: 626
Merit: 159
I am currently solo mining but through my own pool at the moment.
i like to try that too
do you use cgminer and could you please give me instruction how to mine on own fullnode?

which version do you use and which patch or patches do you have in use, how to install them?

I'm using bitcoincore v23.0 and connecting it through a heavily modified version of a few open source pool projects.

This is not a task for a novice as there are millions of lines of code to go through but start looking at ckpools open source, p2pool code, Yiimp as well as Nomp.

Somewhere in between them all lies the right bits and pieces to put a functioning pool together but I must admit deciphering the the voluminous files figuring out which to use and what to discard is a time consuming venture.

IMHO there is no downloadable "plug and play" pool software for the novice miner which is a shame... I'm working on correcting that.

If you just have few smaller miners and are using cgminer then use Golden-Guys cgminer which does seem to be mostly based off of Kano's version of cgminer.  Although I haven't had time to fully examine every bit of that code.



newbie
Activity: 72
Merit: 0
I am currently solo mining but through my own pool at the moment.
i like to try that too
do you use cgminer and could you please give me instruction how to mine on own fullnode?

which version do you use and which patch or patches do you have in use,how to install them?
full member
Activity: 626
Merit: 159
sledge which pool did you use when you hit the block? do you solo mine against bitcoind at all?

what patch do you guys recommend for solo mining on bitcoind?

When I hit I was mining on CK's Pool.

I am currently solo mining but through my own pool at the moment.
newbie
Activity: 72
Merit: 0
sledge which pool did you use when you hit the block? do you solo mine against bitcoind at all?

what patch do you guys recommend for solo mining on bitcoind?
full member
Activity: 626
Merit: 159
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.

I would prefer that this not be the thread that anyone start throwing shade at any user or contributor on this forum regardless of your personal opinions.

The testnet and mainnet are two different beasts. Difficulty of 1 vs. 34T at the moment being one "big" difference Smiley

I will never forget that I would have never hit a block if it hadn't been for Kano's cgminer code, Ck's solo pool and Sidehacks hardware....

Each person should embrace and take their own BTC journey but let's not discount the experience, efforts and contributions made over several years of the people listed above.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.
Quoted for posterity, coz that's a pretty specific statement you make there.
member
Activity: 100
Merit: 29
who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?

Just ignore it. Up to now he has never come up with his own approach - and he probably never will - but rather spends his time on telling other people's work off. That's the real tragedy here.

All I can say is that FOR ME, this golden-guy patch has proven to find blocks countless times on BTC testnet and other forks when solo mining on an own node. And I have tested this with lots of different addresses by now.

But this is no promo, no recommendation and you always do things at your own risk.
newbie
Activity: 72
Merit: 0
No, coz in your case you are advertising code for free to people claiming it will work, without testing it properly,
with clearly no understanding of what you are doing, and people are silly enough to listen to you and some of them, if they find  a block, will not get the reward.

Yeah this place is full of hackers that think they know what they are doing but wont be found when the shit hits the fan.

If you were to actually test it properly you would 'likely' spot the obvious issue.

who do you mean?i did not advertise code for free.i had quoted the patch to ask if you had referred to it in your previous reply because it was not clear.

still unanswered is your statement that this patch sends coins to a foreign address. I'd love to understand, but you don't seem to want to answer.

does anyone else know what kano means and what it has to do with this patch?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
No, coz in your case you are advertising code for free to people claiming it will work, without testing it properly,
with clearly no understanding of what you are doing, and people are silly enough to listen to you and some of them, if they find  a block, will not get the reward.

Yeah this place is full of hackers that think they know what they are doing but wont be found when the shit hits the fan.

If you were to actually test it properly you would 'likely' spot the obvious issue.
newbie
Activity: 72
Merit: 0
You have enabled other code that wont always work.

Rather simple and obvious actually for a programmer.

you said that after applying this patch cgminer will not send the coins to your address but a
random address under certain circumstances.What code does the patch enable?
can you please be more specific with your reply?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
You have enabled other code that wont always work.

Rather simple and obvious actually for a programmer.
newbie
Activity: 72
Merit: 0
Be aware that the patch mentioned above will not send the coins to your address but a random address under certain circumstances.
Most people don't like thoroughly testing patches, so yeah too bad about that hey.

do you mean this patch?

Code:
From 168a1bdfedb1408a690f5387e04e3c9af7842c5e Mon Sep 17 00:00:00 2001
From: Stefan Berger
Date: Sun, 28 Feb 2021 10:51:53 +0000
Subject: [PATCH] Make coinbaseaux flags optional

Needed for solo mining on bitcoind, starting with v0.20.0
It's probably safe to delete the coinbase flags, but leave them in as optional for now.

See also: https://github.com/bitcoin/bitcoin/commit/9aedabe67eedfee9c94c6a50962f11348eb99bca
---
 cgminer.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/cgminer.c b/cgminer.c
index ece7ce100f..ab52e30a61 100644
--- a/cgminer.c
+++ b/cgminer.c
@@ -2960,7 +2960,7 @@ static bool gbt_solo_decode(struct pool *pool, json_t *res_val)
  flags = json_string_value(json_object_get(coinbase_aux, "flags"));
  default_witness_commitment = json_string_value(json_object_get(res_val, "default_witness_commitment"));
 
- if (!previousblockhash || !target || !version || !curtime || !bits || !coinbase_aux || !flags) {
+ if (!previousblockhash || !target || !version || !curtime || !bits) {
  applog(LOG_ERR, "Pool %d JSON failed to decode GBT", pool->pool_no);
  return false;
  }
@@ -3039,10 +3039,12 @@ static bool gbt_solo_decode(struct pool *pool, json_t *res_val)
  ofs += ser_number(pool->scriptsig_base + ofs, height); // max 5
 
  /* Followed by flags */
- len = strlen(flags) / 2;
- pool->scriptsig_base[ofs++] = len;
- hex2bin(pool->scriptsig_base + ofs, flags, len);
- ofs += len;
+ if (flags) {
+ len = strlen(flags) / 2;
+ pool->scriptsig_base[ofs++] = len;
+ hex2bin(pool->scriptsig_base + ofs, flags, len);
+ ofs += len;
+ }
 
  /* Followed by timestamp */
  cgtime(&now);

I cannot find a random number generator in that code or any references to bitcoin addresses so what exactly do you mean?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Be aware that the patch mentioned above will not send the coins to your address but a random address under certain circumstances.
Most people don't like thoroughly testing patches, so yeah too bad about that hey.
newbie
Activity: 72
Merit: 0
which cgminer version is required to mine on a full node?could someone give me a download link please
hero member
Activity: 630
Merit: 731
Bitcoin g33k
good idea, but I would advise against solo mining on a hosted node due to the sheer amount of data (some TBs per month) just for the GBT traffic.
could you please explain this a little more, please? I understand that due to GBT a bunch of data is transferred between fullnode and miner every second. As far as miner+fullnode work on one and the same host, which is very powerful and therefore performant, does direct mining on bitcoin core really have a disadvantage compared to mining by intermediary pool ? Or maybe there are even advantages? I tried this setup on testnet and it works fine so far.

I started to play around with mining on a hosted node last week, somewhat inspired by all these solo pools that have popped up recently. A far better option is to install a ckpool instance on the same machine and connect there via stratum. I did such a setup and it works fine. And that way, you don't even need to patch cgminer and it works for stratum-only devices like the Futurebit Apollo as well. If there is interest, I could post a setup guide too.
Would be awesome to see a setup and operation guide, I guess it would be interesting for the whole community. Thank you in advance.

See the steps for patching cgminer below:


EDIT: You could also use this modded cgminer: https://github.com/cmmodtools/cgminer There are a few patched versions around that should work equally well.

many thanks for the instructions. I tried patching Kano's latest cgminer version with the goldenguy patch and it worked fine, I was able to successful mine on bitcoin core with GBT using. Can you explain please what kind of additional mods the mentioned cmmodtools/cgminer has in comparison to Kano latest cgminer version? And which other patched or modded versions of cgminer are available out there that you can suggest and for what reason? What kind of mods/patches have they included and what are they good for (some examples) ? Thanks for your very helpful and kind reply.
member
Activity: 100
Merit: 29

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.

Hi 100knot2dae and rest,

would you mind sharing a brief step-by-step how-to for getting the patched cgminer version to run on with an own full-node which is running bitcoin core v23.0.0. I have a full-node running in a data center with superior superfast internet connection and would like to use it for solo-mining with a GekkoScience Compac F. Unfortunately Kanos' latest version 4.12 does prohibit the use for mining on an own full node running latest bitcoin core 23.0.0 version. How to mitigate this? Thanks to all

Hello,
good idea, but I would advise against solo mining on a hosted node due to the sheer amount of data (some TBs per month) just for the GBT traffic. I started to play around with mining on a hosted node last week, somewhat inspired by all these solo pools that have popped up recently. A far better option is to install a ckpool instance on the same machine and connect there via stratum. I did such a setup and it works fine. And that way, you don't even need to patch cgminer and it works for stratum-only devices like the Futurebit Apollo as well. If there is interest, I could post a setup guide too.

See the steps for patching cgminer below:


EDIT: You could also use this modded cgminer: https://github.com/cmmodtools/cgminer There are a few patched versions around that should work equally well.
hero member
Activity: 630
Merit: 731
Bitcoin g33k

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.

Hi 100knot2dae and rest,

would you mind sharing a brief step-by-step how-to for getting the patched cgminer version to run on with an own full-node which is running bitcoin core v23.0.0. I have a full-node running in a data center with superior superfast internet connection and would like to use it for solo-mining with a GekkoScience Compac F. Unfortunately Kanos' latest version 4.12 does prohibit the use for mining on an own full node running latest bitcoin core 23.0.0 version. How to mitigate this? Thanks to all
member
Activity: 144
Merit: 25
Solo mining FTW  Cool

Let's band together and make an effort to code something that could work

This is what bitcoin is all about. This is how it started!
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
There's a chance if you use slow internet, run it through tor, add a vpn on top of that, run your bitcoin through tor and a vpn, then connect to a pool node on the other side of the planet, and restrict your node to hope someone else will send you blocks and get your block you find out to the rest of the world.

The point is you want to make sure you don't make your chances WAY worse by doing such things.

The chance of a miner finding a block is a simple to calculate fixed number - that changes every ~2 weeks - and that chance of course is just a statistic, even a small miner can find a block ... as you know well.

However, reducing the chances of winning that block dramatically by doing such things as I mentioned above is just silly.

If you are lucky enough to have your miner find a block, but then throw it away coz your network setup is no where near as good as the major pools, that would be a really bad thing to do.

If your miner is spending a % of it's time working on stale blocks and also taking a long time to send that one share you might find that is a block to bitcoin, then bitcoin spends a long time processing that block and a long time getting that block out to the network, then you are just possibly throwing away hundreds of thousands of dollars. Yeah a certain other solo pool owner may be able to afford to do that, but do you want to?

The point is that is all unnecessary, you don't need to take those risks and damage your chances of winning a block.
full member
Activity: 626
Merit: 159
But there's a chance!!  Wink

legendary
Activity: 3822
Merit: 2703
Evil beware: We have waffles!
As Kano said, even the big pools lose orphan races. If your connection to the network is even just 2x slower than theirs one has just increased the odds against getting a block before someone else does.

Yes there is a *chance* that if against already incredible odds one *does* find a block when solo mining to their own node, personally I'd be heartbroken to soon after see that another miner with better connections to the BTC network beat me in the race for my block to be the one that is 1st to be confirmed & built upon...
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
Ignorance is bliss.
...
... and I even pointed out the exact reasons further up why it is a bad idea ... sigh.

If someone tells you not to smash your thumb with a mallet coz it will hurt, do you need to try it anyway?

The big pools still lose blocks due to orphan races - just no one reports the losses.
I see some of them coz I have a world wide network that also reports these events.

If you are 10 times slower than the big pools at doing block changes you will get 10 or more times the orphans.
If you are 30 times slower, you will get 30 or more times the orphans and also get stale blocks that no one will ever see.

As for running slow bitcoin and no global fast network connectivity, that 30 number would be minimum, and probably worse.
full member
Activity: 626
Merit: 159
How is it a 'hero' to help fools do something stupid?

Look, even that other pool a lot of you solo mine on has lost around 5 blocks due to negligence and miss-management.
The last guy who lost a block there was ripped off by the guy who runs it - and he has around $100mil in BTC - lol.

Ignorance is bliss.



A hero in my mind usually perform things that many others cannot and help when many others cannot.

You have a specific skillset with coding and as you have read by many on here there is a desire to do this.

Since solo mining on our own is currently is not easily done with CGMiner and Bitcoin Core  and I personally haven't heard of anyone losing a block solo mining on their own... We really don't know if its stupid idea or not.  Reminds me of a great quote "Nothing beats a trial but a failure" from Maya Angelou.

The comment about the "other pool" is even more reason to give everyday folks a shot of doing this on their own.

You kinda indirectly just proved the my point about the need for this.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
How is it a 'hero' to help fools do something stupid?

Look, even that other pool a lot of you solo mine on has lost around 5 blocks due to negligence and miss-management.
The last guy who lost a block there was ripped off by the guy who runs it - and he has around $100mil in BTC - lol.

Ignorance is bliss.

full member
Activity: 626
Merit: 159
Kano,

I have been very successful with my mining endeavors from the altcoin side (ETH,RVN,ZIL) and the BTC side. And yes some of that luck has in fact come from "bad ideas" and "just about impossible" situations as you know.

My offer to send you some BTC was genuine and offered in thanks for your coding efforts on CGMiner as without it I wouldn't have ever been mining BTC directly let alone find a block. Let's call it good karma or at least an attempt at such from my end.

Now back to BTC solo mining efforts. As my BTC mini mining farm grows and it is indeed growing I would still love the ability to be able to solo mine directly to Bitcoin Core. It's not the fact that I don't want to mine to a pool, its more the fact that I like to be in more control of my own environment when mining.

Given that I understand what you are saying about block distribution from what I gather the relatively small amount of data that is transmitted I believe (excuse my ignorance if it in fact is that) that the connections to other nodes are in fact more important than internet speed. I don't think anyone here mines on dial up at this point.  Wink Distribution of said data shouldn't require a significant amount of compute power or network throughput even if sharing that data with 30+ nodes within a very short window.

My suggestion to modify CGMiner to allow for solo mining to Bitcoin Core would benefit the Bitcoin network as a whole.

My logic would be quite simply that adding additional full nodes to the BTC network helps everyone.

The sending of hashpower to your pool (solo or otherwise) even if just for a short duration with some sort of split with the end user would also be an added benefit for the end miner as well. Not to mention would improve the overall hashrate and I believe the health of your pool.

Now as for the transparency part there are many different mining software out there that have fees associated with the use of their software. I am not sure if by doing what I suggest would violate the licensing of CGMiner but if it didn't then implementing this functionality would be a tremendous help to the community.

I can't say I have ever lost a block solo mining but that would be something I and many others would be willing to try.

Make no mistake I respect your opinions and your expertise on blockchain programming but you have the option to be a hero to many here that want to do just as I am trying as well as help yourself (through your pool) in turn as well.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
It has nothing to do with 'pay for effort'
That is the same as the reason why I told you not to give me any BTC when you wanted to.

Instead, it has to do with you losing blocks.

Unless you run all of:
a high speed bitcoin that can average processing network block changes in less than 100ms.
a bitcoin that gets blocks from the whole internet very fast
a bitcoin that can distribute blocks to the whole internet very fast
a method to distribute your blocks around the world to your own distributed nodes very quickly

If you don't do the above, then your chances of losing blocks due to stale or orphan is much higher than a well connected pool that does the above

Suggesting people solo mine at home is, to be blunt, negligent, bad advice.

Some people seem to think that running bitcoin on a rpi is a great idea.
. It is not if you are solo mining.
Some people think that they don't need a fast and well distributed network.
. It is no good if you are solo mining.
Some people think it is ok to CPU mine.
. It is not, it's a complete waste of time.

I added the 3rd one since the three together seem to be common ignorance.

At home my main bitcoin runs on it's own on an i7-10700 with 32GB ram and a 1GBit internet connection.
No chance I would be using it to try to solo mine blocks.
That would be stupid.
I use it for testing and that's as far as I would go with it.
Being a pool developer and the main cgminer developer, that is a necessity.

But it gets worse:
There's the complete misunderstanding about anonymity.
No bitcoin isn't anonymous. If anyone told you that, then they don't understand bitcoin.
Also, you'll need your bitcoin node to be well connected and have a fast connection to the bitcoin network, seeing all the network blocks as fast as possible.
Hiding your bitcoin node behind networks/vpns/tor/etc will definitely increase the chances of you losing a block, if you ever find one.

... and aside: worse, mining to a pool sending your bitcoin address twice every minute is exceptionally far from anonymous.

Yes people are free to do stupid things, but I'm not gonna go out of my way to help them do it, even for BTC.
As said, I'll get around to putting the simple fix in one day, but anyone with the idea that my efforts and compensation are related, has no idea.
full member
Activity: 626
Merit: 159
Due to the many reasons I've explained - I consider this a bad idea.
Many people I discuss anything about bitcoin with seem to not even understand the issues.

Some time when I get around to doing the next gekko driver I'll probably fix the solo code, but helping people lose blocks always sounds like a bad idea to me.

Kano,
I know you are busy I get it but if I had the coding knowledge you have demonstrated I would consider adding a small "10 second" or "30 second" per hour or whatever fee to the CGMiner software and then point that traffic at your solo pool.

Forgive me if that would violate the licensing but....

Come up with some sort of split so that with the miner and your solo pool would be equally or proportionality rewarded (be transparent) if they hit a solo block.

You can do this and I for one would be using it!


People are going to do it anyway. Better they do it in at least a working environment that you wrote.
If not, there is someone out there who will hack it together and kind of sorta get it working and if they don't have anything better to use they will use what they have.

-Dave

Dave,
I suggest he use my logic above to help pay for his efforts.
legendary
Activity: 3500
Merit: 6320
Crypto Swap Exchange
Due to the many reasons I've explained - I consider this a bad idea.
Many people I discuss anything about bitcoin with seem to not even understand the issues.

Some time when I get around to doing the next gekko driver I'll probably fix the solo code, but helping people lose blocks always sounds like a bad idea to me.

People are going to do it anyway. Better they do it in at least a working environment that you wrote.
If not, there is someone out there who will hack it together and kind of sorta get it working and if they don't have anything better to use they will use what they have.

-Dave

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Due to the many reasons I've explained - I consider this a bad idea.
Many people I discuss anything about bitcoin with seem to not even understand the issues.

Some time when I get around to doing the next gekko driver I'll probably fix the solo code, but helping people lose blocks always sounds like a bad idea to me.
full member
Activity: 626
Merit: 159
Hi @Sledge0001 I'm interested in doing something similar using a raspiblitz node (https://github.com/rootzoll/raspiblitz) and an Antminer S9k currently mining with ckpool (https://solo.ckpool.org/), however, everything @kano says makes sense.

Decentralization and trustlessness are wanted in the bitcoin BTC community. Considering that ckpool have the infrastructure with these nodes connected to big pools it is possible to solo-self-miners to connect directly and fast with ckpool to improve the odds? I really want to use my old s9k with the local full node and do the lotto mining but most importantly learn about the experience.

I'm a volunteer if you help me to achieve this, we can try to measure latency between nodes or find a list of the biggest pools and nodes and do nice research for the community. I don't think that I'm the only one interested in achieving this. What do you think?


I am going to dive back into this further as well.

My initial thoughts are simply to keep my larger miners pointed at a pool (4 x S19A Pro's at the moment) but revisit this with my USB miners and also in the mean time try adding a few Futurebit Apollo BTC miners as well.

I believe that given the modest amount of data that is included in every block transaction the speed of most internet services should be fine assuming that the node is well connected to other fast nodes.

I'm game to try this!

@Kano how hard would it be to add the ability to solomine using CGMiner to the newest Bitcoin Core? I for one and I bet others would be willing to donate to that development!
newbie
Activity: 1
Merit: 0
Hi @Sledge0001 I'm interested in doing something similar using a raspiblitz node (https://github.com/rootzoll/raspiblitz) and an Antminer S9k currently mining with ckpool (https://solo.ckpool.org/), however, everything @kano says makes sense.

Decentralization and trustlessness are wanted in the bitcoin BTC community. Considering that ckpool have the infrastructure with these nodes connected to big pools it is possible to solo-self-miners to connect directly and fast with ckpool to improve the odds? I really want to use my old s9k with the local full node and do the lotto mining but most importantly learn about the experience.

I'm a volunteer if you help me to achieve this, we can try to measure latency between nodes or find a list of the biggest pools and nodes and do nice research for the community. I don't think that I'm the only one interested in achieving this. What do you think?
newbie
Activity: 4
Merit: 8
Hi Sledge0001!

My name is Seb and I have a mining channel called Sebs FinTech Channel on YouTube: https://www.youtube.com/c/SebsFinTechChannel

I'm super interested in your story of hitting a block mining on the USB miners.

I recently made a video on setting up the Compac Fs to mine and I have another video planned on how to set them up to mine solo.

I'd love to ask you a few questions about your farm, your experience hitting a block and any advice you might have for people wanting to try something similar.

Please let me know if you'd be open to this. We could do it either here through text, do a voice call or video call, whatever you feel most comfortable with and you can remain as anonymous as you like Smiley

Please send me a DM if you're interested.

Best regards,
Seb
member
Activity: 60
Merit: 20
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 Huh
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.

member
Activity: 100
Merit: 29
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 Smiley
legendary
Activity: 3822
Merit: 2703
Evil beware: We have waffles!
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.
member
Activity: 100
Merit: 29

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.
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalksearch.org/topic/m.58276516
Quote
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. Smiley
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.
member
Activity: 100
Merit: 29
Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalksearch.org/topic/m.58276516
Quote
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. Smiley

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

full member
Activity: 626
Merit: 159
Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalksearch.org/topic/m.58276516
Quote
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. Smiley

Thank you.
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
Solomining with cgminer is not possible yet.

Kano is working on it:
https://bitcointalksearch.org/topic/m.58276516
Quote
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
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.
full member
Activity: 626
Merit: 159
...
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..
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
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.
full member
Activity: 626
Merit: 159
By the end of next week I should have a total of 25 x Compaq F's and 6 x 2Pac Miners chewing away.  Grin

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.



legendary
Activity: 3234
Merit: 1220
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 Cheesy

Otherwise, carry on brother, looks like you are having fun and learning along the way.
full member
Activity: 626
Merit: 159
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!!!  Tongue

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! Smiley
member
Activity: 100
Merit: 29
Your setup looks quite good.  Cool 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! Smiley

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 Smiley

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.
legendary
Activity: 4326
Merit: 8899
'The right to privacy matters'
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.
full member
Activity: 626
Merit: 159
Your setup looks quite good.  Cool 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! Smiley
legendary
Activity: 3234
Merit: 1220
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.
member
Activity: 100
Merit: 29
Your setup looks quite good.  Cool 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
full member
Activity: 626
Merit: 159
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!!!!


Jump to: