should be all my pc's state same, btcguild just found block: 22562 timestamp: 2013-10-23 07:39:47 PM
my solobfgminer: 19:40:20 new block detected on the network
meh its roughly 30 seconds, I guess I can live with it. machine is not a very powerful one, old, old dell desktop I had given to me.
Topic: Solo question - will blocks be accepted? basic BTC question. (Read 1817 times)
clocks arent synchronized?
Ok put the addy back in and showing GBT on my solo pool.
I also have been comparing block times, and even with a backup pool BTCGuild (eleuthria ROX!!) my QT client appears to be approx. 2 minutes behind. I get new block detected on network timestamp ~2minutes past BTCguilds found blocks timestamps. Sometimes I get the backup pool relay message and then my solo pool says it caught up to new block, which is good.
Does this mean I am mining stales for those 2 minutes? Is that bad or normal?
I also have been comparing block times, and even with a backup pool BTCGuild (eleuthria ROX!!) my QT client appears to be approx. 2 minutes behind. I get new block detected on network timestamp ~2minutes past BTCguilds found blocks timestamps. Sometimes I get the backup pool relay message and then my solo pool says it caught up to new block, which is good.
Does this mean I am mining stales for those 2 minutes? Is that bad or normal?
OK this is weird- my solo instance of BFGminer used to show my solo pool http://127.0.0.1:8332 as getwork, I restarted my bitcoin-qt and BFG miner,now the pool shows as GBT- is this right?
Yes I would think that's right since both Bitcoin-QT and BFG do GBT Solo. That should be a good thing.
OK this is weird- my solo instance of BFGminer used to show my solo pool http://127.0.0.1:8332 as getwork, I restarted my bitcoin-qt and BFG miner,now the pool shows as GBT- is this right?
also connected another rig to my solo pool and that shows as Gwork in BFGminer....fut the whuck?
and.. removing the argument coinbase-addr changed it back to GWork in bfgminer... begs the question, is GBT better? and should I keep the coinbase-addr argument in my BFGMiner startup option?
or, is this just misreported and all I can do with daemon is Gwork no matter what BFGMiner thinks it is?
also connected another rig to my solo pool and that shows as Gwork in BFGminer....fut the whuck?
and.. removing the argument coinbase-addr
or, is this just misreported and all I can do with daemon is Gwork no matter what BFGMiner thinks it is?
--coinbase-sig "Yep Icon did it again!"
Isn't there a command line option to do that with the Bitcoin-QT client?
so - meaning my wallet would get the 25 btc regardless? good. hate to think I may have hit the lottery and muffed it up.
No worries. The Bitcoin daemon would have assigned the reward for each block to an address in its pool.
thanks, Icon, I did not have a payout address, (noob didn't RTFM, the readme.solo file , duh) I have like 60 connections now after the port forward.
Thanks to all for the replies...
M1n3r49er
Thanks to all for the replies...
M1n3r49er
Probably more important than latency is the number of nodes your daemon is talking to. Forwarding port 8333 inbound to your daemon will increase the connection count above 8. When I ran solo, I announced blocks through 50-90 nodes at a time.
might also be worth using add node to connect to a few supernodes such as blockchain.info and a few off there lists.
plus #1 on its list doesn't even forward blocks or do transaction verification, afaik. can correct me if i'm wrong, i haven't checked the bitpeer project for a couple months
i think lukejr's list is better luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt, just ignore the nodes that aren't 0.8.4 or higher.
you only need a handful or so of connections. so should probably have like 10 connects set up, since sometimes ppl get ddos'ed or go down for whatever other reason
Also you'll want a failover address in there from another larger pool, to keep your block in sync with the rest of miners. hate to work on day old data. 
O and if you using bfgminer need to readme.solo file need to set an payout address and if you want to sign the block you solve
Here is an example:
bfgminer --compact -o http://localhost:8332 -u icon -p xxx -o stratum.btcguild.com:3333 -u xx -p xx -G -S erupter:\\.\com53 -S erupter:\\.\com28 --coinbase-addr 1JafVRe23oLSku4FBwBE3rJAKc9Y8wZM5z --coinbase-sig "Yep Icon did it again!"
That above is were i assigned 2 com ports (usb miners) to solo for me
O and if you using bfgminer need to readme.solo file need to set an payout address and if you want to sign the block you solve
Here is an example:
bfgminer --compact -o http://localhost:8332 -u icon -p xxx -o stratum.btcguild.com:3333 -u xx -p xx -G -S erupter:\\.\com53 -S erupter:\\.\com28 --coinbase-addr 1JafVRe23oLSku4FBwBE3rJAKc9Y8wZM5z --coinbase-sig "Yep Icon did it again!"
That above is were i assigned 2 com ports (usb miners) to solo for me
1) rpcallowip - should this be only the IP addy's of my local lan mining rigs? or the default * ? will that block my newfound extra connections since port redirecting 8333 to my bitcoinQT machine ?
rpcallowip should include the IPs of machines that will mine for you. You can also leave it as "*" in which case the entire world could, in theory, mine for you. Your router will block this though, since the RPC port is different from the regular Bitcoin port that is used to sync nodes (8333) and you probably won't have the RPC port fowarded.tldr: Doesn't really matter what you choose, as long as your miner IPs are included.
Quote
3) setgenerate and getgenerate = whats this do ? getgenerate returns false, does this mean I am not able to mine solo??
These parameters are related to mining with the built-in miner of the Bitcoin-client itself, using the CPU. They haven't been relevant for a long time.
ok I ran guiminer and my GFX card is getting dif 1 accepted shares, bfgminer shows A=0 so if I get A=1 does that mean a block? and I hit the lottery?
ok I am running bitcoin 8.5 on windows, my conf file needs server=1 and daemon=1. rpcuser and password.
couple questions:
1) rpcallowip - should this be only the IP addy's of my local lan mining rigs? or the default * ? will that block my newfound extra connections since port redirecting 8333 to my bitcoinQT machine ?
2) running bfgminer, says its connected, but there is no messages on the screen, so I am not sure if I am mining solo....
3) setgenerate and getgenerate = whats this do ? getgenerate returns false, does this mean I am not able to mine solo??
couple questions:
1) rpcallowip - should this be only the IP addy's of my local lan mining rigs? or the default * ? will that block my newfound extra connections since port redirecting 8333 to my bitcoinQT machine ?
2) running bfgminer, says its connected, but there is no messages on the screen, so I am not sure if I am mining solo....
3) setgenerate and getgenerate = whats this do ? getgenerate returns false, does this mean I am not able to mine solo??
ok I added rules for port 8333, now, am I going to get hacked by Linux Super Villains(http://www.youtube.com/watch?v=8LsxmQV8AXk)?
can someone tell me how to list the inbound connections using the console in bitcoin-qt in windows 7 so I know if its doing its thing? should I have more than 8 connections in the connections list now? canyouseeme.org reports success from the LAN PC on 8333.
EDIT - I restarted and now have 10 active connections, so I guess I am on my way... still worried about the super villains, tho.... ( I love that old video, always makes me laugh
)
can someone tell me how to list the inbound connections using the console in bitcoin-qt in windows 7 so I know if its doing its thing? should I have more than 8 connections in the connections list now? canyouseeme.org reports success from the LAN PC on 8333.
EDIT - I restarted and now have 10 active connections, so I guess I am on my way... still worried about the super villains, tho.... ( I love that old video, always makes me laugh
)
Probably more important than latency is the number of nodes your daemon is talking to. Forwarding port 8333 inbound to your daemon will increase the connection count above 8. When I ran solo, I announced blocks through 50-90 nodes at a time.
might also be worth using add node to connect to a few supernodes such as blockchain.info and a few off there lists.
Probably more important than latency is the number of nodes your daemon is talking to. Forwarding port 8333 inbound to your daemon will increase the connection count above 8. When I ran solo, I announced blocks through 50-90 nodes at a time.
50ms is good it just helps your miners if they find a block to claim it across the network faster that way its added to the block chain and reduces the chances of the blockchain finding a new block and orphaning yours.
it just helps your miners if they find a block to claim it across the network faster that way its added to the block chain and reduces the chances of the blockchain finding a new block and orphaning yours.
ok average ~50ms to google dns; also same for one of the IP's listed in my debug log file from bitcoin-d. should be good right?
as long as the connection can keep bitcoind uptodate quick enough it should be fine... iv got and euro millions.. if i win im going to invest a small fortune in mining gear XD
thanks for the info, I have 7G right now on the solo rig, just for shits and giggles. I am on a broadband connection,10 X 1 default values in bitcoin-d, so that should be good.
and @vm1990: I bought a lottery ticket today as well
and @vm1990: I bought a lottery ticket today as well
aslong as you have a half capable connection and miners the block will get accepted... if you have a slow connection with high ping then the odds are it will just stale out and be orphaned.. i do the same i have 2ghs solo mining and ine day maybe they will find a block.. hell its cheaper then the lottery and probably better odds
The hashpower used to solve a block has no effect on whether the network will accept a solved block. A solved block is a solved block.
Of course, someone else could solve a block and announce it on the network-- just before your miners announce a new block. This is true for solo miners and pools, alike. Last year, I checked the status of one of my solo miners and found:
Accept: 0
Reject: 1
Son of a @#%^#$@&^%$#!! "Missed it(50BTC) by that much"...
Of course, someone else could solve a block and announce it on the network-- just before your miners announce a new block. This is true for solo miners and pools, alike. Last year, I checked the status of one of my solo miners and found:
Accept: 0
Reject: 1
Son of a @#%^#$@&^%$#!! "Missed it(50BTC) by that much"...
With this difficulty, finding a block with a solo rig is like winning the lottery. But in case you find the block, it will be accepted. We are all equal, big and small.
OK, please do not reply with 1,000 "why are you mining solo, join a pool" posts.
I am in a few pools. I also have a small set up mining solo, just in case I get lucky.
So, on the off chance that I do find a block, will it be accepted? Are all the miners out there that run the big pools only accepting blocks that are generated from a few large operations?
- my hash power is miniscule, so if I find a block would it be rejected because someone else with HUGE hash power has already solved it, and I can never catch up to the currently solved blockchain?
Would a block that was accepted by my solo set up start another hard fork foul up?
any insight at all on how this whole thing works would be helpful.
thanks in advance-
M1n3r49er
I am in a few pools. I also have a small set up mining solo, just in case I get lucky.
So, on the off chance that I do find a block, will it be accepted? Are all the miners out there that run the big pools only accepting blocks that are generated from a few large operations?
- my hash power is miniscule, so if I find a block would it be rejected because someone else with HUGE hash power has already solved it, and I can never catch up to the currently solved blockchain?
Would a block that was accepted by my solo set up start another hard fork foul up?
any insight at all on how this whole thing works would be helpful.
thanks in advance-
M1n3r49er
Jump to: