[9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining

[doublec]

Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful ) and the pool finds a block that is later orphaned, the payments of the next valid block will be lower than they would be if the orphaned block never existed.

The effect of the payments of the next valid block will depend on if the orphan block is short or long. In the longer term this effect is minimized and the the general cost to the miner is the percentage of orphan blocks the pool gets.

According to Meni Rosenfeld, the DGM creator, the scores should not be adjusted if an orphan occurs. There's a discussion in the DGM thread about this and you should raise any questions you have there. Here's what Meni says:

I can see why it is intuitive to treat orphaned block as if they never happened - thus cancelling S=S*o - but the method invariant is based on the assumption that a share has a probability of d/D to be a block. If orphans exist this is no longer the case, shares actually have a lower chance of becoming a valid block. If orphans are ignored completely, the operator will pay out more than he should (the block rewards he actually receives are lower than the method assumes). I've done the math and if you simply cancel the payment specified for the orphan blocks, everything is just right. This assumes, however, that every block, once received by the pool, has the same chance to become an orphan.

And later in the thread:

Shares submitted after the orphan will be worth more than those submitted before, and this is proper.

The orphan did happen and this is information that needs to be taken into account. The orphan blocks are not in addition to the valid blocks - they are instead, some of the blocks which should have been valid end up orphans instead. The correct comparison is not orphan vs. no block, but rather orphan vs. valid block.

When a block is found, all past shares have a chance to get a payday if it ends up valid. The cost of this chance at payment is the score reduction - even if, contingently, it ends up an orphan. Later shares never had a chance to profit from the block, and thus don't get their scores reduced for it.

This is similar to the situation with shares in general in a pool - when you submit a share, you are rewarded even if the particular share was of no use, because in finding a share you had a chance to benefit the pool - and you get an expected reward equal to your expected contribution.

It would be nice to have a method that could adjust for orphan blocks and 'make up' payment for them but it's not possible since we can't predict the probability of a block accurately in the presence of orphans. The pool doesn't have a way to 'make up' the cost of orphans and pass that on to miners, other than increasing the fee to approximate the orphan rate. From what I can tell users prefer losing out on orphans but paying a lower fee.

[matt4054]

