Bitcoin Forum

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.

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.

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.

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

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.

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.

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.

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.

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.

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

I suspect you've already reached a number of conclusions and that I'm just wasting my time responding—  since you're already ignoring the points upthread, but in case I'm incorrect:

GBT was originally created by ForrestV (under an the original name, getmempool) so that p2pool could exist.  Today _all_ current pool software uses it to talk to bitcoind.   Luke took up the task of writing the formal specification for it and made a number of important improvements to close some denial of service risks and to make it more useful for general pool software, and because some of the updates weren't completely compatible and because the old name was confusing it was renamed.  GBT is part of the bitcoin ecosystem, developed cooperatively in public, reviewed and used by many people, part of the reference software, with a clear publicly agreed specification.  It's not just "luke's thing".

When you "mine" using getwork or unsecured-stratum you aren't a miner from the perspective of Bitcoin. You're just more or less blindly selling computing time to an untrusted third party (the pool) who is using it to mine.  If you were to call yourself a miner in that model we might as well say that AMD is a miner with 90% of the hashpower, declare bitcoin a failure, and go home. :)

The security of bitcoin really depends on this assumption that mining— real mining, not just people selling cpu cycles— will be _well_ distributed, and that the people running it will have a long term investment in bitcoin (e.g. mining hardware) that would be damaged by doing anything hostile like helping someone double spend. If it's not well distributed there is a lot of risk that attackers can take over bit chunks by hacking systems or holding guns to people's heads. If the miners are not invested in Bitcoin then they could get short term returns by maliciously mining. These risks exist even if they don't allow the attacker to get a majority hash power, "a lot" is enough to steal from people especially if combined with network isolation attacks (see the bitcoin paper on attack success probability as a function of hashrate). People hype "51%" but >50% is just when the attack success probability becomes 100% (assuming infinite attack duration). Especially with the subsidy down to 25 BTC a high value attack doesn't have to have high odds of success to be very profitable.

If these assumptions— that actual mining (validation) is distributed and the miners are economically motivated to be honest— is incorrect then bitcoins— and mining hardware— should be worthless.  

So, big centralized pools are a terrible thing for bitcoin. They violate the assumptions, and even if the poolops themselves are honest people (well, lots of people thought pirate was honest...) they are still an easy target for attack electronically or at gunpoint. But pools are easy and convenient and people are short-sighted and hope that someone else does the work to keep bitcoin secure while they just do the easiest thing.

For a while the core developers have been strongly encouraging people to mine using p2pool which solves these (and other) issues.  Luke's pool was already popular with the more-geeky crowd and it lost a number of big miners to P2pool.   Rather than denying the reality of the above serious concerns Luke looked for a way of combining the advantages— make mining that is as easy to use and as flexible in payout schemes as fully centralized pools, but not a danger to the Bitcoin ecosystem. He realized that the getmempool call that p2pool and other poolservers were already usng could be used by miners directly, allowing the miners to "trust but verify" and substantially limiting the attacks a malicious party controlling a pool could perform.

(Luke has also done some clever work in BFGminer to decrease the exposure even with getwork, for example it watches the previous block in the block header and prevents pools from asking you to mine a fork against blocks you previously mined. ... but getwork simply doesn't have enough information to do much better validity checks than that)

Con is a brilliant coder, by everyone's acknowledgement, but he's also a little bit coin operated. Luke can be difficult to deal with at times— but he's thinking long term and he's concerned with the future viability of Bitcoin for everyone.  When you delegate _Bitcoin's_ security to either Con or Luke, you might be delegating it to people smarter than you either way— but out of the two only in the case of Luke are you delegating it to someone who's actually demonstrated that they've thought mught about it or _care_ much about it.

People could debate if a centralized pool using GBT and users with BFGminer is "decenteralized" or not or GBT-mining's merit relative to p2pool. But debates over terms are boring, and a comparison to p2pool is somewhat apples to oranges (I say p2pool is more decentralized, especially since the poolops can still cheat miners out of payments in the non-p2pool options, and Luke argues with me).  What matters is that properly used GBT based mining can close many of the risks to Bitcoin of centralized pools. And fortunately slush was convinced with stratum to add extensions to pick up many of the same advantages.

Yes, getting extra data to validate the work takes some more bandwidth but all the bandwidths involved in mining (or bitcoin for that matter) are small. Because GBT style mining allowed massive bandwidth reductions for high speed miners many people had been just expecting people to switch to it and never notice the increases because they were paid ten times over by the improvement, but then slush showed up with stratum which had the efficiency but not (initially) the security improvements of GBT... In any case, the bandwidths involved are so small that they shouldn't be relevant to almost any miners (esp since they don't increase much with increased hashrate). It may be relevant to mining pools— but miners are paying for their services and ought to demand the best behavior for their long term future.

The whole post above is well argued. But I wanted to highlight just this fragment.
This is a standard dialectic argument used when software vendor tries to disparage software as a service (SaaS) vendor.

In this case we have Luke-Jr & gmaxwell as conventional software vendor. They hawk their complex software and the updates to it. Although the software is open-sourced it is so complex and obfuscated that only very few will be able to sensibly maintain it. The service component (PoW pooling) is pushed behind.

slush, ckolivas and kano together form a SaaS coalition. They hawk first of all their service and software part is the simplest possible required to relay the work that needs to be performed.

The "who's better" decision shouldn't be made on the bandwidth cost alone. The most rational discriminator is each miner's administrative overhead costs and skills. Simply speaking you the question you want to ask yourself is: Do I want to delve into programming, compiling and reinstalling every time I need to change rules in my mining operation?

Not the entire issue, that's just one important difference. GBT is also more flexible in terms of things like miners being able to manipulate the blocks they mine and pools being able to setup their own failover/load balancing. There's also GBT Full Node Optimization which I wasn't able to test since no miner implements it yet, which would enable miners to use their local bitcoind to cut down even more on bandwidth use without sacrificing network security.

It decentralizes the block creation. With every miner checking their blocks, a pool would be noticed trying to perform any attacks and miners could switch to another pool or (with BIP 23 Level 2 support) make blocks that aren't performing the attack.

Centralized vs decentralized lies in where the blocks are being created/controlled. With GBT, blocks are always ultimately controlled by the miner (there are some rules on what the miner can do, but this is necessarily part of any pool, centralized or not).

While I am the "BIP champion" of BIPs 22 and 23, the GBT protocol itself is the combined work of many authors over the course of 6 months in 2012. Adoptions isn't that bad (https://en.bitcoin.it/wiki/Getblocktemplate#For_miners), either.

Kano is, as usual, a liar. Ironically, he added a "Bytes Received" counter to cgminer git that significantly misreports bandwidth usage. I reported this to him, but apparently all he cares about is making GBT look bad.

Edit: When I posted the OP, I was actually expecting a "haha, I told you so" response from Kano. But seriously, he is extremely agreement-resistant.

Luke runs a service, though its not much of a money making service (as his pool doesn't take a cut of the subsidy).  I don't— but I don't earn a cent from working on Bitcoin (except for a few donations here and there— which I've had none in months).  I don't think this has squat to do with motivations, but if if you're looking to disparage _someone_ based on motivations you're looking at the wrong parties.

Bitcoin is a distributed and decentralized system.  You can make any distributed system non-distributed by just having some centralized parties run it.   If that is what you want— Paypal is a _ton_ more efficient— all this trustless distributed support has costs, you know—, and more carefully audited and trustworthy than basically _any_ centralized Bitcoin service.  I happen to think that Bitcoin is worth having, but only worth having if it offers something that more efficient options can't, without decentralization bitcoin is just a scheme for digicoin pump and dumpers to make a buck. So, looking out for Bitcoin's security is my only  motivation on this subject. People using GBT or verified stratum for mining against a centralized pool aren't even running any software I wrote, and they're certainly not paying me for it.

I'm quite happy that people provide services for Bitcoin, even though services have centralization risk. But in the community we should demand that things be run in a way which minimally undermines Bitcoin and we should reject the race to the bottom that would eventually leave us with something no better than a really byzantine implementation of paypal.

And yet this isn't a question anyone is forced to ask themselves, even P2Pool users. And at the same time, people on centralized mining setups still need to maintain their software (e.g. it was pretty halrious to watch big pools lose half their hashrate when phoenix just stopped submitting blocks at some difficulties)

Firstly, the example data is contrived and demonstrates nicely the confusion between technology and application. The test data does not demonstrate the bandwidth data difference intrinsic between stratum getwork and gbt, but the application of said technologies within luke-Jr's software within the constraints of his particular test. The intrinsic bandwidth requirements of each protocol can easily be calculated, and then I implore users who care about bandwidth to test it for themselves - with cgminer. Either using traditional tools or using the cgminer API  to get the results as Kano suggested.

Second what Kano is talking about when he says "transaction times", I believe he is referring to how often a block template for GBT, or a set of merkle branches for stratum, based on current queued transactions is being received by the mining software. If said template is sent once every 30 seconds on average by stratum, and received every 120 seconds on average by GBT, there are potentially 90 seconds more worth of transactions that never make it into the next block solve, in the way it's implemented in luke's software. In cgminer I receive the template every 30 seconds with GBT to match that of stratum. Only when the protocols are "equal" in terms of their likelihood of perpetuating transactions (since this is what bitcoin is about) should the bandwidth be compared. Pretending the bandwidth doesn't matter when one implementation can use over 100MB per hour is just naive.

