[DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too

[Chopes]

Pay outs seem to be broken at the moment.

Definitely not working.

[Chopes]

Looks like payouts are back up and running no problems.  Thanks tycho

[DeepBit]

Are payouts not working? Just tried to do an instant payout, reach the success page, but the btc is still in my account and no payout is recorded. Known issue being worked on?

Yes, it's a known issue, already fixed.
You may request your payment again.

[DeepBit]

Why isn't the difficulty history updated anymore?

It was updated manually, but then I decided to implement automatic update and not deployed it yet. Sorry about that.

[paraipan]

Why isn't the difficulty history updated anymore?

It was updated manually, but then I decided to implement automatic update and not deployed it yet. Sorry about that.

thanks DeepBit, whoever you are

[DeepBit]

Why isn't the difficulty history updated anymore?

It was updated manually, but then I decided to implement automatic update and not deployed it yet. Sorry about that.

thanks DeepBit, whoever you are ;)

https://bitcointalk.org/index.php?topic=3889.msg572234#msg572234

"[Tycho]" is always [Tycho] and "DeepBit" may be [Tycho] or someone else authorized to make "official" statements and support :)

[paraipan]

Why isn't the difficulty history updated anymore?

It was updated manually, but then I decided to implement automatic update and not deployed it yet. Sorry about that.

thanks DeepBit, whoever you are

https://bitcointalk.org/index.php?topic=3889.msg572234#msg572234

"[Tycho]" is always [Tycho] and "DeepBit" may be [Tycho] or someone else authorized to make "official" statements and support

relax man, i know that, just making you our mystic helper...

[Mousepotato]

Nearly 10M shares on that last block. Ouch!

[patrixiorey]

I'm having some issues,

1)When i start to mine in this pool the 3 to 5 first blocks are shown in stats as i never submit a share, and i don't receive any payment for those blocks

Also, when i stop my workers, the 3 to 5 last block that i submit shares are shown again in stats like i never shared on those again, and again i don't receive the payment for those.

I was watching all the blocks resolved for several days, one by one, and i was monitoring that on the last 7 days and always happened the same. This have some explanation?

2)Also in last days i put a counter for shares submited, and again start monitoring, I detected that the shares are not asigned correctly to each block resolved. The stats system take an amount of my shares subtimted to the blocks that are resolved in a few minutes, and those shares from fast blocks are asigned to the fat blocks that are resolved sometimes in hours, and as result my payment is lowered from 10 to 40% less.

To be graphical like this example:

https://i.imgur.com/Enqjo.jpg


So, the first thing that i think was that maybe my counter is giving wrong info, but no, i go to other pools and i tested for several hours and no, the counter is fine.

I can make a table with the same info like the example with true info from my share counter and the Deepbit stats, but i think that isn't need, Anyone could do the same and see.

So, i also sended before a this info to the mail address shown on deepbit web, but at this moment i don't have a response...

[bulanula]

I'm having some issues,

1)When i start to mine in this pool the 3 to 5 first blocks are shown in stats as i never submit a share, and i don't receive any payment for those blocks

Also, when i stop my workers, the 3 to 5 last block that i submit shares are shown again in stats like i never shared on those again, and again i don't receive the payment for those.

I was watching all the blocks resolved for several days, one by one, and i was monitoring that on the last 7 days and always happened the same. This have some explanation?

2)Also in last days i put a counter for shares submited, and again start monitoring, I detected that the shares are not asigned correctly to each block resolved. The stats system take an amount of my shares subtimted to the blocks that are resolved in a few minutes, and those shares from fast blocks are asigned to the fat blocks that are resolved sometimes in hours, and as result my payment is lowered from 10 to 40% less.

To be graphical like this example:




So, the first thing that i think was that maybe my counter is giving wrong info, but no, i go to other pools and i tested for several hours and no, the counter is fine.

I can make a table with the same info like the example with true info from my share counter and the Deepbit stats, but i think that isn't need, Anyone could do the same and see.

So, i also sended before a this info to the mail address shown on deepbit web, but at this moment i don't have a response...