Yes, I would be fine with just cancelling the payout triggered by the orphan block, but if the orphan is late and the money is already withdrawn, it will have a side effect. I will compare it to what happened when the dividend for TAT-ASICMINER went paid in double. Those who withdrew early, before the correction, have got away with it (it was on burnside's expenses in the end), while those who left the funds on their account saw it taken back.

Wouldn't it be the same here? Even if you put the balance in negative, aren't you afraid that you'll be paying for "smart boys" who just recreate a new account when they have a negative balance?

In other terms, would this method require delaying payments? That would be ok for me...

[redtwitz]

According to Meni Rosenfeld, the DGM creator, the scores should not be adjusted if an orphan occurs. There's a discussion in the DGM thread about this and you should raise any questions you have there. Here's what Meni says:

I can see why it is intuitive to treat orphaned block as if they never happened - thus cancelling S=S*o - but the method invariant is based on the assumption that a share has a probability of d/D to be a block. If orphans exist this is no longer the case, shares actually have a lower chance of becoming a valid block. If orphans are ignored completely, the operator will pay out more than he should (the block rewards he actually receives are lower than the method assumes). I've done the math and if you simply cancel the payment specified for the orphan blocks, everything is just right. This assumes, however, that every block, once received by the pool, has the same chance to become an orphan.

I hadn't thought of it that way. Yes, if every block has the same chance of becoming an orphan, every miner will lose exactly his fair share on average.

[doublec]

In other terms, would this method require delaying payments? That would be ok for me...

Right, the payment would be delayed 3 confirmations or so to confirm the block isn't orphaned.

[doublec]

Pool will be going down in 10 minutes or so for updates. It should be up approximately 10 minutes later.

Edit: Pool is back up and the orphan changes discussed earlier are implemented.

[Lucko]

Isn't that a bit close together? I know 0.8.1 has there problems but still is that just that or is something else?

140   239191   2013-06-02 03:15   03:42:08   0.00000000   22.01560992   6,906,882   orphan
139   239158   2013-06-01 23:33   00:47:30   25.07671449   21.21246575   1,525,245   valid
138   239150   2013-06-01 22:46   04:23:37   25.05475000   25.25235495   8,392,360   valid
137   239112   2013-06-01 18:22   07:44:31   25.09837842   26.46872984   14,570,508   valid
136   239041   2013-06-01 10:37   03:01:39   25.03060000   24.41042079   5,781,368   valid
135   239016   2013-06-01 07:36   07:29:50   0.00000000   26.82509542   14,144,418   orphan

[doublec]

Isn't that a bit close together? I know 0.8.1 has there problems but still is that just that or is something else?
140   239191   2013-06-02 03:15   03:42:08   0.00000000   22.01560992   6,906,882   orphan

140 wasn't really a true orphan, it wasn't actually a valid block but the pool paid out on it anyway so I marked it as orphan. The issue was that the pool would submit a block to multiple bitcoind's and every now and then it is actually stale but one of them would report it as successful due to not having had a new block notification yet and it was being reported as a successful block. It could technically be regarded as an orphan but it's not really since that bitcoind would immediately know when it propogated the block further. Too late for the pool though since it considered it valid. I've closed this loophole now.

One advantage of the move to making blocks pending until confirmed is that this sort of issue of "orphan, stale or something else" is avoided since we wait for confirms. I can manually look if needed to see if it was an orphan (racing with another miner) vs was stale but one of the bitcoind's I communicate with didn't know yet.

[juhakall]

An orphan block reduces the DGM score without generating any payout, but a stale block doesn't, right? Since you are submitting blocks to multiple bitcoinds, the boundary between orphan and stale blocks is not that clear, when some bitcoinds can still accept a block while others would reject it. Since this distinction is affecting scores, it would be interesting to have more detail about how you decide whether a block that didn't pay was orphan or stale.

The extreme, malicious case would be running one bitcoind behind a crappy dial-up connection. It would almost always accept blocks that all the other bitcoinds would reject. A bigger than expected portion of blocks would be marked as orphans instead of stales, resulting in smaller scores for users. On the other hand, if you are running, say, five bitcoinds without any malicious intent like described above, and only one rejects a block, why should that block be marked stale? Isn't there a good chance the other bitcoinds could still spread the block and make it win the race? And surely the pool should attempt to use their own block as a base for the next one they are working to generate.

Actually, I have wondered why pools don't modify their bitcoind to not reject a block, if the earlier block of same height still has zero confirmations. Why not work on the block the pool found, even if the other block of same height is already widely spread? If the pool happens to be lucky enough to mine a second block before the competing block gets a new confirmation, their earlier stale block combined with the new one would net the pool two blocks instead of one. Surely I'm missing some obvious reason not to do this.

[soulmann]

Why are last 3 blockes pending?

[rammy2k2]

i just joined this pool, mostly because of the merged mining. any reviews abt pool ?

[doublec]

An orphan block reduces the DGM score without generating any payout, but a stale block doesn't, right? Since you are submitting blocks to multiple bitcoinds, the boundary between orphan and stale blocks is not that clear, when some bitcoinds can still accept a block while others would reject it. Since this distinction is affecting scores, it would be interesting to have more detail about how you decide whether a block that didn't pay was orphan or stale.

The distinction is pretty fine. It's considered a stale if the bitcoind that owns the private address that's paid out in the coinbase address never sees the block. It's an orphan if it sees the block and loses a race resulting in the bitcoin noting the payment as 'orphan'.

Actually, I have wondered why pools don't modify their bitcoind to not reject a block, if the earlier block of same height still has zero confirmations. Why not work on the block the pool found, even if the other block of same height is already widely spread? If the pool happens to be lucky enough to mine a second block before the competing block gets a new confirmation, their earlier stale block combined with the new one would net the pool two blocks instead of one. Surely I'm missing some obvious reason not to do this.

Some pools are big enough to continue building on confirmation 1 blocks and win enough times to make it worthwhile. I think it's generally considered bad form by most pool operators to do this. There's a suspicion that some have done in the past though from discussions I've had with various operators.

[doublec]

Why are last 3 blockes pending?

The switch away from pending is currently done manually while I confirm the process works correctly. I'll be making it automatic when I'm confident everything is fine. This means if we find a number of blocks overnight there will be a delay.

[Lucko]

i just joined this pool, mostly because of the merged mining. any reviews abt pool ?

Not that I know of... But I must say the pool is good. DGM is something of getting used to but it is a good system. Admin is responsive (doublec) and pool works OK in expected reliability. I think uptime is well over 99%. There are some 0.8.1 issues but all pools have them right now. doublec is making and testing merged mining modifications on 0.8.2 that will probably solved that. Pool speed is from 2.1TH to 3.8TH depending on a ASIC miner(1TH) and time of a day... Pool also have a issues in some cases if you are using cgminer 3.x. No problem with 2.x. doublec is looking into them and finding solutions...

If you are looking where to setup difficulty. You do that with password. So if you have low speed miner you setup password to d=1. If you are over 1,5 to 2 GH set it to 2 or 4...

There are some small downsides. You can't change payment address(not sure if this is a downside) so I would recommend setup wallet for your payments. And you don't have individual workers. All is on one account...

Any questions? PM me or write them here.

[rammy2k2]

how do i set up difficulty if i mine with a blade ?

[Lucko]

how do i set up difficulty if i mine with a blade ?

I didn't jet see interface for blade but I guess you have a username and password right? Set password to d=8(I think this setting is good for a blade). Or are you using stratum proxy? But even if you don't do that you are OK. It will defaulted to 16 and that is still OK for blade.

[mtbitcoin]

What would the recommended difficulty be for an Avalon (66GH)?

Thanks

[Lucko]

What would the recommended difficulty be for an Avalon (66GH)?

Thanks

I think it is somewhere between 32 and 64. I would start with 48 or so... And then looking to be sending about 8 to 15 shares a minute. This is DGM so that is more then enough...

EDIT: I see that luck code was implemented 

[mtbitcoin]

What would the recommended difficulty be for an Avalon (66GH)?

Thanks

I think it is somewhere between 32 and 64. I would start with 48 or so... And then looking to be sending about 8 to 15 shares a minute. This is DGM so that is more then enough...

EDIT: I see that luck code was implemented 

Thanks.

btw, what luck code are you referring?

[Lucko]

btw, what luck code are you referring?

Joke... There is no such thing... But last time we had bad luck I asked doublec to crate some code for that.

[rammy2k2]

so far im pretty happy with this pool