indicates that BTC Guild's percent of orphaned blocks was 1.3%. Since BTCG pays for orphaned blocks, am I correct in thinking that this effectively reduces the 3% transaction fee to 1.7% (not considering other factors that reduce the fee further)?

1.3% is slightly above normal for BTC Guild. I always use 1% as the rule of thumb for orphans. So compared to other pools which do not pay orphans, it is effectively a 2% fee for BTC Guild. Less if the other pool fails to pay transaction fees or namecoins.

email conversation with Organofcorti

Quote

>I think including orphans in the calculations would be a mistake. For example in Giga's last week of operation it had 2 orphans. If they were included the calculations would have been horribly skewed. Better to include stale/orphans in a separate column.

I understand where you're coming from, but there are a couple of things that need to be taken into account.1.The "luck" calculation is based on the number of shares per solved block - not shares per block accepted by the network. 2. Orphaned blocks should be assessed separately, but I haven't found a reliable way to do that yet. I can simply report the number of orphans, but that doesn't tell anyone whether that is too many or too few or expected due to variance.3. I would like to report average earnings (which would take orphaned blocks into account) but the various reward methods make this problematic.

So when looking at the luck of a pool that does not pay for orphans, stale/orphaned/rejected blocks will negatively impact earnings but these rejects are still counted in the luck calculation making it artificially high

>I think including orphans in the calculations would be a mistake. For example in Giga's last week of operation it had 2 orphans. If they were included the calculations would have been horribly skewed. Better to include stale/orphans in a separate column.

I understand where you're coming from, but there are a couple of things that need to be taken into account.1.The "luck" calculation is based on the number of shares per solved block - not shares per block accepted by the network. 2. Orphaned blocks should be assessed separately, but I haven't found a reliable way to do that yet. I can simply report the number of orphans, but that doesn't tell anyone whether that is too many or too few or expected due to variance.3. I would like to report average earnings (which would take orphaned blocks into account) but the various reward methods make this problematic.

So when looking at the luck of a pool that does not pay for orphans, stale/orphaned/rejected blocks will negatively impact earnings but these rejects are still counted in the luck calculation making it artificially high

"Luck" in bitcoin mining is an Erlang distributed variable. For one block, the canonical "luck" calculation is defined as submitted shares / expected shares. The calculation cares not one whit whether or not the solved block is valid or not. If orphaned blocks were not included, the luck calculation would be artificially low. Orphaned blocks have no affect on how luck is calculated. If orphaned blocks were not included, expected shares / accepted shares would no longer be Erlang distributed, and "luck" calculations averaging more than one block could not be made.

So instead, I'm using the "bitcoin per gigashare" metric as a measure of income that includes the effect of both luck and orphaned blocks. Reward method effects and fees are not included.

Summary: If you want to look at the canonical luck (the Erlang distributed average of submitted shares / expected shares) look at the "luck" column. If you want to see the effect of both "luck" and orphaned blocks, look at the "bitcoin per gigashare" column.

BTW, the comments in the private email above were about the old table. The quoted table is one of the new tables which I developed after taking on board your input.

When is additional merged mining coming? I remember end of January was said.

No date was ever given for DVC/IXC, only that they would come *after* the new backend and after Scrypt Guild. Unfortunately, the new backend took much longer than expected (illness + bugs), and was eventually scrapped entirely. As a result, Scrypt Guild is also pushed back further.

IXC and DVC are *completely* worthless. If BTC Guild adds them, they'll just become twice as hard to mine from difficulty, and go even further down in value since you'll have a whole lot of new people selling them to the highest bid on the books. Right now they add less than 0.2%. If their difficulty was increased by BTC Guild's hash rate, it would be less than 0.1%, not counting the drop in value guaranteed to follow the rise in difficulty.

This isn't saying they won't be added, just that they have always been near the bottom of the list of things to add/consider adding.

Actually im about 90% sure you said January but I dont have time to look for the post(s) now. Not a big deal anyway as you pointed out.

"Luck" in bitcoin mining is an Erlang distributed variable. For one block, the canonical "luck" calculation is defined as submitted shares / expected shares. The calculation cares not one whit whether or not the solved block is valid or not. If orphaned blocks were not included, the luck calculation would be artificially low. Orphaned blocks have no affect on how luck is calculated. If orphaned blocks were not included, expected shares / accepted shares would no longer be Erlang distributed, and "luck" calculations averaging more than one block could not be made.