Third, there has still not been any valid explanation for how sending the miner all the transactions in their entirety actually improves the security of the network. Unless someone is running mining software and a local bitcoin node and is comparing the values from each, and then decides what transactions overlap, and what are valid transactions the pool has chosen to filter out, and then determined that the data is enough of the transaction list to be a true set of transactions, having the transactions does not serve any purpose. Pool security validity software should be developed that does this, and people should use said approach if they care to confirm the pool is behaving. luke's software does not remotely do this to verify the transactions. It simply grabs them and then if it doesn't get them claims the pool is doing something untoward if it doesn't match the template. The transactions could be anything. It also completely ignores the fact that the vast majority of miners run their mining software on machines that aren't actually running bitcoin nodes with which to check the transactions. While the main bitcoin devs might wish this to be the case, it's not remotely the reality and is not going to become it.

We have a very suspicious community that will continually check the pools' actions. Yes history has shown pools may do something untoward - though it's usually about scamming miners with get rich quick schemes and not about harming the bitcoin network. If security was to be forced upon the miners by bitcoin itself, then a valid non-pooled mining solution should exist within the client itself that does not require people to have at least 1% of the network to be feasible. Solo mining is pointless for any sole entity any more. Unless bitcoin devs decide that something resembling p2pool makes its way into bitcoind, allowing miners of any size to mine, then pooled mining is here to stay. If or until that is the case, pooled mining is a proven solution that the miners have embraced. P2pool is great in principle but the reality is it is far from a simple plug in the values and mine scenario that miners use pools for. Pretending mining should be dissociated from bitcoin development just makes it even more the job of the pools to find solutions to mining problems as they arise. GBT failed to provide a solution early enough and efficient enough in the aspects that miners care about and stratum came around that was much more miner focussed. You can pretend that GBT is somehow superior but there isn't a single aspect that makes it attractive to miners or pool ops, and people are voting with their feet as predicted.

I understand your arguments, but I'm unable to reconcile them with your actions.

With your writing in English you are advocating distributed systems and heterogenous implementations.

With your code commits you reinforce centralization by marginalizing anyone who can't or doesn't want to use GCC and has implementation ideas differing from the ones you espouse.

The marginalization of Windows users and developers (like Casascius) is very glaring example: lots more people would contribute to the project if the core developers would actually download Microsoft Visual Studio Express, purge the code base from GNU-isms and made sure that all future changes developed on Linux don't break Visual Studio builds.

I don't disagree with you: decentralized project can be surreptitiously centralized by malicious (or incompetent) software as a service vendors.

But there is another avenue to such surreptitious centralization: a core development team that is full of "not invented here" and "our way or highway".

No disrespect intended for your thoughtful response, but this made me chuckle.  Deepbit was (is?) frequently attempting to mine forks of its own blocks. It's only Luke's paranoia code that caused anyone to actually notice it.  Look at what happened with with the BIP16 enforcement— discussed and announced months in advance there were popular pools that didn't update for it— for some (e.g. 50BTC) for a long as a month, and they kept hundreds of GH/s of mining during that time. A lot of malicious activity is indistinguishable from the normal sloppiness of Bitcoin services, and what does get caught takes hours (or weeks, months...) for people to widely notice much less respond to... an attack event can be over and done with far faster than that.

The only way to have any confidence that the centralized pools aren't single points of failure is making them so they aren't— so that most malicious activity cause miners to fall over to other pools that aren't misbehaving... but most of those checks can't be implemented without actually telling miners what work they're contributing to.   I'll leave it to Luke to point to the checks he currently implements and sees being implemented in the future.

So many possible responses… (1) You must have me confused with someone else— I write portable software. (2) show me this person who "can't" use GCC, (3) but not officially supporting VC is more about being conservative and making the software testable, especially since we have a significant shortage of testing resources, especially on windows (and Microsoft's standards conformance is lackluster to say the least)— that a compiler bug caused miscompilation that ate someone coin but it was fine on the compiler the tester used is little consolation. (4) Although you do seem to have me confused for your employee, as while I'm happy for you to use things I write I'm certainly not writing it to your specifications without a sizable paycheck. (5) But if you'd like to submit some clean portability fixes to the reference client I'll gladly review them (6) though having heterogeneous software is the direct opposite of people blindly copying code with so little attention that they can't bother to do a little work in their environment, so changes that have risk or complexity may not be worth it if they're only for the sake of helping forks and blind copying. (7) Finally, why have you made this entirely offtopic reply here? The thread is about protocols between pools and miners, and has basically nothing to do with the reference client not providing you with MSVC project files.

Pity that seems to have not been of importance to either you or your boss Luke-Jr

Um, why should GCC users be responsible for MSVS compatibility? The reason the codebase(s) aren't compatible is because there are no developers who want to deal with MSVS. Also, it's not like MSVS is free software - so you're asking free individuals to become less free (by agreeing to MSVS's terms) so that you can avoid using free software? I don't get it.

This is why I, and most other Bitcoin developers, work to improve standardization and make Bitcoin more friendly to multiple competing implementations maintained by different people. Remember that GBT is the standard developed by free cooperation of many different people with different projects, whereas stratum was the protocol developed behind closed doors by a single individual.

