Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 54. (Read 163893 times)
Pool had a 5 minute restart today to install some updates.
Hi! Do you think it could be possible to merge mine NVC, PPC, TRC and other sha256d coins?
Those coins are not set up for merged mining. The creators/users of those coins would need to change them to support merged mining.
Hi! Do you think it could be possible to merge mine NVC, PPC, TRC and other sha256d coins?
Didn't know that. I was sure it reports the finder since this is the first time I saw this from the pool I was on. You live and you learn...
You can tell it's from Bitparking anyway since I have "Bitparking" in the coinbase. 
Bitparking pushes the new block out to multiple bitcoin nodes. Depending on which of those broadcasts the block first it gets a different IP address and blockchain.info won't show it as coming from 'Bitparking'.
Didn't know that. I was sure it reports the finder since this is the first time I saw this from the pool I was on. You live and you learn... Unless 24.6.229.60 is Bitparking we will probably have orphan block... It looks like pool is not weary well connected because it took about 2 minutes for 50BTC to show up after we fond a block and I still don't see Bitparking on Blokchain.info
EDIT: It looks like this time we had IP not name for some reason... Addresses for new coins look like Bitparking...
EDIT: It looks like this time we had IP not name for some reason... Addresses for new coins look like Bitparking...
Remember blockchain doesn't actually report the IP that found the block (that info isn't in the chain), rather they report the IP that first sent the block to blockchain's bitcoin server. It won't always be the pool itself since blockchain doesn't keep connections open to every node in the network at once.
Pool user br*********at ('*' replaces name characters to avoid revealing your user id), you are mining on stratum using an scrypt miner and all your shares are rejecting. You might want to check.
Unless 24.6.229.60 is Bitparking we will probably have orphan block... It looks like pool is not weary well connected because it took about 2 minutes for 50BTC to show up after we fond a block and I still don't see Bitparking on Blokchain.info
EDIT: It looks like this time we had IP not name for some reason... Addresses for new coins look like Bitparking...
Bitparking pushes the new block out to multiple bitcoin nodes. Depending on which of those broadcasts the block first it gets a different IP address and blockchain.info won't show it as coming from 'Bitparking'. EDIT: It looks like this time we had IP not name for some reason... Addresses for new coins look like Bitparking...
I don't know where it's getting port 52333 from. It should be port 8337. Where did you get the source from? Try:
Code:
ixcoind -addnode=50.116.37.18:8337
I got the Windows "package" from here, I thought it was the closest to the "official" binary.
Now forcing port 8337 didn't seem to do the magic. I think I need another devcoind.exe or compile it myself...
You would have better luck had you gotten the binary from here https://www.box.com/s/1mqfk22gyqq97ytdmifi
Unless 24.6.229.60 is Bitparking we will probably have orphan block... It looks like pool is not weary well connected because it took about 2 minutes for 50BTC to show up after we fond a block and I still don't see Bitparking on Blokchain.info
EDIT: It looks like this time we had IP not name for some reason... Addresses for new coins look like Bitparking...
EDIT: It looks like this time we had IP not name for some reason... Addresses for new coins look like Bitparking...
We need to write algorithm add luck... I choose a really bed time to join...
Depending on the setting for o in DGM, your shares also carry value across rounds like in PPLNS. It's just in PPLNS you have 100% credit until hitting the cap for N, then the value goes to 0. In DGM (depending on the settings) the value of the shares decay geometrically. Since the value of the share is set at the time the share is logged, whether you leave the pool or stay around has no effect on that share's value. Your earnings will vary based on short/long blocks with equal probability.
FTFY? Do you understand PPLNS at all? You get paid for each share based on blocks solved after it's submitted. The value of the share has NOTHING to do with timing/consistency of share submissions. It is entirely based on how many blocks the pool solves after the share is submitted. There is no exponential/DGM scoring involved that makes shares worth less when you stop or when you start.
Reading comprehension is your friend.
PPLNS (while better than DGM) still punishes inconsistent miners on long rounds. It only counts the last N shares. You can claim it isn't related to timing or consistency of submitted shares... but anyone who understands how the payout method works knows you're incorrect. The saving grace on PPLNS is on short rounds you effectively get paid the same as an average round... But how often does a pool have multiple short block finds in a row?
Your terminology is flawed. Punish implies the method actively discriminates/penalizes the miner. You're simply giving an example where a miner submits shares during bad luck then isn't mining during good luck. That's variance, and is present under EVERY system except for PPS. They could have the exact opposite, and only mine during good luck. That's not rewarding them for inconsistency, that's just being on the positive side of variance.
PPLNS with bad settings could make it so they get -no- payment during bad luck, which could be considered punishing. With proper settings, they will get some payment. BTC Guild's setting for 'N' is ~25x difficulty. There will never be a time where a share is not paid something. The higher the N value, the less variance for inconsistent miners.
FTFY? Do you understand PPLNS at all? You get paid for each share based on blocks solved after it's submitted. The value of the share has NOTHING to do with timing/consistency of share submissions. It is entirely based on how many blocks the pool solves after the share is submitted. There is no exponential/DGM scoring involved that makes shares worth less when you stop or when you start.
Reading comprehension is your friend.
PPLNS (while better than DGM) still punishes inconsistent miners on long rounds. It only counts the last N shares. You can claim it isn't related to timing or consistency of submitted shares... but anyone who understands how the payout method works knows you're incorrect. The saving grace on PPLNS is on short rounds you effectively get paid the same as an average round... But how often does a pool have multiple short block finds in a row?
Nice pool, thanks for running. I like the no nonsense website.
Is it a bad idea to have multiple workers submitting shares under the same userID ?
Not at all.
PPLNS doesn't punish miners for disconnects/non-continuous mining, while still being hop proof.
Nor does DGM. The Slush scoring method has got people thinking that "hop proof" means "must mine continuously". Since it's waiting until confirmation of block generation and paying based on the last 5 rounds these losses will be obfuscated because they happen proportionally over the next 5 rounds. As I miner all you'll be able to notice is that your earnings seem to have decreased.
What is this 5 round thing you are writing about? Where in DGM do they mention 5 rounds? Note this point in the DGM article:Quote
the expected payout per share is always the same no matter when it was submitted.
I know what FTFY you is. But when what is posted is inaccurate BS, it's hardly fixed
.
Judging from the latest posts, it looks like forum messages are sometimes almost as hard to correctly understand as payment methods. 
Jump to: