Decentralized mining protocol standard: getblocktemplate (ASIC ready!)

[Luke-Jr]

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.

This isn't correct.

Plus, I suspect most mining software would end up requiring a different subset of the GBT protocol than the one bitcoind supports

This isn't a problem.

[1713413108]

1713413108

[eleuthria]

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.

This isn't correct.

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.

[Luke-Jr]

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).

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.

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.

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

GBT is more full featured, but your arguments imply that most mining software wouldn't bother implementing the full feature set to begin with.

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

[hahahafr]

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.

[slush]

The decentralization is important

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.

[Luke-Jr]

...and the stales rates...

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

...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.

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

[hahahafr]

Numbers?

[dooferorg]

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.

[Luke-Jr]

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.

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

[Luke-Jr]

I don't have dialup, but still saving bandwidth is important so the new mining hardware doesn't DDOS your shiny pool by saturating the pools line.

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.

If the GBT thing has been around since February, why aren't all pools and miners already using it?

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.

[hahahafr]

I don't have dialup, but still saving bandwidth is important so the new mining hardware doesn't DDOS your shiny pool by saturating the pools line.

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.

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).

[kano]

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 ...

[ssateneth]

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 ...

quoted before deletion

[kano]

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 ...

quoted before deletion

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.

Since Eleuthria and slush have both recently announced their own developed-behind-closed-doors mining protocols, I felt it appropriate to make a thread here for end-user discussion of the "getblocktemplate" standard which they intend to compete with. As a poolserver author, a pool operator, a miner author, and a contributor to the reference client, my life is not improved by having yet another protocol to support, and what's bad for the authors of the infrastructure tools is also bad for all their users.

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

[Luke-Jr]

Numbers?

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.

[slush]

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.

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 ;-).

[kano]

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.

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 ;-).

... 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.

[slush]

kano, now you're comparing apples and oranges. Stale ratio is affected by many factors and there's no obvious reason why GBT should be worse than getwork.

[kano]

kano, now you're comparing apples and oranges. Stale ratio is affected by many factors and there's no obvious reason why GBT should be worse than getwork.

stale/reject ratio is basically 2 things: 'LP' issues and processing work for too long according to how long the pool will accept the result (and the protocol may allow that all the way up to an LP)

3 different protocols still have that same requirement: accept work or reject it.

There are of course 3 factors in it:
1) The mining software
2) The protocol
3) The connectivity between them

If the miner/protocol/pool is rejecting more work then there is some issue that needs to be resolved.
(or the design is a POS)
As I stated, I get around 0.3% stale with a standard pool protocol
(I can also add that my pool connect is half way around the world, so that should be close to about as bad as it can be)

However, comparing cgminer+getwork/LP+a standard pool
is indeed quite valid.

What other comparison could be made?

Fake up some excuse for bad performance?

His figures are showing his miner+his protocol+his pool are clearly worse than the setup I described ... and I will add that ~0.3% or better is not unexpected from people using cgminer+getwork/LP+'choose random pool'

So I'm not sure where the apples and oranges are ...

[hahahafr]

Numbers?

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.

If I understand correctly GBT also supports LP, doesn't it? Did you make use of LP with getwork and GBT in your test?

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.

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 ;-).

Since stratum is working over a plain TCP connection, one could say that the equivalent of LP is just a simple TCP "message" like any other one, isn't it?

It would really be interesting to see the stale ratio of GBT+LP vs Stratum over one week on the same pool/same connection.