Of course I am agreement-resistant when you fudge the results.
I don't care if the results make you look good or bad.
Anyone who posts results that are rigged should expect a negative response from all but their lapdogs.

The "Bytes Received" counter is cgminer is simply what CURL tells us it has (sent and) received.

If you think there is some problem with that - then feel free to point out what it is - or go bug the CURL developers and tell them their code is wrong.

Simply saying it is wrong, oddly enough, doesn't mean much to me, coz I have had to deal with your blatant lies so often I take no credence in anything you say without clear proof.

Even though I do provide details of my arguments to you regularly, you usually provide none at all, so I certainly have no interest in your statements without any proof, since most of your arguments are clearly FUD.

No, you failed to read cURL's documentation, which describes what it actually does. cURL does not have a counter for bytes sent/received on the network.

You're projecting (http://en.wikipedia.org/wiki/Psychological_projection).

No it's not the same - YRI

Again read what you copied from me: "increasing" - yeah tricky word that.

As ckolivas pointed out above, yes I'm referring to how long you think work should be worked on before getting new work with possibly new transactions.

How long you have work determines exactly that, your effect on transaction confirm times.
Stratum on the original stratum pools and GBT in cgminer use the figure of 30s to decide when new work should be sent/received.
BarbieMiner GBT uses 120s (not 80s) thus his GBT increases it by 4x what cgminer does.

Note that while kano is correct that updating the template less often means a delay of the first confirmation of transactions sent in that time period, it's nowhere near the relevance he claims. The difference between 30 seconds and 120 seconds* is 90 seconds or a minute and a half. That's the extent of the confirmation delays as well. The fact that blocks can take that much time just to propagate the network makes it even less relevant. If "oh no, I sent my transaction 90 seconds too late!" is more of a concern to you than "oh no, someone double-spent to me and I'm scammed!" then I don't know what to say.

* No, he isn't right about stratum v GBT update times being 30/120 - that's entirely pool dependent really (and none I know of are as high as 120 in practice). I'm just using it as a worst-case example.

No, you failed (as usual you said nothing yet again) to state that your issue is that you may be compressing the data thus the network bytes may (or may not) be compressed.

However, if you bothered to read the curl documentation yourself, it says:

So ... yes I can add another counter for network bytes which MAY be different depending upon the pool and the compression options available.
I'll add it soon.

The current counter is still correct.

You're still hiding things.
Typical and common.
You know this depends on a number of settings, but don't want people to know that they may well still be sending and receiving 50x the data with GBT vs Stratum depending on those settings.

Lots of good discussion, and I love the flip-flop point-counterpoint going on here.


Anyone care to comment on this? We can argue about transaction times and network usage, but those are all trivial compared to this. The above issue has to be addressed first, and then the little stuff can be worked out (in whichever protocol and proper implementation of said protocol).

Or it could be admitted by the GBT zealots that anyone who can program can write a program to do exactly this without even needing the miner to do it.
It's just a few simple lines of code to hook a whole module to do whatever you like to hook into bitcoind to see what transactions are available and what transactions were put into each block.

Not only that, but doing this will easily point out all these imaginary evil pools that gmaxwell and his boss Luke-Jr say exist and make it blatantly simple to say that a pool is doing these nefarious things and thus anyone would have the simple proof to bring out the light of truth and salvation about these evil pools ... and then everyone mining on them would shout praise be to Luke for being the BTC saviour - everyone go crucify the saviour ... :P

However, there is also a complete and major fallacy with the idea that either of these methods will completely resolve any such security problem.
They both have the same problem of not knowing the list of transactions that any particular bitcoind contains ... ... ...

Stratum family of protocols was not developed behind closed doors. The development started right here with a lively discussion:

https://bitcointalk.org/index.php?topic=55842.0

From the very beginning it was ignored by the core development team because of its key features:

1) allows a clean break from the polling only (RPC) behaviour deeply embedded into the archotecture of the Satoshi's client.

2) shows a way forward that lies after abandoning the legacy of long-poll (one of the most horrible hacks in the Bitcoin millieu) and correctly using two-way transport ability of a single TCP/IP socket.

Those things must have been a complete cultural shock to the core development team: a protocol that not only acknowledges the essential asynchronicity of Bitcoin network, but exploits it to reduce the network resource usage.

I'm going to assume that developers still living in the world where everything has to be polled for will spare no means to try to disparage anyone from outside of their group.

Bitcoin is essentially asynchronous and anyone who tries to hide that fact is going to be working on a very bad software project. Completely asynchronous implementations like 0MQ or FIX are currently too advanced for an average Bitcoin implementer. Stratum is somewhere inbetween and is a way for the average Bitcoin implementer to learn modern software architecture.

Actually, I and a number of other people noticed that Deepbit was broken entirely by accident because it broke MPBM's code for detecting stale work every time it started mining two different forks.

