Topic: Mining protocol bandwidth comparison: GBT, Stratum, and getwork - page 4. (Read 28311 times)

Actually, many pools have GBT implemented.  I take that as advocating.

Also, kano suggests a lot of things.  See my post above (edit: and gmaxwell's) for an example why we shouldn't just listen to kano.

And I don't see how Luke-Jr could have possibly rigged his test, when as per his own list, GBT is not number one on his list.  Plus he also provides the result for stratum-secure using the same request time values as GBT (0.25).

Please read and think before jumping to conclusions, folks.

-wk

None of this has anything to do with transaction confirm times.  It might impress the less technical people when you throw nonsense around like this, but it's really just everyone with a clue embarrassed on your behalf.

I don't exactly see how this makes any sense.  As we know, transactions are confirmed initially when they are mined in a block, and receive a bump in confirmation every time a new block is built on top of the block in which the transaction appears.

Now, the bitcoin network is tailored for blocks every 10 minutes.  Now, I'm no rocket scientist, but, as far as I know, 30 seconds, 80 seconds, and 120 seconds are still < 10 minutes.  So, at most, even if any protocol shifts mining the transaction by any of those times, the confirmation time gets pushed to the next block.  So, instead of 10 minutes, its 20 minutes to get a confirmation, in a worst case scenario.  And, again, no rocket scientist here, but, 20 divided by 10 != 4.

And this is a moot point anyway.  The polling interval of getting new work containing new transactions (GBT, getwork, stratum, custom, whatever) shouldn't adversely effect confirmation times on average as long as the work is requested at intervals of less than half the bitcoin block mining target of 10 minutes, since every time a block is found, the new transactions will be used for the new work anyway.  So, at most, again, even in a worst case scenario we're talking about pushing the transaction back one block IF the transaction if given to the pool that just happens to mine the next block AFTER *every* miner of that pool has already requested their work, but before it mines the block.  Seems like a pretty unlikely scenario even at 120 seconds (20% block target time).

I really want to know where this 4x longer to confirm number comes from...

To summarize, lets look at every protocol as pseudo code:

(X being 1/2 the protocol's new work interval)

• Miner requests work from pool
• X seconds later, Network user submits a transaction
• Miner mines a block using work from line 1
• Miner requests new work from pool due to new block found (this happens < X seconds from line 1)
• Miner's new work's works on the transaction referenced on line 2, < X seconds from the time it was submitted to the network
• Some miner (maybe this one, maybe somewhere else) mines a block that contains the transaction from line 2 sometime between now and 10 minutes from now, on average

Transaction confirmation time: X seconds at a minimum, to 10 minutes, on average.

So, if the network contains only one miner, polling at X second intervals, then transactions take at least X seconds to be put into a block, and 10 minutes on average.  In practice, regardless of the value of X, miners are not requesting work from their pools or solo bitcoind at the exact same interval, so, again, as long as the value of X is less than 5 minutes, the value of X has no real effect, on average, on transaction confirmation time, because blocks happen on average every 10 minutes.

But, as this forum is full of trolls anyway, I don't think anyone should just trust me, kano, luke, or anyone else.  Do the math yourself, have someone you know do the math for you, or in some other way verify the numbers yourself.

-wk

P.S. - The OP was actually about bandwidth usage, not confirmation times... FWIW, I'm at 0.49 shares per 2KB with stock-settings bfgminer on Eligius using GBT with my four x6500s (~1.5GH share acceptance rate), after about 10 hours.... which is actually better than Luke-Jr's result, for whatever reason.  Seems stock setting is a scantime of 60 seconds and expiry of 120 seconds... which IIRC is the same as cgminer.

So let me get this straight, this whole debate over GBT vs stratum boils down to the issue of "network security"? I'm all for network security, but I usually leave the details for people smarter than me. However, I have to ask the same questions as Kano: Does having every miner on a pool verify the transactions actually increase security? And also how does mining at a centralized pool using GBT = decentralized?

It seems to me that if these "security" issues are actually a non-issue, than stratum + cgminer = the best solution. I say cgminer because LJR admitted to having to edit his program just to use the same stratum implementation as cgminer. We get the same amount of "security" as the old GW, but with far less network usage and far greater scalability. On the other hand, if these issues are actually legitimate, than it would appear that GBT is the way to go, as it does use a little less network usage.

However, I have to take into account 3 things: LJR is the only person I've seen advocating these changes. LJR is also the author of GBT and BFGminer, the competing solution to the problem he seems to be the only person caring about. And lastly, kano suggests that LJR jimmied the test to make his protocol look better.

So firstly, anyone wanting to see the figures, simply look at the cgminer API and see for yourself.

Yes not much point trusting what Luke-Jr has to say - look at the numbers yourself ...

cgminer API stats command includes the number of times data is sent and received and the amount of data sent and received.

As Luke-Jr has stated above (though the numbers are false and he knows it), he has GBT increasing transaction confirm time by 4 times what Stratum does with his clone miner.

In cgminer, we keep the transaction confirm times roughly the same for both Stratum and GBT - which Luke-Jr complained about saying that it is better to have GBT increase transaction confirm times by 4 times what Stratum does.

Now, I still have yet to see explained anywhere how getting the list of transactions stops a pool from attempting a double spend or gains any other security?
It may be some wet dream that Luke-Jr likes to fantasize about, but no such security exists, anywhere.
As for decentralised?
How exactly is having a centralised pool using GBT decentralised? It isn't.

The few times I bothered to look at the cgminer statistics I got something of the order of GBT is 50x Stratum but there was another factor to take into consideration (share difficulty) so it's probably not quite as high as 50x
But again, anyone can do it themselves and see the numbers - no point taking much notice of Luke-Jr's rigged results and lies.

Stratum (on the pools that invented it) sends work roughly every 30s as per design.
GBT on Luke-Jr clone miner gets work every 120s - go check the code - that's what it says - not 80s as he lied above.
You wont find that 80s anywhere in the clone miner code.
He rigged the results.

Again, on his miner clone you are increasing transaction confirm times by 4 times with GBT versus Stratum
on cgminer they are the same thus they have the same effect on BTC transaction confirm times.

Not "will be" — is the only. The reference there is 2kb of data... a very tiny amount.  The only reason to worry about data amounts for normal users is higher rate miners. And the other protocols don't increase their inbound bandwidth much at all for higher rates.. while GETWORK basically becomes linear with hashrate.


If you really wanted to assume these attacks couldn't happen, you could just have a few centralized parties handle all the transactions and we could just skip this whole costly mining thing.  Perhaps we could call the resulting system "paypal", if the name isn't already taken.  

But more seriously, top pool infrastructure has been compromised before— fortunately there was more to be made from robbing the pools hot wallet than by maliciously redirecting the mining, though thats not as likely to be true in the future.  Compromising any major pool— even if it's not a majority at once is still bad because it enables a variety of nasty attacks.

And certainly, more smaller pools would be better.  But regardless of the pool size— bitcoin loses the decentralization that makes it valuable if the people buying hardware aren't doing any due diligence to make sure their hash power isn't being redirected to attack.

At 3.5 Gh/s, yes. Due to scalability, GBT will probably surpass getwork somewhere around 20 Gh/s.

BFGMiner implements secure stratum, and CGMiner implements blind stratum. (Edit: The testing was all done on BFGMiner, however; I commented out the secure stratum code for the blind stratum test)

It shouldn't change much, correct. But that's just blind stratum, which is harmful to the network. Secure stratum is less efficient. And all stratum is less flexible (currently).

That's the main issue, yes. By making pools a high-value target (due to the ability to do these things), I'd say the attack is a lot greater than it would be using a secure mining protocol. Perhaps it isn't economically useful today, but it will be if Bitcoin ever takes off.

Why is that? Probably because 3-5 big ones centralizes more mining than 10-20 medium ones? That's exactly the point: 3-5 big ones using GBT isn't any worse than 10-20 medium ones, since the mining is decentralized again.

I understand scaling is will be a big issue, but your own findings show the old GW is 3-6 times more efficient than your own protocol? Moo point (You know, like a cows opinion? +1 if you get the reference) as this is all gearing up for ASIC,s but I just think it's funny.

I'm assuming this was done on BFGminer, but I thought there have been reports of higher-than-normal network usage with stratum as compared to CGMiner. Ya, I went there. Sorry, as I don't want to turn into a flame-war, as I'm very interested in the outcome, but isn't there a difference? Im looking for answers from people other than LJR, as you seems to present present the hard evidence in this thread, but you are quite a bit biased.

And as of right now, stratum is 22x more efficient than GBT? Both were designed for scaling, so this won't change (much), correct?

And lastly, anyone besides LJR care to comment on the issue of "network security" by using GBT or "secured" stratum? Correct me if I'm wrong, but the only difference is downloading all of the transactions and independently approving them, rather than just hashing at what the pool gave you? A) Is this correct? B) How likely is an attack on a pool to the point where the pool's hashrate could be controlled and used maliciously? C) How likely is it that the top 3 pools could have this happened at the same time? I do not mine at one of the top 3, as I'd rather see 10-20 medium sized pools than 3-5 big ones.

I took a few hours to do some mining protocol bandwidth usage comparison/tests on my 2.5 Gh/s development mining rig. For each protocol, I gave it 10 minutes and measured its bandwidth usage in terms of (difficulty-1) shares per 2 KB (in both directions). I chose 2 KB because this is roughly the amount of bandwidth used to mine 1 share using the original no-rollntime getwork protocol, and therefore this metric gives approximately 1.00 "bandwidth-based efficiency" per the classic 100% "work-based efficiency" (what BFGMiner displays now).

Stratum ( blind ): 7.44
getwork (rolling): 2.19
getwork (no roll): 1.08
getblocktemplate : 0.33
Stratum (secured): 0.17

Stratum is updating every 55 seconds; GBT every 80 seconds. If secured stratum updated only every 80 seconds, its efficiency would be 0.25. Most likely the difference between this 0.25 and GBT's 0.33 is accounted for by the gzip compression employed by GBT.

Note that these numbers do not take into account scalability. The main benefit (in terms of bandwidth usage) for both GBT and stratum is that they scale without using more bandwidth. I will probably do another run of bandwidth testing when ASICs ship.

They also don't account for Bitcoin security: getwork and blind stratum, though far more bandwidth-efficient at 2.5 Gh/s, give the pool the ability to do double-spends and other kinds of attacks on Bitcoin. Even if you decide to trust your pool operator, this makes the pool a huge target for crackers since it enables them to abuse it to attack Bitcoin. With blind mining protocols, all it takes is someone cracking the top 3 biggest pools to 51% the network.

To try to avoid pool differences affecting the results, all the measurements were made on the Eligius mining pool within the same timeframe.