Bitcoin Forum
December 10, 2016, 12:53:36 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 ... 226 »
  Print  
Author Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!  (Read 461947 times)
ThiagoCMC
Legendary
*
Offline Offline

Activity: 1190


฿itcoin: Currency of Resistance!


View Profile WWW
January 23, 2012, 01:34:33 PM
 #1561

I hate "Invalid Blocks".

What we need to do for EclipseMC pay us for invalid blocks?!

Mercado Forex acessível para todos os Brasileiros que tenham Bitcoins! Cadastre-se hoje mesmo! Bastar acessar aqui: https://1broker.com/m/r.php?i=8879
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481374416
Hero Member
*
Offline Offline

Posts: 1481374416

View Profile Personal Message (Offline)

Ignore
1481374416
Reply with quote  #2

1481374416
Report to moderator
1481374416
Hero Member
*
Offline Offline

Posts: 1481374416

View Profile Personal Message (Offline)

Ignore
1481374416
Reply with quote  #2

1481374416
Report to moderator
1481374416
Hero Member
*
Offline Offline

Posts: 1481374416

View Profile Personal Message (Offline)

Ignore
1481374416
Reply with quote  #2

1481374416
Report to moderator
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
January 23, 2012, 02:28:49 PM
 #1562

I hate "Invalid Blocks".

What we need to do for EclipseMC pay us for invalid blocks?!
I saw that invalid block and it made me wonder two things:

1) Didn't I read something about the scoring system leading to some (much less than normal) pay on invalid blocks?  Was that the previous scoring system, is the block chart wrong, or is the calculation wrong?

2) How do the averages work with invalid blocks?  Technically, doesn't "44% luck" on an invalid block equate to no luck, and shouldn't the average luck percentage (if not the next block luck percentage) include the time wasted on the invalid block but not the luck from it (avg divide by 49 instead of 50 or something)?
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
January 23, 2012, 02:43:18 PM
 #1563

Well, I can institute something like an "invalid block insurance" at 3% "fee"... I hesitate to call it a donation, though, since a donation implies of someones free will.  But like a couple pools have done in the past, they insure against invalid blocks with a forced donation of x amount.  I'm certainly open to this if there's enough demand.

Quote
1) Didn't I read something about the scoring system leading to some (much less than normal) pay on invalid blocks?  Was that the previous scoring system, is the block chart wrong, or is the calculation wrong?

2) How do the averages work with invalid blocks?  Technically, doesn't "44% luck" on an invalid block equate to no luck, and shouldn't the average luck percentage (if not the next block luck percentage) include the time wasted on the invalid block but not the luck from it (avg divide by 49 instead of 50 or something)?

Nope, there's no less than normal pay on invalid blocks, unless you mean 0 pay?  As much as I'd like to pay out on invalid blocks, I can't afford to pay 50 BTC out of my pocket.  I'm not really making money on running the pool and my Ferrari is sadly still on layaway.  Actually, I'll settle for an Lotus Exige or Ariel Atom at this point. 

I'm not sure I understand your question with regards to the block chart being wrong?

As far as the averages, there's a few different ways you can look at an invalid block and each are equally valid but produce very different results.  The convention, perhaps set by Deepbit and Slush et al in the beginning is to acknowledge invalid blocks as being a separate legitimate entity.  From a purely continuity standpoint, this should not be so and invalid blocks should never be acknowledged as existing in the first place as far as pools go - thus they should just be passed over and the current block continues as normal.

Convention and technical limitations make this more difficult in so far as it takes time for a block to be realized as invalid, so unless the pool delays the stats, an invalid block shows up in the chart until it's invalidated by the network. 

So, as far as luck goes for both the invalid and current block, since it's acknowledged as a separate entity from the current block, it takes with it it's luck.  It's ultimately a semantics game, and through convention and technical limitations, you get what you see.  If people would prefer another method/display/semantic convention, I am happy to oblige, I just chose the current method because that's what people are already familiar with and I am definitely not trying to hide anything.

