Topic: [0Th]Ozcoin Pooled Mining |DGM 1%|Stratum+VarDiff port 80|NEW CN mining| - page 127. (Read 398185 times)

Good ol' Anonymous, I always did like him... or her.
Sam

wtf, some anonymous user is mining on this pool right now @ 358.6 GH/s

http://dl.dropbox.com/u/25848420/wtf%20358ghs.png

who the hell is this?

US server was down for hardware upgrades briefly this morn (my time)

Appologies for no advance warning - wasnt expecting it till Monday - I'm looking at it as "surprise scheduled maintainance"

Now we are comfortable with the backend and stale rate we will move on to the (much needed) front end work

More graphs and real time stats are in the planning for chart pron lovers

#ozcoin irc chanel on chat.freenode.net is active and friendly, staff are available 24/7 for help and support or just general mining chat - also accessable via the WebIRC link onsite -drop in say hi

we have maintained >200Ghash for a week
Encouraging mods to sticky us among top10

  worked

stats are working correctly now
continuing to work on website

Discussion for that is here:
https://bitcointalksearch.org/topic/ozcoin-litecoin-dgmpps-48653

Anyone have an idea what's going on with the Litecoin part of Ozcoin? There was a period this morning when everyone's hashrate dropped to zero and my miner kept saying that a jason_rpc_call failed. My miners connected eventually, but now the server seems to be back down.

What happened at BTCGuild was:
A block was "Invalid" then a VERY short block occurred after that so only the high hashers got shares in it.
Result was that everyone who hashed up to the "Invalid" who didn't have a 2.5% donation and had no shares in "Block Y" (low hash rate) got nothing for all their hashing from "Block X" to "Invalid".

Basically what it means is of course that your hashing from "Invalid" to "Block Y" determine your payout and your hashing from "Block X" to "Invalid" is ignored.
This can be the same or can be different depending on a quite a few things.
I'm not sure what effect this has on DGM.

Also from the pool point of view they are paying out extra BTC for hashing from "Block X" to "Invalid" for anyone who has >= 5% donation

Yeah, this looks much better now.
I reconnected a few hours ago and my BTC efficiency is at 99.76%. Nice.
NMC is still a desaster though (83.93%).

thanks Inaba , I do understand and in fact that is what we did on the pool when it was proportional

but please bear with me a monent.
When I sit here looking at poolserverj's console and see a block found message with the hash and the finders userID my pool sees a block, the bot in our irc chanel announces a block,miners go "woohoo", share count is set to 0 and a new round commenced etc.
After this "block" is announced to the network the network verifies or orphans/invalidates/ our block depending on network criteria and others "blocks" submitted close to the same time.

Meni, i meant this bit " share count is set to 0 and a new round commenced etc."

Now I have had a discussion with someone knowledgeable about this as well and was told it couldn't have happened, but one time we saw a block "orphaned" at 8 or 9 confirmations... blocks were rare at the time and I was watching the wallet and announcing the confirmation count in IRC got to 7 went for a drink, came back and it had been orphaned- it did happen.So early payout is always a risk.

So

Quote from: Graet on January 09, 2012, 01:13:52 AM

as i said this has been the topic of discussion among staff for some days

Actual topics covered in more detail so we dont need to keep going around in circles
1:  sorting the software to Block X ----> Invalid Block ----> Block Y as we did in the past.
2: We need to work out a way to incentivise "donations" that doesnt involve paying out at 0 confirmations maybe at 5.Realising that I do pay the server costs and would like the pool to break even oneday but also to reward and give incentive to the coders for their good work and any other bounties or dontaions to bitcoin software developers not on staff.Whilst still giving the option of 0 fee pool.
3: We do not want to put ads on the site and then offer for ppl to pay to have them removed - but always an option
4: Reintroducing TXN fees with block payouts
5: Getting massmail setup on new site. so we can inform miners of changes, planned outages etc.
6: Stabilising displayed hashrates
A lot of these are being workked on and those that arent are in a to do list
And quite a few other that i dont think it is neccesary to share at the moment - do keep an eye though, some interesting stuff coming for Ozcoin miners .

Suffice to say work is not finished and the first post in this thread is the first place I update when changes are being made

slow reply, sick kid finally sleeping
hope it helps clear the situation

That's the key assumption. If it's invalidated there will be a difference in actual payout between different ways to treat invalid blocks. There's no bias (for methods like prop) one way or the other so I don't think it really matters much, but there is at least a conceptual difference, and I think kano is entitled to consider one way as more proper.