I'm quoting in full just in case. In my experience the various attempts at disparaging Microsoft software stem from lack of understanding of its capabilities and the requirements it fulfills in many markets. Close to a half of bitcoind code is just a re-implementation of database (but not-really-a-database), of which multitute is available on Windows, together with the plentitude of available APIs. Probably close to a half of bitcoin-qt code is just a re-implementation of a data-bound control that are taught in the first semester of Visual Basic or C# or C++ programming.

I actually admire Gavin Andresen for willingness to simply admit that he's not familiar with various available database/financial APIs and learning them would detract him too much from the short term goals that he sees for Bitcoin.

Anyone can also note that various moral and ideaological opponents of Microsoft suddenly change their stance when talking about Apple. And Apple OSX/iOS is even worse prison-like-system than Microsoft Windows are.

But lets get back to the supposed superior security of the GBT and value that such security provides for Bitcoin. Lets look a the recent successfull double-spends agains SatoshiDICE losing bets. If the GBT was really security-oriented then we would've heard about this from many simultaneous GBT users. But we've heard about this voluntarily from the cheater himself. The list of would-be double-spenders would be freely circulated here on this forum.

I'm having trouble believing anyone who simultaneously claims that he has long-term financial security outlook but is oblivious to the attempts to abuse the protocol happening right now.

Combined with the above is the fact that you seem to pop up in every thread discussing alternate Bitcoin implementations and protocols and start disparaging their authors.

I don't know what are yours and Luke's goals, but I'm getting more and more convinced that they aren't the ones that you are openly defending here. There is a possibility that you are completely incorruptible like Felix Dzerzhinsky and you will show up in your armoured train anywhere you observe some counter-revolutionary activity that is trying to corrupt the ideals of the Bitcoin revolution.

Edit: I may be suffering from a case of mixed revolutions. Substitite Maximilien de Robespierre (http://en.wikipedia.org/wiki/Maximilien_de_Robespierre) and guillotine in the above paragraph.

+1

... and that would make signed binaries much easier too:

Bitcoin Signed Binaries (https://bitcointalk.org/index.php?topic=10471.0) (posted May 29, 2011, and STILL never been fixed because I can't be arsed to hack such things against a flaky mingw gcc build)

Edited to add:


Visual Studio Express 2012  (http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-products) ---> With Visual Studio Express tools, you can build the next great app for Windows 8, Windows Phone, and the web. Best thing about them? They’re entirely free.

^I'm pretty sure you don't agree with their definition of "free" though, so whatever LOL

Because they aren't free. If you want to sell your soul to Microsoft for it, go ahead and use their malware to sign your binaries yourself.

You seem to have messed up with the URL tag in that quote... I think it's cute so I'm quoting your error as-is.

---

Also, What?

I don't think microsoft or their compiler suite is malware (which somehow magically steals souls)... As a fact-respecting scientist, my usual baseline state don't involve a soul or other philosophical / religious / ethical / GNU baggage, so I'm not worried about this... uh... "philosophically / religiously non-free" distorted price which you speak of, and therefore, somehow different than "free of charge" (zero monetary cost) as most people understand the word...

---

As far as bandwidth goes, I'll stick with stratum, thanks though for helping prove that even your own implementation of stratum makes better sense than GBT...

Most miners / bitcoin users are probably:

1) windows users without "free license" GNU-ism baggage
2) not watching their mining software unless it stops working
3) not watching the contents of the transactions they're (blindly) verifying 24/7
4) not worried about your "philosophically / religiously non-free" dilemma, since most of their software is compiled using commercial compiler toolchains.

The logic would follow that most miners / bitcoin users don't care if your use of MSVC-compatible code will allegedly hurt their soul, or some sort of philosophical / religious / ethical / GNU-ism or other baggage with regard to how they mine or spend bitcoin... Stratum protocol is also acceptable for above-listed reasons 2 and 3...

OK thanks, carry on.

Quoth the wot,


Not an accident.

You've missed the point that a few of us have asked and been given no answer.

What does verifying the transactions do?

It verifies that the list of transactions provided by the pool ... matches the list of transactions in the block.
Well ... good to know ... but what does that do?
Nothing. There are no 'this is a bad transaction' checks anywhere.

Anyway, once a block is actually found - the list of transaction MUST exist for everyone on the bitcoin network to see or the block will be rejected.

So if people are concerned about mining transactions that some psychotic, religious nutcase thinks are damaging to bitcoin, then oddly enough those dangerous, damaging transactions will be known by everyone as soon as they land in a block.
... and then they can go rant about the pool that did it and lots of people will leave the pool.
If they never get in a block ... well aint that good :)

Though I will agree that this doesn't always work, there was this pool called Eligius that attacked an alt-coin with the pools hash power ... and also drastically restricted Bitcoin transactions for about 5 months ... and clearly stated that he was doing it in his pool thread ... that no one seemed to care about.

So ... basically ... even adding some 'this is an evil transaction' code into the miner, most likely it will have no effect anyway.
... and we'd also have some centralised 'authority' saying what is an 'evil' transaction ... ... ... ... ... but fortunately only centralised for those who used his holiness' cheap clone miner.