Cue in the popcorn please ...

Scammers gonna scam. Maybe they are not scamming you but you are just "unlucky" and the counter is "fixed" just for you

[ancow]

I'm having some issues,

1)When i start to mine in this pool the 3 to 5 first blocks are shown in stats as i never submit a share, and i don't receive any payment for those blocks

Also, when i stop my workers, the 3 to 5 last block that i submit shares are shown again in stats like i never shared on those again, and again i don't receive the payment for those.

I was watching all the blocks resolved for several days, one by one, and i was monitoring that on the last 7 days and always happened the same. This have some explanation?

2)Also in last days i put a counter for shares submited, and again start monitoring, I detected that the shares are not asigned correctly to each block resolved. The stats system take an amount of my shares subtimted to the blocks that are resolved in a few minutes, and those shares from fast blocks are asigned to the fat blocks that are resolved sometimes in hours, and as result my payment is lowered from 10 to 40% less.

To be graphical like this example:

[...]


So, the first thing that i think was that maybe my counter is giving wrong info, but no, i go to other pools and i tested for several hours and no, the counter is fine.

I can make a table with the same info like the example with true info from my share counter and the Deepbit stats, but i think that isn't need, Anyone could do the same and see.

So, i also sended before a this info to the mail address shown on deepbit web, but at this moment i don't have a response...

Are you sure you aren't forgetting the stats delay? Also, your "my counter" part of the graphic can't possibly measure the total amount of shares, so that is suspicious. You should rather include the beginning and end of round times.

FWIW, I do a little superficial verification that shares are counted correctly from time to time, and everything checks out.

[os2sam]

I'm having some issues,

1)When i start to mine in this pool the 3 to 5 first blocks are shown in stats as i never submit a share, and i don't receive any payment for those blocks

I apologize in advance if I am stating things you already know/considered.

The Deepbit stats page is delayed by one hour so you may be seeing blocks that were found prior to your starting mining.  Also if there is a really long block mixed in the round it may take longer than an hour for the stats page to be updated.

Also Deepbit doesn't find every block.  So a round may encompass several blocks worth of hashing and those shares are paid by the one block that got solved at the end.

Also when I first started mining I was switching my miner between Proportional and PPS whenever the luck shifted and the share count shows both share types for the block/round but only calculates pay based on the Proportional shares so it made it look like I was getting paid less when in reality I wasn't.

So it would seem to me that you need capture the share count for the round which may be more than one block long and match up the actual times so as not to be confused by the delay, if that's the case.

Anyway just some random thoughts, don't know if it has any bearing on your issue,
Sam

[slush]

Also Deepbit doesn't find every block.  So a round may encompass several blocks worth of hashing and those shares are paid by the one block that got solved at the end.

This can be easily verified by calculating shares for every bitcoin block (user is receiving prevhash in LP broadcast), then wait for stats on website, pick their prevhashes from block explorer, match them with own records and then just sum together own shares from blocks mined inside of deepbit rounds.

Just my 2 cents, because it's interesting to thinking about how to check this. But personally I think that patrixiorey did some basic mistake and it isn't a problem of deepbit.

[DeepBit]

1)When i start to mine in this pool the 3 to 5 first blocks are shown in stats as i never submit a share, and i don't receive any payment for those blocks

This looks exactly like you forgot about stats delay.

2)Also in last days i put a counter for shares submited, and again start monitoring, I detected that the shares are not asigned correctly to each block resolved. The stats system take an amount of my shares subtimted to the blocks that are resolved in a few minutes, and those shares from fast blocks are asigned to the fat blocks that are resolved sometimes in hours, and as result my payment is lowered from 10 to 40% less.

No, it doesn't works this way. Check again about stats delay and check if your timezone is set correctly so you can see in stats which block was solved at that moment.

So, i also sended before a this info to the mail address shown on deepbit web, but at this moment i don't have a response...

Never received it.

[bulanula]

In other words : Move on, nothing to see here

[patrixiorey]

Scammers gonna scam. Maybe they are not scamming you but you are just "unlucky" and the counter is "fixed" just for you