So instead, I'm using the "bitcoin per gigashare" metric as a measure of income that includes the effect of both luck and orphaned blocks. Reward method effects and fees are not included.

Summary: If you want to look at the canonical luck (the Erlang distributed average of submitted shares / expected shares) look at the "luck" column. If you want to see the effect of both "luck" and orphaned blocks, look at the "bitcoin per gigashare" column.

BTW, the comments in the private email above were about the old table. The quoted table is one of the new tables which I developed after taking on board your input.

This is only somewhat related, but have you thought of doing any kind of statistical analysis on the block timing distribution in relation to orphans? Specifically I'm thinking of GHash.io, and their relatively common (though it seems less frequent now) runs of 2 or 3 blocks in the span of a minute. They seem to be involved with orphaned blocks more often than most (or at least the grumblings about them are).You'd expect more short rounds and clusters of them just because of the shape of the CDF, and observations just glancing at blockchain.info every once in awhile are obviously subject to huge reporting bias, but a lot of people seem to complain about GHash doing a withholding attack.I think it'd be interesting to get a comparison of block finding time for the different major pools, though I have no idea what type of distribution you'd expect around their average generation time.

Question, would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

My original number was much higher bu I lowered it for the purpose of this question. My thoughts on this could be way off but I seem to verage around 442 shares per round and I'm running 2 335Mh/s ASICs.

I will be getting 600Gh/s soon I hope. That said, I took that 442 and divided it by the two ASICs I have and figured I'd probably get around 221 per 335Mh/s. I then took the 600Gh/s figure and divided it 335Mh/s and got 1,791. I then took that number and times it by the 221 and got 395,811 which I then lowered as a guess to the 380,000.

So ya, I could be way the hell off on this, but for shits n giggles can anyone answer the question which I pose again below >

Would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

Question, would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

My original number was much higher bu I lowered it for the purpose of this question. My thoughts on this could be way off but I seem to verage around 442 shares per round and I'm running 2 335Mh/s ASICs.

I will be getting 600Gh/s soon I hope. That said, I took that 442 and divided it by the two ASICs I have and figured I'd probably get around 221 per 335Mh/s. I then took the 600Gh/s figure and divided it 335Mh/s and got 1,791. I then took that number and times it by the 221 and got 395,811 which I then lowered as a guess to the 380,000.

So ya, I could be way the hell off on this, but for shits n giggles can anyone answer the question which I pose again below >

Would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

Question, would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

My original number was much higher bu I lowered it for the purpose of this question. My thoughts on this could be way off but I seem to verage around 442 shares per round and I'm running 2 335Mh/s ASICs.

I will be getting 600Gh/s soon I hope. That said, I took that 442 and divided it by the two ASICs I have and figured I'd probably get around 221 per 335Mh/s. I then took the 600Gh/s figure and divided it 335Mh/s and got 1,791. I then took that number and times it by the 221 and got 395,811 which I then lowered as a guess to the 380,000.

So ya, I could be way the hell off on this, but for shits n giggles can anyone answer the question which I pose again below >

Would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

See, that was my thought too... but how accurate can calcs really be ? I mean what you make can for lak o a better thought be based on where you sit on the totem pole. Ex, someone has 22Th will make less than a guy with 30Th.

Question, would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?My original number was much higher bu I lowered it for the purpose of this question. My thoughts on this could be way off but I seem to verage around 442 shares per round and I'm running 2 335Mh/s ASICs.I will be getting 600Gh/s soon I hope. That said, I took that 442 and divided it by the two ASICs I have and figured I'd probably get around 221 per 335Mh/s. I then took the 600Gh/s figure and divided it 335Mh/s and got 1,791. I then took that number and times it by the 221 and got 395,811 which I then lowered as a guess to the 380,000.So ya, I could be way the hell off on this, but for shits n giggles can anyone answer the question which I pose again below >Would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

See, that was my thought too... but how accurate can calcs really be ? I mean what you make can for lak o a better thought be based on where you sit on the totem pole. Ex, someone has 22Th will make less than a guy with 30Th.

At 10gh it says I should be making about .0023 BTC per day...which I do.

EDIT: But that calc is based on no variance or luck, and being on this pool there is some variance and luck involved, so my daily take is +- 15%

