 Show Posts
|
|
Pages: [1] 2 »
|
|
Like the title says, when running bfgminer, how do you specify your wallet address properly? I have seen both --generate-to *and* --coinbase-addr in various searches of google by luke-jr, but which is the right one? Specifying either one seems to work. Did something change between versions? How do you specify your wallet address?
Thanks
|
|
|
|
tb@ubuntu:~/bitcoin-0.21.0/bin$ ./bitcoin-cli -netinfo
Bitcoin Core v0.21.0 - 70016/Satoshi:0.21.0/
ipv4 ipv6 onion total block-relay
in 73 0 0 73 9
out 10 0 0 10 2
total 83 0 0 83 11
Local addresses: n/a
What does block-relay mean in this context? |
|
|
|
Does the number of inbound and outbound network connections to your blockchain play any role in who is awarded the block? For example, if a solo miner solves a block and then say 1 second later a large pool solves the same block before all the nodes record the block in the blockchain? Who wins? That's called an Orphan race. Which found block is confirmed first wins. So yes, connections matter but not how exactly many you have but rather how fast of a connection they have to the Bitcoin network so their found block is available to be confirmed. If by "confirmed" you mean another block follows it, then yes. The block that is first to have the next block built on top of it wins. Of course, the earlier block has a head start, but it is not guaranteed because the chain follows the longest branch, and the later branch could get lucky. And, if the next blocks are produced at about the same time, then it is the next block that determines the winning branch. And so on ... I am solo mining with my own blockchain and wallet hosted by me, I have opened the firewall to allow inbound connections, not just outbound, I figured it may be relevant in the off chance of success. |
|
|
|
|
Does the number of inbound and outbound network connections to your blockchain play any role in who is awarded the block? For example, if a solo miner solves a block and then say 1 second later a large pool solves the same block before all the nodes record the block in the blockchain? Who wins?
|
|
|
|
if you mean farmed blocks. where a pool is owned fully by one owner and he has warehouses of asics.. well that can happen
So what have you heard, how many of these people are out there? |
|
|
|
|
I know its a long shot, but I was curious how often a solo miner solves a block? Probably not a topic that would freely come up by the person solving it for anonymous purposes.
I was just doing some quick math and the odds are way up there-
For example, assume there are 170,000,000 TH/s out there right now. If you had 5 newpac usb sticks overclocked to 100GH/s, that would be .5 TH/s. Take the 170m and divide by the .5 and that is 340,000,000 blocks before you theoretically would ever solve one. Divide that by 144 per day and we are talking 2.3 million days or ~6500 years.
Having said that, you have the same odds as anyone else, you could solve a block on the first try, or get 10 in a row, or never.
It is said that the large pools such as slushpool represent about 15% of all bitcoins mined per pool. But how often do you think a solo miner solves a block on their own? Any good stories or discussions on the topic?
|
|
|
|
|
Thanks. Ubuntu I presume?
Any way to prioritize startups of those files? For example, if I want to start bitcoind first, then bfgminer proxy, then cgminer last?
|
|
|
|
|
I am using bfgminer as a proxy only, is there a way to run this as a daemon in the background? Right now I have to have an open console window.
|
|
|
|
|
Here's how I am doing it.
BFGMiner is able to mine against 0.21.0 but CGMiner is not. However, BFGMiner is not compatible with Newpac sticks (not 2pac or compac those work).
So I run bfgminer as a proxy only, then connect my cgminer to bfgminer.
|
|
|
|
|
Try installing libz
On my ubuntu it was sudo apt install libz-dev
|
|
|
|
|
If you solo mine and actually solve a block, does it make sense to have a large amount of inbound connections configured? Or is the only concern outbound connections?
The idea being if you actually solve a block, you need/want to tell the bitcoin blockchain world about it as quickly as possible before another miner solves a block within seconds of you.
For example, how would a large pool handle their inbound and outbound connections? On Bitcoind 0.21.0, if you are nat'd behind a router, you can only initiate connections outbound to the world and I believe on this version the max is 10 outbound. But if you open port 8333 on your router, you will start seeing inbound that exceed 10, so far I am seeing 25.
But which is more important for broadcasting to the world, outbound? Is the only advantage of inbound to run a node for others to sync their blockchain databases?
Thanks
|
|
|
|
Everyone on this post was so helpful I wanted to reach back out and let you know my solution which is subject to change by any other good advice I receive here. I went out and bought a raspberry pi 4 with 8gigs and then bought the Argon One M.2 case that holds a SSD drive. I bought the 1TB drive from Samsung. Its a really neat tiny but powerful setup. Then, I bought myself a Newpac USB miner based on the BM1387 chip. Its running ubuntu. I really had to do a lot of trial and error to get this all to work right. I really like BFGMiner, but it will not work with the new Newpacs. There was some posts about a year ago from @luke-jr about getting it supported but it doesn't have it yet. The great features of BFGMiner from my point of view are the ability to use it as a stratum proxy for other miners as well as its ability to solo mine against the bitcoind higher versions. But it just doesn't support the miner I use. That's where cgminer comes in. Cgminer is the only miner that supports the Newpac based on BM1387. But, cgminer will not work for GBT solo mining against modern versions of bidcoind greater than 0.19. So what I ended up doing is running my bfgminer as a stratum proxy and then run my cgminer with stratum+tcp and point it to the bfgminer. Bingo works! So that's my ugly setup!  I hope luke-jr reads this and decides to spend some time with the newpac drivers. |
|
|
|
Unfortunately 20.04 is only available in the LTS version not the prebuild version which pi requires. Does anyone know if I can run bfgminer on these newpacs? For whatever reason I can compile that.
Well just use the Raspberry OS. It's made for it after all. BFG Miner doesn't support newpacs. They developed their own version of CGMiner to support these. I think I am just missing some package that it requires to compile, but I just don't know which one. The packages that it lists are fairly minimum, as the compiling would error out it would give you a clue to what was missing, for example libz. I am looking for a way to figure out what might be missing but the error message is not descriptive. Is there a way to debug the compile? |
|
|
|
|
EDIT: I compiled on another server running 20.04 and that worked. Thanks.
|
|
|
|
Hello, trying to compile cgminer per the instructions from the GekkoScience docs. It is failing on Make but I can't tell exactly why. First I run sudo git clone https://github.com/vthoang/cgminer.gitThen sudo CFLAGS="-O2 -march=native" ./autogen.sh --enable-gekko Completes ok. Then I run sudo make -j 2 Make ends with the following snippet /usr/bin/ld: cgminer-driver-gekko.o:(.bss+0xff0): multiple definition of `avalonm_drv'; cgminer-cgminer.o:(.bss+0x2ad8): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x10e0): multiple definition of `avalon7_drv'; cgminer-cgminer.o:(.bss+0x29e8): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x11d0): multiple definition of `avalon4_drv'; cgminer-cgminer.o:(.bss+0x28f8): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x12c0): multiple definition of `avalon2_drv'; cgminer-cgminer.o:(.bss+0x2808): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x13b0): multiple definition of `avalon_drv'; cgminer-cgminer.o:(.bss+0x2718): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x14a0): multiple definition of `ants3_drv'; cgminer-cgminer.o:(.bss+0x2628): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x1590): multiple definition of `ants2_drv'; cgminer-cgminer.o:(.bss+0x2538): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x1680): multiple definition of `ants1_drv'; cgminer-cgminer.o:(.bss+0x2448): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x1770): multiple definition of `modminer_drv'; cgminer-cgminer.o:(.bss+0x2358): first defined here
/usr/bin/ld: cgminer-driver-gekko.o:(.bss+0x1860): multiple definition of `bitforce_drv'; cgminer-cgminer.o:(.bss+0x2268): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:891: cgminer] Error 1
make[2]: Leaving directory '/usr/src/cgminer'
make[1]: *** [Makefile:1835: all-recursive] Error 1
make[1]: Leaving directory '/usr/src/cgminer'
make: *** [Makefile:794: all] Error 2
I re-ran the whole thing as root without sudo and same result. Any idea how I can track this down, its not very descriptive. As far as I know all the dependencies that required were installed. Running Ubuntu 20.10 on Raspberry Pi. I have BFGminer installed but for the life of me cannot get it to identify the Newpac so I thought cgminer was the way to go since the equipment maker recommended. |
|
|
|
When you say add it at the end, you mean compile it back in?
Yes. As GBT expects coinbase aux, you can just include it as an empty field again. It'll be easier to ensure minimal downtime as you won't have to waste your time to manage each of your mining instances. Alternatively, remove it from your mining client so it doesn't throw an error. I guess this is where I am confused at, if I want to solo mine against bitcoind, which is the way to go if I don't want to downgrade to 0.19.1? Add it back into the bitcoind code and recompile (not sure exactly how) --or-- remove code from miner client and recompile? Thanks |
|
|
|
Thanks. My linux bitcoind server is almost done syncing, will look into 0.19.1 when it finishes. My question though would be how do mining pools do this?
Most of them probably don't rely completely on Bitcoin Core and builds the block using their own implementation. Most mining pool don't use GBT but stratum instead. Unless you're able to see how the pool functions, you probably won't know if the problem exists for them and what their remedy is. Since the error exists due to the fact that they expect the coinbase flags, they can just add it at the end before feeding it to the miners. When you say add it at the end, you mean compile it back in? |
|
|
|
|
This is all good stuff, thank you everyone!
|
|
|
|
3 newb questions on bitcoin mining.
First, do all bitcoin miners, regardless of what pool they are attached to, mine the same single block?
Nope, each pool is free to include into candidate block any unconfirmed transaction from its mempool. At any time the content of candidate block which miners mine depends on the pool. There is competition between miners attached to different pool in solving cryptographic puzzle for their own candidate blocks. Thank you! You uncovered 3 more questions lol, hope you don't mind The amount in mempool is manually adjustable? 10 minutes later when the next block is mined, are outstanding transactions prohibited from going into the previous block if there is still room? How will transactions be recorded after the last block is mined in 2140? |
|
|
|
|
Thanks everyone.
How many transactions can fit into a single block? How does the miner decide which transactions will go into his mined block, is it automatic like an auction where the highest fees get in first?
|
|
|
|
|