While this is semi-off-topic, I feel obligated to point out/clarify that Eligius (http://eligius.st) is under new management (https://bitcointalk.org/index.php?topic=23768.msg1291494#msg1291494).  ;D
There are not arbitrary limits on transaction count of block size in place.  The only thing of note in place regarding transactions, that is not part of the reference client, is the filtering of Satoshidice transactions, which means we simply do not include bets directed at Satoshidice in our blocks.  (For the record, this is publicly noted in the original post from when this was implemented here (https://bitcointalk.org/index.php?topic=23768.msg968819;topicseen#msg968819))  The decision to leave that particular piece of code in place was a personal one, as I do believe that SatoshiDice could use a much less wasteful method of doing business.  Passive aggressive vs SatoshiDice. ;)

Anyways, I think that having the transaction data available for miners to verify is worthwhile.  While the software to actually allow any real verification of this data, aside from validating it against what the pool is asking be hashed, is in it's infancy, I think it has potential to help secure the network even more by allowing miners to choose to allow their software to check their transaction list against their own bitcoind's transaction list, note any major issues, transactions that would not be accepted by a standard client, etc.

Obviously not every single miner is interested in doing this, and I'm reasonably certain no one has ever said otherwise.  But, it would not be a bad thing IF every miner were.

----

In any case, this thread is about the bandwidth use of the various mining protocols.

So far, through my own testing, my number's concur with the OP's to within an acceptable margin for error. (No discrepancy sufficient enough to change the order of most to least usage).

I however, do not see any real performance differences between the protocols as far as pool-side accepted shares over time, so, as far as I'm concerned, the bandwidth usage is a moot issue since I would venture to guess that majority of miners are using residential internet connections which are generally unmetered, and even the worst protocol bandwidth-wise (secure stratum) does not use a substantial amount of bandwidth, averaging about 36kbit/sec... and the cheapest broadband connection available in my area is 1500 kbit/sec. So, I think bandwidth usage is a moot issue for mining, especially considering these are non-vardiff tests too.

Have fun, try to stay on topic here...

-wk

As I stated in here before, any test that expects 2 bitcoind's to have the same transaction list is naive and will fail.
If a pool restarts it's bitcoind, the memory pool is empty ...
If you restart your bitcoind, the memory pool is empty ...


I'll reply to your other comment later ... since it's better to supply numbers rather than make vague sweeping statements like you have.
The cgminer API reports those numbers so it's easy to see what they are ... rather than just say something without proof.

Edit: though I will point out that after I added the extra 'network' byte counter to cgminer, I went and looked at the clone code ... and noticed he was ignoring some data ....................
Here's a clue (that he obviously didn't have one of :P)
https://github.com/bagder/curl/blob/master/src/tool_cb_dbg.c

Of course, as you already know (since I reported it to you), cgminer's counters lie about bandwidth usage. And since you haven't reported any bug to me, you have nobody to blame for that but yourself - IF it's true (which I doubt, since you're not competent and I did in fact read the code you referenced).

Well I've pointed out the problem and you've ignored it.
To be expected. Nothing new. Source code in front of your face is too difficult for you to understand ...

cgminer doesn't lie about the byte count, it is the correct byte count transferred.
The old version just didn't report the network byte count which can, of course, be different to the data content byte count transferred, if the data is being compressed.
What you didn't bother to point out to the fools who believe you, is that will depend on the pool ...

I've also concluded that, for whatever reason, cgminer does not correctly report bandwidth usage consistent with usage reported by sniffing data directly on the box in question between the pool and box, which is the method I personally used for my tests.  I have several GB of PCAP to back up my "vague sweeping statements".  However, I find it wasteful to post all of that raw data when a summary of the findings is all that is needed.

Also, the new "E" that calculates bandwidth usage in bfgminer as a measure of number of shares per 2KB was in fact accurate to within 1% of my PCAP data. My assumption is that I'm including some packet header data that "E" is not, which would account for the error mostly.

cgminer's counters however almost never matched my PCAP data, being off by huge margins that I could not logically account for, thus I deemed that particular output from the miner useless.

After disabling gzip in bfgminer, both cgminer and bfgminer yield statistically identical results for bandwidth usage for all protocols supported by both softwares.  With gzip compression enabled in bfgminer code, bfgminer, obviously, uses less bandwidth.

All long tests were done against eloipool, and some shorter comparison tests done against various other pools with expected results.

Loser ... using the version of cgminer that doesn't have the change to include the Network byte count ... D'oh
If you are going to make comments about cgminer - then do that when you know what you are talking about.

Anyway, the clone is ignoring data in certain circumstances ... as per that code from the curl developers shows ... that clearly both of you are too dumb to even notice the problem when I stick the code in front of you - lulz.

Meanwhile ... a run log ...

http://207.36.180.49/run666.gif

And anyone wanting to generate that with a customsummarypage in miner.php
... and of course you add this to your list of customsummarypages:
'Proto' => array($protopage, $protosum, $protoext)

I'm pretty sure looking any code is not even necessary considering I'm using PCAP data for my tallies. Learn to read.

Second, it's good to know that you're psychic now and know what version of the software I'm using without even Asking! I'll keep that in mind on my next trip to Vegas.

Edit to clarify: PCAP data matches bfgminers bandwidth efficiency number, while no cgminer api output from any version to date matches. Feel free to run a capture and run the numbers on your own if you don't believe me.

i.e. you are not running the latest cgminer version fool.
See, when you don't even take any notice of what is going on with cgminer and only stare into your master's eyes and at your masters crappy clone (as to be expected by the sock puppet you are), don't show your stupidity by assuming you know what you are talking about cgminer, coz you are wrong.
As per my screen, it does indeed.
The code has been there for 4 days.

Though I will repeat what I said above since clearly your ability to read is deficient:

Edit: I'll even add the picture again - since words are too difficult for a sock puppet to understand
http://207.36.180.49/run666.gif

Again, must be psychic. A bad psychic at that. How would I be able to compare PCAP data to your outputs if I wasn't running the code which output the data? Are you really that thick?

And also, do, oh wise one, explain to me how bfgminer's numbers match near perfectly with the PCAP data, yet the as-of-last-night-version of cgminer's api output does not? If there was in fact data being ignored in bfgminer as you claim, then would that not show in a comparison against PCAP data? (I assume kano won't actually try to answer this... wagers?)

You are not running the latest code if you are not seeing the network numbers ... the old code (as I ALREADY said in here quite a while ago) shows the data byte count, not the network byte count ... and ... as I ALREADY stated in this thread ... I would add the network numbers at a later date.
That change is there and has been for 4 days.
You're probably even looking at the wrong git.

... and of course you've again shown your stupidity.

Will I have to redo the words at 2nd grade level for the moron?
I'll quote them yet again just in case a few extra times sinks in:

The data being ignored is the SSL data - as the example code I linked clearly shows and the cgminer clone code ignores.
No idea why you are unable to spot that damn obvious point in the code there even after being told about it.
My code includes all 6 cases of data, the cgminer clone only includes 4 of them - it ignores the 2 SSL cases that only a halfwit would not be able to see looking at the code supplied by the Curl developers.

I'm not sure how you magically worked out, that when my code has EXTRA cases that the clone is missing, that I am actually getting the wrong answer.
I wrote my code based on the Curl developers code and thus got it correct.
I've no idea where on earth you got the fail code for the cgminer clone.

In my testing I am not using SSL, so it makes no difference to my numbers.
In your testing, if you are using SSL then you are getting the WRONG answer from the cgminer clone.
For anyone who IS using SSL and the clone miner, they will get the wrong answer.
Yeah I know that's not everyone, but when you write code, it's a good idea to get to work in all cases ... and viewing the Curl developers code has a much better chance of getting the right answer than thinking you are always correct when you often aren't :P

Sigh.

... and then they slink away into the darkness coz they don't want anyone to think that they could be wrong about anything.

So just to clarify in case anyone was wondering where the code is that was committed 4 days ago:

https://github.com/kanoi/cgminer/commit/d3d8772b5ea1d29e6bf8e724fb9a2e662db30c19

... and anyone wondering why my git ... for anyone who bothers to keep track of what is going on with cgminer at the moment ...

https://bitcointalk.org/index.php?topic=28402.msg1427509#msg1427509

(Posting delayed by useless IRC conversation)


When did I ever say I was not seeing the network numbers?  Please quote me on that one.


So much hate... and I thought we had some love....

... well, maybe not... but anyway.  ;D


Well, I'll start by pointing out that mining over SSL is a feature that is pretty useless anyway IMO... why waste resources encrypting/decrypting data that is essentially public knowldege already anyway?
that has no bearing on my tests. I stated that the majority of my testing was done against eloipool, which does not support SSL.


So, I obviously never tested that.  And that is also irrelevant to the data, since you said youself bfgminer has the non-SSL cases handled.

I will, however, rerun my longer PCAP tests against your network-bytes code instead of testing it for a short time (since it is newer than the beginning of my tests), to see how it goes with cgminer.

I shall report back soon!

My last post (I'm referring to) was about 9 hours ago ...

... majority ...

I'm not sure how I'm supposed to know that "other pools" don't allow SSL ...

... and ignoring SSL means that if some "other pool" does support SSL, then the code will ignore the SSL data in the count.

Yeah I know I keep repeating it ... but I hope for it to eventually sink in ...

To clarify even more, I've re-skimmed my PCAP data and no data was encrypted on any pool I tested with.
So, even if bfgminer code does not account for SSL data usage, its still as irrelevant to my testing as it was many posts ago.

... and to clarify even more ... your testing is therefore ignoring a case that the clone miner you were testing was also ignoring.

So yes the fact that neither the original cgminer, or the clone were being tested on SSL pools does not in any way negate the fact that the clone code ignores data ... SSL data ... that may or may not be used by the pools.

The silliest thing about this, is that it is only 2 lines of code to support the SSL data ... and even simpler, those 2 lines are just 2 extra case lines.

Kano says......


I have just about had enough of your tone Kano.
I know you have issues with LJR, but FFS, can you be a little less sarcastic and downright NASTY with your posts.

You are seriously putting me of browsing this forum.

You think you are smart, and you probably are (I say probably because of your bitchy low I.Q. attitude).

I think I will have to put you on ignore, because you are just annoying.

I generally have respect and admiration for coders / programmers, but for you sir, I have none. ::)

Put me on ignore ... please :)

... and with his latest release Luke-Jr has added the SSL code lines.

And ironically, that still doesn't fix it. I did add it, because it gets a little closer, but it is currently impossible to get the real number from libcurl when SSL is in use. Good thing SSL is still useless for mining.

Ok... maybe I am misunderstanding things, but why do we want to encrypt miner traffic? 

At this point in time - probably no one wants to.

However, should any pool enable that, the miners will also currently talk SSL (Curl does that)

The point being that the counters should include the SSL count if any pool uses SSL (which may or may not ever happen)

The cost of including the count is almost zero if there is no SSL data, and pretty close to the same as the cost of counting normal data if instead a pool is using SSL.

... and an aside but related comment ... :)
My desktop cgminer on a 3.6GH/s Bulldozer uses about 1CPU second per hour OzCoin Stratum mining (at 8 difficulty) on my BFL FPGA :)
Runtime: 15hrs, 13minutes ...
Top CPU seconds TIME+: 0:15.79
I will also point out that I am also doing an API request to it (summary) every 2 seconds