I would like to point out, with this latest invalid, we are right under the "average" as far as invalids go, since the start of the pool (400 blocks * 1.5% = 6 invalids).

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
January 23, 2012, 04:10:00 PM
 #1564

I don't care one way or the other how the pool calculates the average, whatever is easier is fine, I was just curious as to how it was done.  Regarding the less pay, maybe I read that in Meni's thread, but I thought it was in this one, because it seems like it possibly wasn't necessarily part of double-geometric, but was part of the previous method (and I didn't read THAT threa [presumably also of Meni's]).  Doesn't really matter.  Maybe I misintrepreted a comment and the idea is that the score from the invlaid block is still paid, but at a lower amount since it is paid on later blocks and has decayed.  As far as invalid blocks go, they are part of it, an optional donation of 3% to get paid on invalids would  be optional and therefore of free will, but probably require more coding.  A 3% fee and paying on invalids might make some people happy and could theoretically earn (or perhaps cost) you more in the long run, but then you wouldn't be able to call the pool 0% (per your argument on the ABCPool thread).
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
January 23, 2012, 04:51:17 PM
 #1565

Payout difference was about 1% per user between the invalid and next block, which would account of decay time if you did not factor in the invalid block.

I will consider how best to handle (if at all) an invalid block insurance plan.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
January 23, 2012, 05:14:45 PM
 #1566

I don't care one way or the other how the pool calculates the average, whatever is easier is fine, I was just curious as to how it was done.  Regarding the less pay, maybe I read that in Meni's thread, but I thought it was in this one, because it seems like it possibly wasn't necessarily part of double-geometric, but was part of the previous method (and I didn't read THAT threa [presumably also of Meni's]).  Doesn't really matter.  Maybe I misintrepreted a comment and the idea is that the score from the invlaid block is still paid, but at a lower amount since it is paid on later blocks and has decayed.  As far as invalid blocks go, they are part of it, an optional donation of 3% to get paid on invalids would  be optional and therefore of free will, but probably require more coding.  A 3% fee and paying on invalids might make some people happy and could theoretically earn (or perhaps cost) you more in the long run, but then you wouldn't be able to call the pool 0% (per your argument on the ABCPool thread).
You remember correctly, and I think this is implemented right in EMC even if Inaba isn't completely aware of why it's right (and even if I once erroneously commented on a PM that there's a problem in need of fixing).

The previous method which was the geometric method, is a special case of double geometric, so the same issue with invalid blocks applied to it (and more strongly). But I hadn't yet examined invalid blocks thoroughly at that point, so what you're probably remembering are my comments in this thread about the current method.

The thing is this - DGM features block decay, which means that whenever a block is found, every worker loses a portion of his score. So the question is whether to decay for invalid blocks as if they were normal blocks, or refrain from decaying as if there was never a block at all.

Intuitively you might think that the block needs to be ignored. But a closer examination reveals that this would cause unfair losses to the operator (so on a 0-fee pool he would actually lose on average for running the pool). On the other hand, if blocks cause decay as if they were valid, the loss is shared equally between all parties. So if for example 1% of blocks are invalid, every miner will gain on average 1% less than he would have if all blocks were valid, and the pool op's profits, if the pool has fees, will also be reduced by 1% of the profit. This I think is the fair solution.

It just so happens that the correct solution is also easier technically, so it is what we have by default. It should also be noted that with the parameters used in EMC, block decay is very weak so the issue has little consequence one way or the other.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
cyberlync
Full Member
***
Offline Offline

Activity: 226



View Profile
January 23, 2012, 06:37:34 PM
 #1567

I am currently watching cgminer showing "Pool 0 communication failure, caching submissions" and after a second, sometimes up to 6-7 secs later, it gets back and submits the shares. Pool 0 is us.eclipsemc.com:8337

edit: switched to us2 and now it all seems to work fine.

Giving away your BTC's? Send 'em here: 1F7XgercyaXeDHiuq31YzrVK5YAhbDkJhf
NetworkerZ
Member
**
Offline Offline

Activity: 114


View Profile
January 23, 2012, 07:03:25 PM
 #1568

Me too. Miner says connecting, then it mines for a few seconds and lose connection again. Also on us1 port 8337

Greetz
NetworkerZ
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
January 23, 2012, 07:34:01 PM
 #1569

Definitely switch to US2.  US1 is just overloaded.

I will likely be rolling out a US3 shortly as well.  I want to make sure US2 is working properly before I add the code for the third server.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
NetworkerZ
Member
**
Offline Offline

Activity: 114


View Profile
January 23, 2012, 07:49:06 PM
 #1570

OK, switched all workers to US2. THX for the info.

Greetz
NetworkerZ
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 23, 2012, 10:21:55 PM
 #1571

I don't care one way or the other how the pool calculates the average, whatever is easier is fine, I was just curious as to how it was done.  Regarding the less pay, maybe I read that in Meni's thread, but I thought it was in this one, because it seems like it possibly wasn't necessarily part of double-geometric, but was part of the previous method (and I didn't read THAT threa [presumably also of Meni's]).  Doesn't really matter.  Maybe I misintrepreted a comment and the idea is that the score from the invlaid block is still paid, but at a lower amount since it is paid on later blocks and has decayed.  As far as invalid blocks go, they are part of it, an optional donation of 3% to get paid on invalids would  be optional and therefore of free will, but probably require more coding.  A 3% fee and paying on invalids might make some people happy and could theoretically earn (or perhaps cost) you more in the long run, but then you wouldn't be able to call the pool 0% (per your argument on the ABCPool thread).
You remember correctly, and I think this is implemented right in EMC even if Inaba isn't completely aware of why it's right (and even if I once erroneously commented on a PM that there's a problem in need of fixing).

The previous method which was the geometric method, is a special case of double geometric, so the same issue with invalid blocks applied to it (and more strongly). But I haven't yet examined invalid blocks thoroughly at that point, so what you're probably remembering are my comments in this thread about the current method.

The thing is this - DGM features block decay, which means that whenever a block is found, every worker loses a portion of his score. So the question is whether to decay for invalid blocks as if they were normal blocks, or refrain from decaying as if there was never a block at all.

Intuitively you might think that the block needs to be ignored. But a closer examination reveals that this would cause unfair losses to the operator (so on a 0-fee pool he would actually lose on average for running the pool). On the other hand, if blocks cause decay as if they were valid, the loss is shared equally between all parties. So if for example 1% of blocks are invalid, every miner will gain on average 1% less than he would have if all blocks were valid, and the pool op's profits, if the pool has fees, will also be reduced by 1% of the profit. This I think is the fair solution.

It just so happens that the correct solution is also easier technically, so it is what we have by default. It should also be noted that with the parameters used in EMC, block decay is very weak so the issue has little consequence one way or the other.
Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
I guess that explains why the earlier discussion died.

There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code Tongue - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.

Until a block is confirmed (120 confirms) it does not exist.
If blocks that get orphaned do affect your DGM, then your DGM is faulty - especially when almost all orphaned blocks are known within 1 confirm.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
January 23, 2012, 11:47:07 PM
 #1572

Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
<snip>
Until a block is confirmed (120 confirms) it does not exist.
If blocks that get orphaned do affect your DGM, then your DGM is faulty - especially when almost all orphaned blocks are known within 1 confirm.
That's one way to look at it, but if you do look at it that way, you could also argue that every time a new block is found on the network all old shares/scores should be discarded since they aren't for the current block (the algorithm does count shares, not blocks; blocks only trigger activity, and the invalid one didn't).  I think BTCGuild even counted shares from invalid blocks toward the next valid block when they were proportional, and it was all pooled work trying to acquire a reward that wasn't acquired until the next valid found block.  Regardless, I'm not sure arguing about which valid shares should count toward a block really has much merit.

EDIT: More importantly, if the algorithm didn't count shares from invalid blocks, pool hoppers would have something to gain, all the work they didn't do later in the invalid block.
btc_artist
Full Member
***
Offline Offline

Activity: 154


Bitcoin!


View Profile WWW
January 24, 2012, 12:02:42 AM
 #1573

Watching.

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
stoppots
Sr. Member
****
Offline Offline

Activity: 271


View Profile
January 24, 2012, 04:26:04 AM
 #1574

Is there a way to withdrawal just the confirmed BTC
BinaryMage
Hero Member
*****
Offline Offline

Activity: 546


Ad astra.


View Profile
January 24, 2012, 04:32:57 AM
 #1575

Is there a way to withdrawal just the confirmed BTC

Under the "Pay Me" menu on the right of the "My Account" page, click "BTC" under "My BTC as".

-- BinaryMage -- | OTC | PGP
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
January 24, 2012, 05:02:31 AM
 #1576

Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
I guess that explains why the earlier discussion died.
What earlier discussion?

There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code Tongue - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.
Do you have a reference for that? This isn't possible as far as I know.

Until a block is confirmed (120 confirms) it does not exist.
If blocks that get orphaned do affect your DGM, then your DGM is faulty - especially when almost all orphaned blocks are known within 1 confirm.
Like I said, that's the correct way to do it. Do the math if you don't believe me. When I have the time I'll add the relevant math to the DGM post and AoBPMRS.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 24, 2012, 08:07:19 AM
 #1577

Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
I guess that explains why the earlier discussion died.
What earlier discussion?

There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code Tongue - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.
Do you have a reference for that? This isn't possible as far as I know.

...
It's not an 'impossible' issue (as I said the word 'orphan' isn't actually correct) but it's very simple:
If you calculate a share that's also a block but it's rejected coz it's late: an LP occurred while you were calculating it.
Like ANY normal rejected share except in this case it's also a block level difficulty.

I will also point out something to any people using cgminer that may have someone in tears if they find one:
If you log all of the output of cgminer, search the logs for a line that contains both "Rejected" and "BLOCK"
That's what I'm referring to (but they should be rare)

That's the same as an orphaned block except it's 1 or a few seconds later (so the pool doesn't advertise it to the network)
That of course has no effect on anything - yet your saying an orphaned block does with your algorithm simply because it was advertised to the network - but the network rejected it.

Of course you know, but I'll state it again: an orphaned block is simply a block that was either calculated just a fraction later than someone else on the network did (but was sent out coz the pool didn't know about the other block yet), or the other 'pool' got their block known by more nodes than your pool at about the same time (which usually also means your block was later than the winning block unless the losing pool has crappy network connections or a lower connection count than the wining pool)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
January 24, 2012, 08:32:22 AM
 #1578

...
There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code Tongue - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.
Do you have a reference for that? This isn't possible as far as I know.
...
It's not an 'impossible' issue (as I said the word 'orphan' isn't actually correct) but it's very simple:
If you calculate a share that's also a block but it's rejected coz it's late: an LP occurred while you were calculating it.
Like ANY normal rejected share except in this case it's also a block level difficulty.
I misunderstood what you meant, now I get it.


For reference, by default the correct way to deal with rejected shares in the scoring method - shares which the pool knows are invalid the moment it receives them - is to ignore them completely, for purposes of both payout and decay, even if they happen to satisfy the full difficulty requirement. Decaying for invalid blocks is only if the pool thought at first this is going to be an accepted block but it happened to be beat by a different block. (Of course, the pool could offer payouts for rejected shares as a feature, but this would cause a loss unless the op takes a fee to compensate).

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
January 24, 2012, 03:41:23 PM
 #1579

us3.eclipsemc.com is open for testing.  Port 8337.

Let me know if anyone encounters any problems. 

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
cyberlync
Full Member
***
Offline Offline

Activity: 226



View Profile
January 24, 2012, 10:24:32 PM
 #1580

It seems whenever we find a block I get quite long miner idles, I set the timer to go to the back up pool if I get 15secs of idle time (up from 6 secs), and both on us2 and us3 I seem to be getting this problem. Just watched it happen...

Giving away your BTC's? Send 'em here: 1F7XgercyaXeDHiuq31YzrVK5YAhbDkJhf
Pages: « 1 ... 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 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 ... 226 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!