...And where do I fit in? Despite what it may look like, this is a technical discussion about the disadvantages of GBT.
imo - you're at least honest in your intent and presentation. I'm not saying that GBT couldn't or shouldn't be replaced with something that is better that what it is now... I'm just saying given the choice between gbt and stratum --- I'll take transparent and clunkier over obfuscated and streamlined. Also I'm not saying 'kill stratum with fire' but I won't be using it until the transparency issue is addressed. The only apparent transparency issue with stratum is that it does not transmit the transactions included in the merkle branches by default. You do know, however, that it supports a get transaction method as well? Then you can reconstruct the merkle branches for yourself and confirm it does what it says. The reality is that 99% of miners will mine blindly trusting their pool, and they rely on the 1% of savvy users to keep the pools in check. It is a mechanism which has worked so far and will continue to do so. There is a way to confirm the pool is doing what you hope it's doing with stratum as well, and enforcing the extra information on the other 99% of users is pointless, as they're not even going to look at it. |
|
|
|
|
One more point about the GBT protocol. If a miner chooses which transactions they include rather than accept whichever transactions the pool/bitcoind has offered in the template, the miner has to submit all the transactions with every share he submits.
A quick check
./bitcoind getblocktemplate
at this very second produces a output that is 469441 bytes!
If every template request was this size and the miner used the customise coinbase option and chose transactions, they would be receiving 400kb for the block template and each share submitted would be 400kb unless they started withholding transactions.
|
|
|
|
I looked at GBT, and I don't see it improving anything. It requires sending the entire block template (potentially up to 1 MB) to miners every 10 seconds, which is definitely impractical for remote miners. An extension to GBT that allowed only sending the merkle root would avoid this, though.
Yes we're debating that very point at length in the GBT thread at the moment, as I do not see the advantage of that either, only potential disadvantage of increasing network bandwidth, or worse, encouraging not perpetuating transactions. Stratum on the other hand uses merkle branches to negate this effect entirely and the bandwidth is virtually static regardless of the miner's hashrate or transaction count. |
|
|
|
|
...And where do I fit in? Despite what it may look like, this is a technical discussion about the disadvantages of GBT.
|
|
|
|
Ah, got it... no, it just uses a sliding window. Is there some drawback to bouncing around? The work is accepted for old difficulty work, so it doesn't matter if there is a difficulty change, since the difficulty is tied to the work sent out. You might be currently working on Difficulty 3 and sending back difficulty 2 shares from an older set of work that hasn't been sent back yet.
Not with getwork, but with GBT (and stratum) the work is tied with the block template they get, so if they ask for an updated block template, and are currently working on different difficulty shares, they lose work across diff changes (mainly on diff drop) since internally the pool only has the notion of the current difficulty target expected from the miner unless you go out of your way to add leeway expecting old target diff work for some grace period. |
|
|
|
Any serious P2Pool user, one serious enough to have ASICs, should definitely have their own P2Pool node...
...With ASICs being 50x more efficient, the only people mining in the future, bar a very few exceptions, will all be running ASICs. And anyone (everyone?) with an ASIC, having invested hundreds of dollars, will be a "serious miner" in my eyes... Ok... so no one will be running p2pool via a remote node? |
|
|
|
I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.
What about mining on a remote node? It seems like ASICs could kill P2P Mining. Any serious P2Pool user, one serious enough to have ASICs, should definitely have their own P2Pool node... ...With ASICs being 50x more efficient, the only people mining in the future, bar a very few exceptions, will all be running ASICs. |
|
|
|
I got a "target-miss" error for json-id 115, which is nonce=430fdafa, block with json-id 112 and a valid diff2 hash=f1f38404e253aef6fa1609b1d96474d8a731ff5dda808a7cdd6b184000000000.
At least this share should not lead to a target-miss error.
This hash: f1f38404e253aef6fa1609b1d96474d8a731ff5dda808a7cdd6b184000000000
when byte swapped is: versus diff 1 which is: This should qualify as a diff 3 share. |
|
|
|
Well, the sliding window is currently set at 180 seconds, so, if I understand what you're asking, then yes to a limited degree.
No, by hysteresis I mean a different threshold for lowering diff versus raising diff. i.e. if the shares are > 20 per minute to increase diff, but then to only lower diff if they drop to < 10. There will be less bouncing around of diff values that way. |
|
|
|
We don't have any limit on the number of free transactions as I understand some other pools have. Although the pool was losing all donations for a while due to the frequency of orphans, I never put in any limits despite the possibility that it would have sped up block propagation and reduced the orphan rate. Glad to hear that, thanks. I wish all pools would do the same. |
|
|
|
US1 is currently set to 20 spm over a 180 second test window. You are connected to US1 and not seeing an adjustment even at almost twice that?
Although... now that I think about it, that makes sense, if you aren't doubling the target then you won't get to 2 very often, since it would bring you in under 20 SPM otherwise, so I think that makes sense.
Ok, wondering whether you used any hysteresis for diff up versus diff down and whether the diff target is a "keep below 20 shares". There's nothing actually wrong here then, just my misinterpretation. |
|
|
|
Con, can you tell us anything about the progress with BFL ASIC support?
No NDA, no physical hardware, no remote access, not even a protocol document to work from. Nothing has been done yet. Will start once I at least get protocol docs. Oh and I realised it was implicit but not explicit in my response, but just since everyone is clinging to any news, I also have not been given any indication of the timeframe for arrival of any of the above. |
|
|
|
Nope, they are still holding on to my funds. @#%#@$ Paypal.
Con - are you seeing what you should be seeing or are you still experiencing a problem?
Depends on what you define as a problem. It hovers mostly around diff 1 and occasionally rises to diff 2 at 37 shares per minute. But you said your target share rate is 30pm for US1 which I thought you said originally was slated for 20pm. |
|
|
|
|
I'd rather see merged mining go.
|
|
|
|
Can I get an explanation of block 205766 ?
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
Now I don't know, but if this is the result of the GBT implementation, it's a worrying sign... considering GBT was meant to improve bitcoin, the potential for pools using it in a way that makes transaction propagation even less likely than before is precisely what I've been complaining about with pooled mining GBT implementations. |
|
|
|
Con, can you tell us anything about the progress with BFL ASIC support? Please choose one of the following:
1. I can't talk about it, I'm under NDA.
2. I've logged in remotely to their servers and have poked around a little.
3. I've logged in remotely and have already begun creating code for BFL's ASIC to work with cgminer.
4. I have no plans to log in remotely to BFL and won't do anything until they send me some real hardware.
5. I have real hardware in hand and am working on the code.
6. I won't support BFL ASIC because I won't develop for them for free and they haven't paid me yet.
No NDA, no physical hardware, no remote access, not even a protocol document to work from. Nothing has been done yet. Will start once I at least get protocol docs. |
|
|
|
|
My bad. Got lost in the noise.
|
|
|
|
|
My rig still hovers at diff 1 on emc1 despite submitting ~37 shares per minute. I thought it was trying to keep shares below 20/m?
|
|
|
|
2.8.7 version of cgminer has been working for me smooth on my 7970 rig in windows. Before that i saw random crashes with erlier versions, good job.
Yay, much appreciate the feedback, especially when it's good  |
|
|
|
|
Show Posts