Edit: and in retrospect, I would guess those numbers might be of great interest to you Inaba once you get the MiniRig SC's working ...

Is there a simple formula us plebs can use to calculate bandwidth given current difficulty, rig hash rate etc?

... use cgminer and look at the API pool stats ...
The API 'stats' command - the last 6 numbers on each pool :)

Calculation will depend on if you are using cgminer or not and which protocol you are using.
The least will be cgminer with stratum.
The clone asks for a large amount of transaction data that it doesn't do anything useful with even in stratum
(and asks for that same data sometimes more than once)
The size of that transaction data is in the order of the size of the block.

And the pool you are mining on may have block size restrictions also e.g. Eligius used to limit every block to 32 transactions for about 5 months so they would be paid more for their work since they seemed to think their pool should be paid more than other pools for the same amount of work - though the real problem was simply that the pool software was crap and got more orphans than the other much better pools.

It varies by pool mainly. Pools that support variable difficulty should use approximately the same bandwidth regardless of hashrate.
Network difficulty has no effect on bandwidth.

Ignore the troll.

Actually a lot of what Kano said is true, specifically this:


If you're looking for the absolute least amount of network traffic, CGMiner's implementation of Stratum is the best.

Not really.. you can degrade BFGMiner's stratum security with the --skip-security-checks parameter.

