Bitcoin Forum
March 19, 2024, 11:12:18 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Warning: One or more bitcointalk.org users have reported that they strongly believe that the creator of this topic is a scammer. (Login to see the detailed trust ratings.) While the bitcointalk.org administration does not verify such claims, you should proceed with extreme caution.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 »
  Print  
Author Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining  (Read 163653 times)
doublec (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1005


View Profile
June 02, 2013, 12:10:51 AM
 #841

Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful Wink) 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:
Quote
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:

Quote
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.
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710846738
Hero Member
*
Offline Offline

Posts: 1710846738

View Profile Personal Message (Offline)

Ignore
1710846738
Reply with quote  #2

1710846738
Report to moderator
1710846738
Hero Member
*
Offline Offline

Posts: 1710846738

View Profile Personal Message (Offline)

Ignore
1710846738
Reply with quote  #2

1710846738
Report to moderator
1710846738
Hero Member
*
Offline Offline

Posts: 1710846738

View Profile Personal Message (Offline)

Ignore
1710846738
Reply with quote  #2

1710846738
Report to moderator
matt4054
Legendary
*
Offline Offline

Activity: 1932
Merit: 1035



View Profile
June 02, 2013, 12:32:11 AM
 #842

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
Full Member
***
Offline Offline

Activity: 231
Merit: 100


View Profile
June 02, 2013, 01:56:49 AM
Last edit: June 02, 2013, 02:17:28 AM by redtwitz
 #843

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:

Quote
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 (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1005


View Profile
June 02, 2013, 02:00:34 AM
 #844

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 (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1005


View Profile
June 02, 2013, 05:36:59 AM
Last edit: June 02, 2013, 05:58:02 AM by doublec
 #845

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
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
June 02, 2013, 07:20:11 AM
 #846

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 (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1005


View Profile
June 02, 2013, 07:42:29 AM
 #847

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
Sr. Member
****
Offline Offline

Activity: 657
Merit: 250


View Profile WWW
June 03, 2013, 05:12:02 PM
 #848

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.

I'm currently developing an experimental social AI platform
soulmann
Full Member
***
Offline Offline

Activity: 221
Merit: 100


View Profile
June 03, 2013, 07:47:20 PM
 #849

Why are last 3 blockes pending?
rammy2k2
Legendary
*
Offline Offline

Activity: 1974
Merit: 1003



View Profile
June 03, 2013, 08:04:29 PM
 #850

i just joined this pool, mostly because of the merged mining. any reviews abt pool ?
doublec (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1005


View Profile
June 03, 2013, 09:08:20 PM
 #851

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 (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1005


View Profile
June 03, 2013, 09:09:23 PM
 #852

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
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
June 04, 2013, 06:43:42 AM
Last edit: June 04, 2013, 09:22:20 AM by Lucko
 #853

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
Legendary
*
Offline Offline

Activity: 1974
Merit: 1003



View Profile
June 04, 2013, 07:34:16 AM
 #854

how do i set up difficulty if i mine with a blade ?
Lucko
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
June 04, 2013, 07:59:33 AM
 #855

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
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
June 04, 2013, 08:39:23 AM
 #856

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

Thanks

EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
Lucko
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
June 04, 2013, 09:21:57 AM
Last edit: June 04, 2013, 01:43:22 PM by Lucko
 #857

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  Grin
mtbitcoin
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
June 04, 2013, 03:30:52 PM
 #858

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  Grin

Thanks.

btw, what luck code are you referring?

EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
Lucko
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
June 04, 2013, 04:03:12 PM
 #859

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
Legendary
*
Offline Offline

Activity: 1974
Merit: 1003



View Profile
June 04, 2013, 08:48:59 PM
 #860

so far im pretty happy with this pool  Roll Eyes
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!