Topic: Decentralized mining protocol standard: getblocktemplate (ASIC ready!) - page 10. (Read 32344 times)

... and I'm not sure when the last time I got much above ~0.3% rejects on cgminer using OzCoin or EMC standard pools.
Which is above Stratum but better than this thread protocol.
Stratum looks like it may be OK, but this thread one being worse than the current numbers on a standard pool is ... not good.

Comparing both solutions based on HTTP+LP, you obviously don't see any difference.

Stratum session on my machine: 60627 submits, 53 stale, it's 0.08 % stale ratio.

This ^^ also includes short outage of my Internet connectivity overnight ;-).

Now that I've had BFGMiner 2.8 running for a number of days, I have some reasonably useful numbers...
getwork session A: 0.83% stale
getwork session B: 1.09% stale
GBT session A: 0.71% stale
GBT session B: 0.66% stale

There's probably a good chance the GBT stales are lower only by coincidence (a lot depends on when blocks are found, after all), but I think it's pretty safe to conclude there's not any notable practical difference just from the protocol.

Thanks

It seems that there is a mod (I wonder who ) who is a slave toy of this stupid thread OP,
who bows down to and deletes posts for him at his whim, to hide the truth about the thread OP.

Not surprising really though, since the thread OP is provably known for lying all over the place to hide his transgressions.

Just reading the first paragraph of the first post and reading exactly what he is saying is rather convincing of the (totally ludicrous) self importance the thread OP places upon himself.

Lulz - what the thread OP thinks is bad, is bad for everyone who uses bitcoind

quoted before deletion

So ... someone wanna tell me who the fucktard mod was that deleted my post from here?
I guess is was most likely Luke-Jr's pissy little dog who does his bidding - but feel free to correct me if I'm wrong ...

Showing the miners the path to enlightenment is nice, but it's not as if we already couldn't do that. Take the Bitminter pool for example: It's clear, transparent, without fees, pool donations are optional, and pays all the transactions fees to the miners. Everyone can check it on the public BTC address that receives the blocks+transactions. After 120 confirmations this same address pays the exact same amount to the miners. More light is not possible.

One should also note that the interest of the pool operator is the same as the miners: Include the best transactions in the next block to maximize his profit (through donations in our case).

Sure, but GBT does save bandwidth. It just doesn't save as much as StratumMP, because it doesn't keep the miner in the dark.

Probably the main (only?) incentive for most pools is surviving when ASICs arrive. There's also the problem of Eloipool being the only (publicly available) maintained poolserver (though p2k plans to update ecoinpool when he gets time), and most pools seem to still be using pushpool or PSJ. Technically speaking, pools running older versions of Eloipool should have an older GBT available, but now that BIP 22 is final, it seemed inappropriate to list them until they are running a compatible version.

GBT has been working with a proxy since February, and is easily added to existing miners.

The stratum approach is working right now with the current installed based of miners. Just point to the proxy intermediary the 'stratum proxy', simple. Been testing this on a miner I have with BTCGuilds stratum test and it's doing great.

Failover to other pools has been addressed by other proxy software and I use that too in conjunction with the stratum proxy with no problem. Miner can work and upstream proxies (on the local network) just decide what pool and how to communicate. I didn't even have to touch the miner software.

Numbers?

FWIW, after 3+ days of use, I can safely say the stale rate is not significantly higher using GBT.

Except miners can't viably choose to switch when they are deprived of the information needed to know when to act.

I agree on this as well. Currently there are 20+ pools + P2Pools and switching over them is the matter of few seconds, and miners already rotates around backup pools. There's really no reason to think that individual miners know better than poolop what they're doing. And if miner is suspicious about poolop activity, he can just switch the pool to another.

I mean - there's no reason to make mining protocol less effective (from any point of view, including CPU resources and used bandwidth, and more difficult implementation in the miners) just because decentralization itself. Market of mining pools is great example of free market and miners can achieve the same level of "decentralization" just by switching to the pool which fits their needs.

The decentralization is important, I agree with you on that Luke. The single-line, TCP connection of slush is still an elegant solution from a miner's point of view. I didn't read much into the technicalities of the GBT protocol, but eventually it's the effective implementations, and the stales rates that come with which ones that is going to determine what protocol is gonna be widely adopted once ASICs are shipped.

Yes, I forgot the exponential factor involved here. However, with a local bitcoind, GBT can shrink far smaller than StratumMP. If bandwidth is a real practical concern for BTCGuild (or anyone else), someone (possibly me, if someone needs and plans to use it) could easily write a "Centralized Mining" extension for GBT providing the same bandwidth savings. Of course, keep in mind that GBT is already going to use far less bandwidth than getwork, so this really shouldn't be a problem. Remember that centralized mining moves the miner's authority blindly to the pool operator, and thus creates a greater risk to the Bitcoin network. Health of the Bitcoin network is IMO far more important than saving a few KB of bandwidth here and there. So... as long as there isn't a practical problem involved, it would seem a shame to keep centralized mining going unnecessarily.

Yes, the biggest hurdle is rewriting all the miner code actually relevant to the protocol at all.

Hopefully mining software will grow closer to full-featured over time. It's pretty important that mining become decentralized, at least.

An empty (coinbase-only block) StratumMP work payload is 399 bytes.  An empty GBT work payload based on your example is 737 bytes.

StratumMP work payloads increase 67 bytes per power of 2 transactions.  GBT work payloads increase by the size of the transactions being included in a block (roughly 250 bytes for a normal tx with 1 input, 1 payout address, and 1 change address).

For StratumMP, a block containing 257-512 transactions would require an extra 603 bytes, for a total of 1002 bytes.  GBT would require approximately 128,000 bytes.
Using a more common example, lets say each block has 100 transactions on average.  StratumMP would be 868 bytes per work payload.  The GBT equivalent would be approximately 26,000 bytes.

Similarly, work submission payloads are quite different.  GBT would require 501 bytes per share submission in your example.  StratumMP requires only 109.

None of the above factors in the added overhead of wrapping GBT into HTTP Requests.


The biggest hurdle on implementing StratumMP is changing from constant HTTP connections and inefficient longpolling, to a static TCP connection.  Beyond that change, StratumMP is a simpler protocol to work with and implement.  GBT is more full featured, but your arguments imply that most mining software wouldn't bother implementing the full feature set to begin with.

This isn't correct.

This isn't a problem.

I've mostly finished a more friendly writeup on getblocktemplate on the Bitcoin Wiki, covering (almost?) everything StratumMP's page covered. Take a look and let me know what you think, or how it might be improved! Feel free to edit it directly too, of course

The problem with GBT is not so much what features it's missing, from what I can tell. Everything that can be done with Stratum can be done with GBT, it'd just far require more bandwidth and every piece of mining software would need code to parse and serialize Bitcoin transactions and blocks and to implement a whole bunch of different cases. Plus, I suspect most mining software would end up requiring a different subset of the GBT protocol than the one bitcoind supports so it's not like using the same protocol for both would even help solo miners.

Question off-topic in another thread, pertaining to bitcoind GBT support:The GBT patch for bitcoind was originally fully backward compatible, but was changed to replaced GMP instead per the request of the rest of the bitcoind development team.