Yet again you fine gentlemen have overestimated my competence.

Lets say I have a 2 Th (2,000 Gh) rig, and I need to tell the server collocation host how much bandwidth I think I'm going to use per month, what is the extreme upper limit of the standard deviation?

FUD as usual.
You have never given any credence to your use of the word security in that context.

I came up with 205 KB/sec, or 18 GB/day at the extreme case of difficulty 1 shares with full 1 MB block templates every 30 seconds.
In practice, 2 Th/s would probably be unusable at difficulty 1, so you would be using a variable difficulty pool which would use less bandwidth for submissions (which account for about 134 KB/sec of this estimate).

Surely you jest. Are you sure that's not 18 GB/MONTH?

No, that's the unrealistic extreme upper limit. There is no upper limit besides that.
For a datacenter, 558 GB/mo is nothing anyway. The very cheapest of dedicated servers include 2500 GB.

So 205kB/sec is the absolute upper limit. We could easily get that down to half that with varr diff, so you're only talking about 9GB/day. I'm gonna guess that most people mining do not work in a datacenter, and have limits on their internet connection. For example, my family has a 500B cap per month. We've been over that cap for the past 20 months in a row, and they've stopped sending us letters or even caring, so it is what it is.

I'll remind all those places that offer less than 2.5TB/month that they don't exist ...
Gonna take me a while ...

So is mining over a cellular modem connection basically impossible due to it's bandwidth usage/cost?

Use stratum with higher difficulty.
You receive on average one (small) work item per 30s (depending on the pool) + LP and send shares back at your difficulty.
Ozcoin allows you to set your difficulty for each worker.

Thanks.  I might be granted access to a location with free power (hydro) but it's off the grid and has no internet.  There is 4G cell service tho.  Didn't know if it's feasible to set up some miners over a cell connection without using hoards and hoards of expensive data.