Well, i never say scam, scammers, or anything like that, i'm just only asking for something that i was monitoring in last days, and i think maybe is lowering the payments...

I also want to express my respect for pools owners, I think the only thing that make grew the mining as we see today is thanks to them.

Are you sure you aren't forgetting the stats delay? Also, your "my counter" part of the graphic can't possibly measure the total amount of shares, so that is suspicious. You should rather include the beginning and end of round times.
FWIW, I do a little superficial verification that shares are counted correctly from time to time, and everything checks out.

I'm very sure that i'm not forgeting the delay stats, I have my user synchronized for my local time, -3 hours, and this is fine, the blocks are identificated correctly with blockexplorer info later when the stats are updated. The counter shows the amount of shares submited with a minimum variance (sometimes it is 100% accurate with each block, and sometimes there is a minimum variation of 10 shares at most). Yes i should include the begining and end, the table that i post is just an example. Also as i shown in the table, there aren't missed shares, the final count from a period of time is the same in both stats.

Also Deepbit doesn't find every block.  So a round may encompass several blocks worth of hashing and those shares are paid by the one block that got solved at the end.

Well, maybe there is the mismatch detected, I had understood that the blocks are solved one by one, and each block corresponded with a round and did not have the concept that in each round are resolved several blocks... so, the shares were submited simultaneously for several blocks?... Is this correct?

Also Deepbit doesn't find every block.  So a round may encompass several blocks worth of hashing and those shares are paid by the one block that got solved at the end.

This can be easily verified by calculating shares for every bitcoin block (user is receiving prevhash in LP broadcast), then wait for stats on website, pick their prevhashes from block explorer, match them with own records and then just sum together own shares from blocks mined inside of deepbit rounds.

Just my 2 cents, because it's interesting to thinking about how to check this. But personally I think that patrixiorey did some basic mistake and it isn't a problem of deepbit.

Well maybe I'm forgetting something else. The procedure that i followed for minitoring is this:

1-All workers are stoped, a window with LP broadcast awaiting for the announcement that a block is found, the counter is reseted to 0 shares.

2-When a block is found i take note of the time to identify the first block later in pool stats, i start minig, automatically starts the counter...

3-For some hours i take note, for each block anounced in the LP broadcast, each begining an end time, amount of shares submited for each block.

4-Later after a few hours, i wait for a last block announcement, when it is announced i stop minig.

5-Wait for stats update, and when i see a none announcement in the statis begin to compare....

What is missed here?

1)When i start to mine in this pool the 3 to 5 first blocks are shown in stats as i never submit a share, and i don't receive any payment for those blocks

This looks exactly like you forgot about stats delay.

2)Also in last days i put a counter for shares submited, and again start monitoring, I detected that the shares are not asigned correctly to each block resolved. The stats system take an amount of my shares subtimted to the blocks that are resolved in a few minutes, and those shares from fast blocks are asigned to the fat blocks that are resolved sometimes in hours, and as result my payment is lowered from 10 to 40% less.

No, it doesn't works this way. Check again about stats delay and check if your timezone is set correctly so you can see in stats which block was solved at that moment.

As I said above, I have not forgotten that

So, i also sended before a this info to the mail address shown on deepbit web, but at this moment i don't have a response...

Never received it.

Well, what can i tell you? I send the mail... Honestly I have no interest in harming or disturbing any pool, or anyone

In other words : Move on, nothing to see here

You want to leave my new hobby when I'm just starting ...

P/D: Sorry for my English...

[ancow]

1-All workers are stoped, a window with LP broadcast awaiting for the announcement that a block is found, the counter is reseted to 0 shares.

2-When a block is found i take note of the time to identify the first block later in pool stats, i start minig, automatically starts the counter...

3-For some hours i take note, for each block anounced in the LP broadcast, each begining an end time, amount of shares submited for each block.

4-Later after a few hours, i wait for a last block announcement, when it is announced i stop minig.

5-Wait for stats update, and when i see a none announcement in the statis begin to compare....

What is missed here?

