do the bfgminer also need the opencl.dll (ati sdk) or can it be used without? It needs OpenCL.dll if you want to use the OpenCL driver, but not otherwise. |
|
|
|
The most recent bitcoin/bitcoin.git has "signature verification cache" which should speed up block validation quite a bit.
That's very interesting and if it makes a big difference should be a fairly urgent update for pool owners if the problem is as big as it appears to be. It's mostly the rest of the network that needs to upgrade for this to be of any benefit. |
|
|
|
Can't wait for it to be merged in the mainline client! As of right now, that probably won't be happening. There's a lot of cleanup needed before it can be merged, and both coderrr and dooglus who were maintaining it seem to have lost interest. I've been rebasing it for next-test, and Diapolo is trying to clean up the GUI code, but it still needs someone to clean up the internals. |
|
|
|
|
IMO, they like Inaba/EclipseMC because they offer automatic PayPal conversion. That's a killer feature for a lot of miners, I bet. Guess who are BFL's customers? Miners.
|
|
|
|
k, trying
cgminer -S COM4
and this when eventually starts, not seeing a MMQ device. but did see this on start up
Icarus Detect: Test failed at COM4: get 00000000, should:000187a2
Error reading from BitForce (ZGX)
k, update
went back to
cgminer -S modminer:\\.\COM4
and now see:
MMQ 0: Programming \\.\com4... DO NOT EXIT CGMINER UNTIL COMPLETE
after 10 mins I see
MMQ 0: Done Programming \\.\COM4
MMQ 0.0: Setting clock speed to 210
After all that, it is still saying OFF :-(
Will leave it longer, I have to head out now.
Phil Nothing after setting the clock speed? No other command line options at all? |
|
|
|
sub
What is with all this "sub" spam? Is there some reason you guys can't just click to stupid "notify" link next to "reply"? |
|
|
|
use -S modminer:\\.\COMn for cgminer. Of course it can't just be -S COMn like bfl or the like. If -S COMn works with a BFL, it should work with a ModMiner too. You only need "modminer:" if another FPGA's detection is messing it up or (more likely) slowing down startup; same as "bitforce:". Windows allows "COMn" for 1-9, but requires "\\.\" before any others; blame your OS for stupid stuff like this. K, I'm having issues with cgminer not seeing the device. The device says it is all installed ok. And under devices can see ModMiner Quad. The only other instance I've heard of anything like this happening, the user had --temp-cutoff for their GPUs, but didn't update it when they added FPGAs to their setup. If you only have 2 to X temperatures listed, X+1 onward get disabled at 0 C which is almost always immediately. Use "cgminer -d ?" to see what order CGMiner sees your devices in, then set --temp-cutoff based on that. |
|
|
|
No; since you now don't have the block until you've requested every txn you're missing, it would probably take longer. And you can't accept the block until you have all its transactions, or you create a security risk. What security risk? The proof of work can't be faked. From the Pow point of view the tx in the block are immaterial. The merkle root hash is merely a 256bit input. Also i didn't mean download tx one at a time. More like: broadcast block header -> node verifies and relays -> node verifies and relays -> node verifies and relays Then nodes request the "block body" from peers and propagate. If there is no valid matching merkle tree for the header the block is discarded as invalid and network revert to the prior longest chain. And in the meantime, all the miners are working on an invalid blockchain... |
|
|
|
Balance Unpaid reward : 0.21928776 BTC Edit: After this current round, you will have 55 satoshis EC left; so about 55 more blocks... Oh, so the actual balance isn't this?: Current block estimate : 0.00000001 BTC I keep seeing this number halve until it reached a satoshi, so I thought this is my EC balance... Guess I'll have to wait it out then.  That's the estimated reward that will be added to your balance at the end of the current round. |
|
|
|
Balance Unpaid reward : 0.21928776 BTC Edit: After this current round, you will have 55 satoshis EC left; so about 55 more blocks... |
|
|
|
Just noticed my spare balance of ~0.21 is still here despite the fact that I've never mined to it for almost two months. How long do the 'extra credit' mode last?  Until we get back to the positive side of luck. If you stop mining, it's possible you might get to zero sooner, though. My balance is at 1 satoshi for more then a week now. Is that counted as approximately zero? How did that happen? Link? |
|
|
|
Well I am less concerned about block prop times as doesn't the new (0.7) of bitcoin eliminate the double verification of block txs. That should dramatically help with prop times.
Also correct me if i am wrong but could block prop be spit into a two step process.
1) Broadcast block header. Nodes can verify the validity of the pow w/ just header.
2) Nodes request block txs from headers they have confirmed are valid.
This would result in full block taking no longer to verify and propogate than a 0 tx bock. It would also provide other useful benefits. No; since you now don't have the block until you've requested every txn you're missing, it would probably take longer. And you can't accept the block until you have all its transactions, or you create a security risk. That being said, it might still help to cut down on bandwidth use; my suggestion in this area is a compromise: send blocks as header+txnlist initially, but keep track of which transactions you didn't have when you received it, and automatically send those to peers you relay the block to before they ask for them. This way, nodes only have to explicitly ask for transactions they didn't have, but the peer relaying the block to them did have. To address the block propagation problem itself, however, my first recommendation is to relay the block before checking transactions (but after checking proof-of-work and other fixed-cost checks, so DoS attacks are still impractical). The blocks with more transactions still have the cost of transaction verification delay (that cannot be fixed without changes to the Bitcoin system itself), but that delay shouldn't affect orphaning of the block itself. |
|
|
|
Just to make it clear what we're talking about:
(snip)
Thanks for the charts it illustrates the symptoms clearly. That sharp rise in avg confirmation time can't be explained by increased tx volume. The avg confirmation time isn't the (immediate) problem. The problem is block propagation time. If that isn't solved, you will likely see another sharp rise in avg confirmation time soon. |
|
|
|
Elapsed should 'almost' never be used unless there is an actual specific reason for it
How long has a block been around is a good example of when it shouldn't be used - that should be a timestamp It is a timestamp... Also - I like float MH/s not H/s since that is what everyone thinks in nowadays and yeah in the future it will be even bigger 1 TH/s is 1000000000000 H/s - that number is just way too big already ... 1000000.000000 MH/s is 'nicer' IMO  1e12 is valid JSON. |
|
|
|
Just noticed my spare balance of ~0.21 is still here despite the fact that I've never mined to it for almost two months. How long do the 'extra credit' mode last? Until we get back to the positive side of luck. If you stop mining, it's possible you might get to zero sooner, though. |
|
|
|
Interestingly there's not such a clear correlation between average Tx per block and the increase in orphans produced. There's no way to get enough orphan data for good statistics. Just reading through the ones blockchain.info has seen, though, suggests a clear bias toward smaller blocks IMO. So are you saying that Eligius doesn't have a list of all the blocks (or their hashes) we mined in the pool, regardless of them getting orphaned or not? Eligius-Ra's bitcoind in theory contains that data, but I'm not aware of any way to get it. If the coinbaser completed on the new block (which it almost always should) there should be a file in the JSON API directory. But even with the high orphanage rate we've been getting, Eligius doesn't have enough orphans to be statistically significant. Anyway, if you do have such a list, then please just publish it and I promise to draw a graph - checking which of them got orphaned and how the percentage has changed in time.
Only then we can see if something really got screwed up in the network - or is it only a bad luck. Try looking through http://eligius.st/~luke-jr/raw/7/blocks/ |
|
|
|
So it was SatoshiDice. I was wondering what had changed to make mining profits so noticeably worse despite difficulty being in previously experienced ranges. Dice is abusing the network, but it isn't the root of the problem; the real problem is that Satoshi's design aimed at making the actual transaction processing have near zero cost has failed, and all the assumptions built on that premise collapse. Luke is guessing it is SatoshiDice, it might just be a run of bad luck.
Or it might be a side effect of Eligius accepting non-standard transactions.
Does Eligius include transactions that have not been transmitted/relayed to the rest of the network? If so, it might be a side effect of that (and if that isn't a side effect now, it might be in the future if Eligius blocks take longer to verify as other nodes need to fetch transaction inputs from disk, instead of already having them in cache memory like transactions that ARE transmitted/relayed). Bad luck is a normal part of mining, and almost certainly has its role at Eligius recently; but it's also certain that isn't the only thing going on. I did indeed check to be sure nobody was abusing non-standard transactions. Interestingly there's not such a clear correlation between average Tx per block and the increase in orphans produced. There's no way to get enough orphan data for good statistics. Just reading through the ones blockchain.info has seen, though, suggests a clear bias toward smaller blocks IMO. |
|
|
|
The bad news, this looks to be a global scalability problem. Maybe we need smaller and more blocks, but that's very unlikely to change, and has its own problems. Or a tiered network with small nodes not verifying everything -- again with problems. Before starting to cry, I would actually prefer to see some numbers - i.e. what was the percentage of orphaned blocks 3 months ago, comparing to what it has been for the last few weeks. Great idea. Eligius' block history is at: http://eligius.st/~artefact2/blocks/The 'Status' column shows whether or not a block was orphaned. See if there's been an increase here, then check other pools, and let us know No, it hasn't shown orphans at all for a while. I'm not sure a good way to see this info, considering most orphans are never seen by most of the network at all... |
|
|
|
Is there any specific reason that a large number of transactions would specifically cause orphans? Is it just because they are slower to be propagated to the network, or is it just too taxing to current pool softwares and algorithms to deal with? They propagate the network much slower. First, because the larger amount of data takes longer to upload. Then more, because Bitcoin nodes don't relay it until they've verified every transaction in the block. I am not sure I can follow. I understand how large blocks propagate slower through the network, and how this causes higher orphan rate. But how does not accepting *TXs* into your own to be mined blocks improve this scenario, as long as other pools still mine them? -coinft If I understand Luke, he said that when a pool mines a new block and announces it to the network, the block does't get relayed by any node until the node receives all the transactions that are listed inside the block. Is this really true? I would have thought that for my node receiving a transaction inside a block is the same as receiving it outside a block. Moreover, if there is a tx inside a block there shouldn't be anything pending for it - so why would it wait? The block itself contains the full data for each transaction. So if we fill the block to the max, that's a 1 MB block that each node needs to download (from another node, likely not a server with a big fat upload pipe) before it even starts validating it. Then once it's downloaded, it's up to 20,000 ECDSA cryptographic signature verifications before it decides the block is valid and begins relaying/uploading it to other nodes. |
|
|
|
|
Show Posts