Question, would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?My original number was much higher bu I lowered it for the purpose of this question. My thoughts on this could be way off but I seem to verage around 442 shares per round and I'm running 2 335Mh/s ASICs.I will be getting 600Gh/s soon I hope. That said, I took that 442 and divided it by the two ASICs I have and figured I'd probably get around 221 per 335Mh/s. I then took the 600Gh/s figure and divided it 335Mh/s and got 1,791. I then took that number and times it by the 221 and got 395,811 which I then lowered as a guess to the 380,000.So ya, I could be way the hell off on this, but for shits n giggles can anyone answer the question which I pose again below >Would it be possible to estimate a perday earning under curren dificulty... assuming that for all rounds I submitted approx 380,000 shares ?

See, that was my thought too... but how accurate can calcs really be ? I mean what you make can for lak o a better thought be based on where you sit on the totem pole. Ex, someone has 22Th will make less than a guy with 30Th.

At 10gh it says I should be making about .0023 BTC per day...which I do.

Wih the 670Mh/s I aevrage it says 0.0002 but it's more like 0.00014. Not complaining because there's going o always be variance.

That said, that calcs diff from the one I usually use so can you help me understand what this is asking ?

The time frame is "How long at this difficulty do you want to calculate mining income". I usually do a month to get a rough idea, but in reality, the best place to go is mining.thegenesisblock.com. That way you can put in all your factors, like cost of hardware, pool fees, cost of electric, etc and see just how much you can possibly make during a given time frame, when you'll break even, and when you'll start losing money: Here's a link for 600 GH/s (assuming Monarch and delivery in a few months)...

The time frame is "How long at this difficulty do you want to calculate mining income". I usually do a month to get a rough idea, but in reality, the best place to go is mining.thegenesisblock.com. That way you can put in all your factors, like cost of hardware, pool fees, cost of electric, etc and see just how much you can possibly make during a given time frame, when you'll break even, and when you'll start losing money: Here's a link for 600 GH/s (assuming Monarch and delivery in a few months)...

Thx, will chck that out but FWIW, it's Black Arrow. Just got this bit if shit news with a slightly neat twist.

Quote

Dear XXX,

We have to inform you that our schedule to manufacture and assemble the system has been disrupted and we are unable to make delivery of the Batch 1 Minion ASIC chip on the initial scheduled date (end of February). We are now expecting to dispatch all Batch 1 orders on 1st of May 2014.

Please be re-assured we are confident that we have tried our best to accomplish our initial ambitious targets. However, we came to the conclusion that it is in the best interest of our customers to delay shipping in order to ensure that the product provides the best-possible user experience.

Without this delay we would have achieved 1.5W/Ghash which would have meant that our chip would not have been competitive at all.

We have now finalized the design process using our newly improved code and will start manufacturing the chip (tape out) in the next few days.

We are happy to announce that Black Arrow Software’s products remain on target for being the best in their class for power consumption. We confirm that our latest improved design has the following technical specifications:

·0.75w/Ghash on TT corner @ 25C which is expected to run at 120Ghash/sec.

·SS corner will be 0.6w/ghash and will run at 100Ghash.

·A further underclocking and underpower should be possible and should yield 80Ghash @ 0.5W/ghash. However, please note that this is not guaranteed to work stable.

Please note, that a further push for improvement in the optimization process would have guaranteed further delays for at least 1-2 months.

It is no secret to us that the Bitcoin mining process is proving to be more and more difficult every day. To compensate our loyal customer for the unforeseen delay of in delivering our miners for batch 1, we are happy to offer free extra hashing power which consists of 25% of your purchased hashing power from our Rent-Some-Minions cloud program for 4 months.

The account for the tape-out has been settled in full and we are confident that the delivery will be completed shortly.

We are taking all the necessary measures and positive actions to expedite delivery to you as soon possible and we are confident that we have the resources to be successful.

Please note:

·We estimate that the delivery for the Batch1 will coincide with the delivery of the Batch2

·The delivery of Batch2 remains unchanged

·The one-off offer presented above is open to the customers who placed orders for Batch1

Sincerely,

The Black Arrow Software Team

So instead of a early March delivery, it's now suspected to be May... so that only screws me even more. Either way my cost was low so I should still be able o break even anywhere from 2-4 months if the May delivery holds up then its just a matter of thee electricity which righ now is $0.09kWh.

