Also whats the the point in setting difficulty from VARDIFF to your own ?
That sentence makes no sense to me. But variable difficulty has no bearing on solo mining. Pools set a higher difficulty for accepting shares to reduce bandwidth. If a pool set your miner difficultly to 1000 then that means approximately one share out of a thousand will exceed the 1k diff and the pool will pay that share as if it were 1000 diff 1 shares. |
|
|
|
Could some one explain to me what does the best share actually mean when you are solo mining.
That's the best share you have found so far. To find a block at current difficulty you need to meet or exceed 103,880,340,815. |
|
|
|
Afaik you have to restart bitcoind to get rid of the warning
OK - thanks - I didn't know that. Guess I'll just ignore it forever now. You can get Bitcoin-qt to run forever now?? I'm lucky to get a week out of mine. The last reliable one was .9.5 although .10.0 wasn't too bad. |
|
|
|
Hey guys new here. Have an S7 on the way (first week of January should be hopefully). Pretty excited to start hashing, just sold off my USB miners so a bit bored waiting for the S7 to come in. Have a lowly 3GH/s Avalon Nano running right now  Well, get to mining! Merry Christmas. |
|
|
|
@os2sam, well my ADSL with bandwidths of down 12285 kBit/s and up only 940 kBit/s is pretty bad, the info page for running a full node tells to have at least 400 kBit/s upload bandwidth available, which would not leave much room for anything else.
Have you considered using a solo pool such as solo.ckpool.org? That way you don't have to mess with an external full node if you don't want to. I just took a quick look at GBT, AntMiners' cgminer certainly supports it, but how to configure a S7 to use it? And is there any advantage or disadvantage in using getblocktemplate instead of stratum? Does it require RPC and is it safe to use over an unencrypted Internet connection?
Just point your miner at http://nodeIP:8332 or whichever port you use. About rpcallowip=::/0, yes it allows any IP address (new format instead of asterisk), but it should not be any good without rpcuser and rpcpassword, but I guess RPC data is generally transmitted without encryption, so that's only something for use with a VPN tunnel then.
Allowing any IP access to your node allows any hacker a socket to your system which just makes their job easier. So just allow the IP address of your miner. As for encryption, I'm assuming it would encrypt your RPC user id and password. I wouldn't want that in clear text. About using the full node's wallet, the official full node info page tells: It’s possible and safe to run a full node to support the network and use its wallet to store your bitcoins, but you must take the same precautions you would when using any Bitcoin wallet. So it should not make any difference, if it's a headless bitcoind as a full node running on a dedicated server in a data center, or bitcoin-qt on your own computer, but the question remains: Can a local bitcoin-qt be used as GUI to connect to a remote instance of bitcoind using the -connect=<ip> argument? I am sorry if the answers to these questions should be obvious, but I do not have anything for this endeavor running or available yet, I'm just trying to figure out how it all can fit together beforehand. I wouldn't put my wallet on a public facing internet connection. Most of us have a full node running behind our NAT and firewall. You can solomine to any bitcoin address you have control of not just the one on your public facing node. Look at the command line options in Bitcoin-qt if you haven't already. |
|
|
|
I am playing with the idea of having a Bitcoin full node running 24/7 on an Ubuntu server in a data center, with one Antminer S7 running at home in my basement, connected to that full node by ADSL (with dynamic IP) for mining solo.
Why not just run your full node in your basemet as well? 1. Does the full node running bitcoind require a stratum proxy
No, Bitcoin-qt uses the GBT protocol which is fine for one miner connecting to it. 3.The release note for Bitcoin Core mentioned -rpcallowip=::/0 (still dangerous!), I guess this is a security concern in case of an unencrypted connection?
I think that argument allows ANY IP address to connect to your Bitcoin-qt, which is bad. Has nothing to do with encryption. I think the encryption would be to obscure your RPC user id and password, which would be a good idea. 4. Would it be a bad idea to use the full node's wallet to store my bitcoins, and is it possible to use bitcoin-qt to remotely access the wallet on the full node? If bitcoin-qt can remote access the full node's wallet, is it done by RPC?
With your Bitcoin-qt publicly available you probably wouldn't want it to have a wallet. Have another Bitcoin-qt behind your firewall on your home network with your wallet that has your coins. 5. Is there any point in using the Bitcoin Relay Network in this setup?
Only if you find a block |
|
|
|
f2pool - 0 of their 14 blocks were empty
How full/non empty were they? |
|
|
|
I did not know that less fee in the transaction takes longer to process.
Mining blocks is not cheap. Miners/pools deserve to be paid for their work. |
|
|
|
Yep. It took like 12 hours more me. For me it was no big deal, just some change. I think it's strange how transactions get processed due to the amount of the fee in there. What's strange about that? |
|
|
|
Hi guys! CGminer works like a charm! Just one thing, i'am unable to compile it with --enable-bitfury command. I'am trying to run it on newest MAC OS X, 1000 issues with compiling... is there a way to download version with compiled driver for bitfury?
Sure, look in the top post of this thread. Thanks, i've ready it carefully but i still can't find solution for this. My bad if i missed something, is there a way to get cgminer with preloded driver for Bitfury? You didn't see the OSX download link from Karin at spaceman.ca? |
|
|
|
This can not be taken seriously if transactions are ignored, which is what the system is built to produce. Really nothing can be done? All is already lost?
My understanding the discussions are focused on 1mg blocks... When it should be on 26k blocks.
Transactions are processed on a supply and demand model. As transaction revenue becomes a larger percentage then more of them will be processed. If we increase the block size when the demand is low then we are just subsidizing this bad behavior and will get more of it. The system isn't broken it should be allowed to work. |
|
|
|
Hi guys! CGminer works like a charm! Just one thing, i'am unable to compile it with --enable-bitfury command. I'am trying to run it on newest MAC OS X, 1000 issues with compiling... is there a way to download version with compiled driver for bitfury?
Sure, look in the top post of this thread. |
|
|
|
Hi
Any help my bitminter connect only 8 usb block erupter can anyone tell how i can add more i have to do any setting ormy computer hae any issue
What OS are you using? WinXP tops out at around 12, WinVista tops out at 50, Win7 60. I don't think *nix has a limit. |
|
|
|
You remember his wallet key  What? You don't have Bitcoin addresses memorized??  It's funny how you can recognize addresses easily if you see them enough. I can recognize most of mine that I have used. Recognizing them is different from memorizing them. |
|
|
|
Thank you, now I see, it asked, I did not see it because the bottom of the site is very uncomfortable, move to the top if you can.
And a font size big enough to see without a magnifying glass would be great too |
|
|
|
Hmm. That is talking about .9.5 but I guess it would pertain to my 11.1 version too. But why has the warning disappeared now after the restart, I wonder? Thanks again, Sam |
|
|
|
My Bitcoin client 11.1 is telling me it's obsolete and to upgrade. Why is the relatively current client obsolete?
It shouldn't be telling you that. There is no current warning out there. The only thing that I can think of that would cause this warning is that somehow you ended up on a fork of the blockchain. How would I go about verifying that? And what should I do about it you think? Check the highest block you have and the block hashes. Make sure that they match the blocks at block explorers like blockr.io blocktrail.com and blockchain.info. If it doesn't something is wrong and you will need to resync. Otherwise, I have no idea. I ran "getblockchaininfo" and the last block and the hash matched what blockchain.info had. But this is after restarting my client and now the error is gone. Thanks, Sam |
|
|
|
My Bitcoin client 11.1 is telling me it's obsolete and to upgrade. Why is the relatively current client obsolete?
It shouldn't be telling you that. There is no current warning out there. The only thing that I can think of that would cause this warning is that somehow you ended up on a fork of the blockchain. How would I go about verifying that? And what should I do about it you think? Edit: I shut down the client and restarted it and now the warning message is no longer there. Doesn't give me warm fuzzy feeling though. I thought only a very small number of devs had the means of sending a warning like that? |
|
|
|
|
My Bitcoin client 11.1 is telling me it's obsolete and to upgrade. Why is the relatively current client obsolete?
|
|
|
|
I think you're missing the point here. Small time miners get small time payouts - no matter what you may wish to happen. You simply aren't going to get a bigger slice of the pie unless you get more hash. Let's say you do start some kind of pool with an upper limit on hashing power. So, you've got a pool with 10000 miners each having 100GH/s. Do you somehow think that you, as one of those 100GH/s users is somehow going to make more than you would as the same user on a pool that has 2 miners, one has 999.9TH/s and you, with 100GH/s? The simple answer is you are going to make the same.
You are hoping for the impossible.
I wrote on the other thread that I usually make 10 mBTC per 2 weeks on Eligius pool and 1 mBTC per 2 days on Antpool with 100 Gh/s hashrate. Those are roughly equal to 0.7 and 0.5 mBTC per day respectively. If I would mine together with all other 9,999 miners with the same 100 Gh/s, using this method I will definitely get 2.5 mBTC per day. And I will definitely get multiple of that per day as the pool hashrate is 1 Ph/s so it is likely to solve more blocks a day. If there would be only 2 miners with 999.9 Th/s and 100 Gh/s, I would have to wait for a few days until my shares value reach the minimum payout threshold while the other miner would get the most payout every day while I am waiting. This is clear to me that I will make very less than on the previous example. Could you please explain why this would not be the expected result, John (I hope you still have the patience of the Saint)? Ok... let me see if I can break this down for you in a way you'll be able to get . For the sake of this argument, we're going to assume there are 2 pools. Pool 1 has 10,000 miners each with 100GH/s. Pool 2 has 2 miners, one with 999.9TH/s and the other with 100GH/s. We are also going to assume that each pool finds exactly 1 block a day, and the reward is exactly 25 BTC per block. When a block is found on pool 1, the pool must divide that 25 BTC into 10,000 parts. Therefore, each miner gets 0.0025 BTCWhen a block is found on pool 2, the pool must divide that 25 BTC into 2 parts. The miner with 999.9TH/s gets 24.9975 BTC. The miner with 100GH/s gets 0.0025 BTC. They are both equal. Payout thresholds are completely irrelevant. It doesn't matter how you break it down, 100GH/s expects to earn exactly the same coin on pool 1 and pool 2. Thanks again. I assumed that you are referring to the methods used by the current pools, as the example on the second pool would not work on the idea I posted because the maximum hashrate for each miner is 1 Th/s. Payout method has no bearing on the percentage of hash rate you contribute to finding a block. Both scenarios above are correct for any payout system. The different payout systems just distribute the payouts differently to discourage pool hopping. I think I mixed up with the vardiff usage on the current pools. I assumed that there is a maximum limit of vardiff so that the miners with huge hashrates send more shares than the miners with low hashrates as there is minimum limit of vardiff.
Variable diff has no bearing on your percentage of hash rate you contribute. The variable difficulty is ONLY to decrease the amount of network bandwidth required and to decrease the load on the pool. |
|
|
|
|
Show Posts