Huh, I'm not sure what's going on with regards to that at OzCoin, it was my understanding from YourBTC that we had a functionally similar DGM implementation (Although I think theirs is handled after the fact via PHP where as EMC is handled in real time, so maybe that's why it's different?)  - anyway, when there's an invalid block on EMC, things just continue as normal and your payout is calculated based on your score.  Meni and I addressed it at the time we implemented DGM - I don't see why the same wouldn't have been done on YourBTC so consequently it should be the same at OzCoin.  

While I'm speaking purely about DGM (since it's both EMC and OzCoins model), the same really applies even to a prop pool like BTC Guild Prop you are talking about.  Assuming (and maybe it's an erroneous assumption) the hashrate remains relatively constant from Block X ---- Block Y, regardless of whether or not an invalid block is between it or not, your payout is going to be the same.  

To illustrate this, say you have 10% of the pools hashrate.

Block X -----> Invalid -----> Block Y  = You receive a total of 5 BTC after the invalid goes poof and block Y is solved.

Block X -----> Block Y = You receive a total of 5 BTC.

Whether or not it's prop or DGM, it really doesn't matter.  The net effect of an invalid block is that it doesn't exist and should never have existed in the first place.. so you aren't out anything.

What I suspect some people take umbrage with is the fact that now Block X ---> Block Y appears to be X + (Invalid ---> Block Y) shares, instead of X shares.  But if the invalid block was masked (like it really should be), your shares are still X.

The thing is, with variance, there may only be a handful of shares between Invalid ---> Block Y or there may be a ton of shares.  But in the end, it will still end up at close to 0 variance, which is effectively proof that the invalid block never really existed and thus nothing was lost.

What that 2.5% "donation" or fee bought you was effectively an extra payment that you should not have received for a block that never existed.  I think maybe it set a poor precedent (or really maybe Deepbit did) in acknowledging an invalid block as a legitimate entity that a miner is somehow entitled to.

That is what I'd like - however it isn't what the first post says is currently happening
(and isn't what was happening on BTCGuild Prop)

What was happening on BTCGuild Prop was the shares you generated from "Block X" up until the "Invalid Block" were thrown away unless you had a 2.5% donation.
From your diagram, the shares from "Invalid Block" to "Block Y" were paid to everyone using ALL of "Block Y"
The shares from "Block X" to "Invalid Block" where only paid if you had 2.5% donation and were paid by the pool itself (no block 50BTC to cover the cost)

Meni's comment may actually mean that isn't what is happening at Ozcoin anyway ...
However from the first post "pay invalids for 5%+ donors" specifically means that shares generated from "Block X" to "Invalid Block" are not paid unless the donation is set to 5% (or higher) though that may be a misunderstanding of DGM

Resets what to 0?

I think what kano is trying to say is that, since invalid block is equivalent to no block, the existence of an invalid block shouldn't affect people's scores. So in a method like proportional, people's scores shouldn't be reset to 0 for invalid blocks.

The problems with his approach are that:
1. It's more complicated to implement.
2. It doesn't matter that much in the case he is considering.
3. It assumes using the proportional method. For PPLNS it's moot since scores aren't updated upon finding blocks. For DGM it matters somewhat since scores are meaningfully updated on blocks, but as I derived some time ago, the correct way to handle this and ensure a fair reward is to update the scores on any block, even if it is invalid. But I was surprised that Graet implied that scores are reset to 0, unless I misunderstood or missing an implementation detail, this could imply an error in his DGM.

I understand, but what I'm saying is that there is no work lost.  The block never truly existed in the first place, nothing was truly solved, therefore nothing was lost.  The fact that you were lead to believe a block existed is the problem and virtually inherent in the network, but as far as the blockchain is concerned, it does not exist and thus you continue mining until you DO find a block.

Block X ----> Invalid Block ----> Block Y

is the exact same as

Block X ----> Block Y

There is no functional or monetary difference between the two.

not something we have looked at yet, I imagine in a few payments time we will be able to get a better idea of the average

What is the average % gain in btc because of the merged mining?

sure is
took a while to get the namecoin working right, but
Date   Comment   Payout   Donation
2012-01-09 09:40:02   Namecoin Exchange (0.00521001 BTC/NMC)   0.02361353   0.00000000

my first one just came through

Is there still auto-conversion of namecoin to btc ?

I think this was the most important line in my post - and the line you skipped over?
I do understand your concern and I did raise this with the coding team some days ago
and yes i hope there are no orphans before it is resolved

BUT I also stated in the 1st post how the pool is operating right now - I am not trying to decieve anyone here. Just to state how things are setup at the moment.