I do however like the idea of 150Gh/s for four months free. I did send a tikect though asking if I could opt for another X1 instead since the cost to them would actually be lower and benefit me in he long run.

150Gh for four months compard to 100Gh forever.

So if nothing else I mine at 750Gh for four months then drop to the 600 I will get out of the 6 X1's I ordered.

http://www.alloscomp.com/bitcoin/calculator is the calculator I've always recommended for hard numbers at current difficulty, which is the only hard number you can be given. I don't have a calculator on the pool because I believe it is misleading for non-PPS users, since pool luck will skew results one way or another, just confusing most users.

The expected earnings per day of any miner on any pool is based on their speed vs the current network difficulty. This number is then skewed mostly by pool luck, and then somewhat by pool payout method depending on the method and the configuration. For BTC Guild's PPLNS, the payment method itself has virtually no variance impact due to an 'N' value in PPLNS that is obscenely high (> 10x difficulty). The only variance you're likely to see is entirely based on the pool's luck.

The speed of the pool only acts as a limiter, establishing a likely floor and likely ceiling of how far luck/variance can swing over a given period. You'll have highs and lows, but a pool the size of BTC Guild experiences "extremely poor luck" as a day at 63% expectation. In smaller pools, that would be "normal" bad luck, with extremely bad luck being something closer to 10-20% expectation. If it's really small, possibly even 0% if they fail to find a block all day. With that benefit comes the downside, which is BTC Guild is unable to hit the extremely good luck values that small pools have. BTC Guild's very good days would be 130-140%, our highest 24-hours I can remember was a hair under 150%. A smaller pool can see numbers as high as 300-500% in a 24-hour period, it just takes a handful of blocks.

ScryptGuild alpha is tentatively scheduled to start on Friday. After encountering a number of setbacks from code I wrote while sick (always seems like a good idea at the time), I've fixed the problems that prevented the launch last week. Some family is visiting this week, so I'm holding off on launch until the weekend. As such, the alpha will probably look much nicer than originally planned.

ScryptGuild alpha is tentatively scheduled to start on Friday. After encountering a number of setbacks from code I wrote while sick (always seems like a good idea at the time), I've fixed the problems that prevented the launch last week. Some family is visiting this week, so I'm holding off on launch until the weekend. As such, the alpha will probably look much nicer than originally planned.

ScryptGuild alpha is tentatively scheduled to start on Friday. After encountering a number of setbacks from code I wrote while sick (always seems like a good idea at the time), I've fixed the problems that prevented the launch last week. Some family is visiting this week, so I'm holding off on launch until the weekend. As such, the alpha will probably look much nicer than originally planned.

Cant wait to point my miners to scrypt guild.

I was just so relieved last night when I finally figured out where that stupid bug was. I was getting so desperate to get ScryptGuild moving that I was almost considering using that crappy MPOS package most the pools use these days for using with slush's python stratum pool.

Alpha will be fairly basic. It will be PPLNS, 0% fee during alpha (pool keeps the meager txfees). At launch it will be manual coin selection by picking a port (probably LTC + Doge +...maybe Moon?). While that's up and running, I'll be working on another update to the backend to allow multiple chains on the same port, with website (and API) based controls to swap a user between chains. That will be 'Beta' stage. Final stage will include the ability to opt in to automatic chain switching based on estimated profitability.

I think users will enjoy the layout for the new ScryptGuild. It will NOT look like BTC Guild, since I've determined the BTC Guild interface would not be very efficient when working with potentially dozens of different coin chains. But it also won't be something you've seen on any other pool to date .

On ScriptGuild are we going to need wallets for each PnD coin or are you handling the conversion and paying out in BTC?

At least to start, ScryptGuild will not do *any* form of transferring between currencies. So you'd have to either run your own wallets, or set the payouts to an exchange like BTC-e or Cryptsy. There will eventually be an instant conversion option on ScryptGuild, probably only to LTC though (since it's ScryptGuild), which uses market rates + small fee, depending on how reliable the exchange APIs are for scrypt coins.

No teasers yet, but the website will probably be functional *before* Friday for setting up accounts and workers. I've purchased a nice template to start off with, I just need to take a little time to customize it and start replacing demo data with proper placeholders.