That seems a bit overly complex and error-prone to me. LPs are sent for any blocks found on the network, not just those found by deepbit. Since a lot of the blocks are found by deepbit, your method may work well some of the time.

What you might want to do is log the exact time each share was committed, then add them up for the time intervals extracted from the stats page, obviously correcting for timezone as appropriate. (I'd suggest to both log in and set your deepbit preference to UTC, that way you can be sure you won't need to adjust anything.)
With this method, you may see a tiny amount of mismatched shares around the beginning/end of each round, but the share counts should match more or less.

[patrixiorey]

That seems a bit overly complex and error-prone to me. LPs are sent for any blocks found on the network, not just those found by deepbit. Since a lot of the blocks are found by deepbit, your method may work well some of the time.

What you might want to do is log the exact time each share was committed, then add them up for the time intervals extracted from the stats page, obviously correcting for timezone as appropriate. (I'd suggest to both log in and set your deepbit preference to UTC, that way you can be sure you won't need to adjust anything.)
With this method, you may see a tiny amount of mismatched shares around the beginning/end of each round, but the share counts should match more or less.

The announcement in my LP broadcast indicates the pool owner, so i take note, in this case, only for blocks found by Deepbit, also the counter log each share, i make some tests analizing the logs and the result is the same, the counter works well, show the same log info. Yes i could, and i already set the preferences to UTC a few times, when i take some practice there is no diference, i cant identify all blocks...

[slush]

The announcement in my LP broadcast indicates the pool owner, so i take note, in this case, only for blocks found by Deepbit, also the counter log each share, i make some tests analizing the logs and the result is the same, the counter works well, show the same log info. Yes i could, and i already set the preferences to UTC a few times, when i take some practice there is no diference, i cant identify all blocks...

Two comments:

* No, longpolling broadcasts are not only blocks done by pool, those are all blocks from Bitcoin network.
* You don't need to synchronize time or timezone at all. Everything you need is to log blockhash when it come thru LP and count submitted shares between each LP broadcasts. Not sure how you log this, but some miners prints blockhash directly to console; or it's trivial to change console output to print those hashes.

So final algorithm should looks like:
a) When LP broadcast come, write down blockhash of broadcast
b) Start counting every submitted shares for every blockhash (don't forget you're now writing down count of submitted shares for NEXT blockhash, which will be mined in future)
c) After few hours, when you'll have enough data, watch pool stats page and follow links to block explorer to see, which blocks wrote down in your logs were mined on this pool.
d) Sum together all logged shares between two block which were mined by pool - and you have exact information how many shares you submitted to pool for given round without any  need for exact time.

Example:
13:00 Block 1234abfb... broadcasted
13:00-13:30 30 shares submitted
13:30 Block 2345bdf... broadcasted
13:30-13:35 5 shares submitted
13:35 Block 3456aaa... broadcasted

Then you'll see on pool stats that only blocks 1234abfb and 3456aaa were mined by pool (those hashes are in links to block explorer). So you sum 30+5 shares and now you know that you submitted exactly 35 shares for round of block 3456aaa.

Tycho, I'm sorry once again for hijacking the topic, I just wanted to make clear some mistakes probably done by patrixiorey. I hope it's clear now and no furter comment will be necessary :-).

[os2sam]

Also Deepbit doesn't find every block.  So a round may encompass several blocks worth of hashing and those shares are paid by the one block that got solved at the end.

Well, maybe there is the mismatch detected, I had understood that the blocks are solved one by one, and each block corresponded with a round and did not have the concept that in each round are resolved several blocks... so, the shares were submited simultaneously for several blocks?... Is this correct?

No shares are submitted for one block at a time.  Lets say Deepbit solved block number 152830 then BTCGuild solved 152831 and 152832 and then Deepbit solved 152833.  So revenue from block number 152833 would pay for the shares you submitted for 152831, 152832 and 152833.

In other words : Move on, nothing to see here

You want to leave my new hobby when I'm just starting ...

P/D: Sorry for my English...
[/quote]

No I don't think he wants you to leave your new hobby.  I think he just wants you to drop the subject.  But I think it is good to trust but verify.
Sam