Topic: [DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too - page 104. (Read 1601412 times)

My comptuer crashed while running the DNSBenchmark but it could have been duie to my OC settings. I have since been able to connect with GUIMiner to deepbit. There were some servers I saw that DNS Benchmark was unable to connect to and I am hoping that the crash was due to poor coding of the program and not the OC of my card. I will run overnight to confirm. At least I am mining for deepbit again. Deepbit speeds are about 374 compared to 388 but that is probably just the innefficiency of polcbm over phoenix. Its livable though considering without any flags and at default clocks I was getting 300.

The worker name goes after the -u in the ufasoft miner and the url goes after the -o.  So the miner program shouldn't get them confused.  At least it never did for me.  Deepbit's main page has command line suggestions for some common miners, you might want to verify the syntax.
Sam

I am in Canada and on a third party ISP on a rogers network. They are known to do traffic shaping (rogers) which could be causing dropped packets. I am not using my connection for anything else but mining at the moment so there should not be any packets dropped. Rogers recently got in trouble for traffic shaping WOW and other games so this would not be a complete suprise to me. What is surprising is that it seems to be affecting deepbit only. I have been trying to connect for almost 2 hours to no avail. With Slush's pool most of the blocks I am mining don;t seem to mature so I have next to 0 BTC despite thousands of shares. ABCPool sounds like its similar to deepbit with the proportional mining and payment despite unmatured blocks but their registration is closed ATM. I will try that dnsbench and see if I can find anything.

If you can ping by name then your DNS should be fine.  My ping to f2.deepbit.net is also a little flaky, but the others are reliable.  I guess I would try to do a Wireshark capture to see what exactly is happening.  If you want to examine your DNS go to grc.com and download DNSbench and run it and it will show you the best DNS servers for your connection.  That's a Windoze app.

Deepbit is using TCP Port 8332 so if any of the other pools are using that same port then it shouldn't be a port blocking problem.  Maybe your ISP is blocking deepbit's IP addresses?  But that wouldn't explain why some miners work and somwwhat and some don't.
Sam

pit.deepbit.net I am getting 53ms constant through multiple ping commands (groups of 3)
f1.deepbit.net I get 52ms constantly
f2.deepbit.net could not connect a few times but the ping to that is out of whack.

Should I change my DNS from my ISPs to google? I have had some issues with connecting to some sites before using my ISPs DNS but I am not sure if I want google knowing and storing every web page and connection I make. I have been trying to connect to deepbit for the last 50 minutes with no success. Shame too since I boosted my mining speed from 340 to 389 Mhash/s.

The other pools are Slush's pool and bitcoinpool. I mainly mine on Slushs but I find the rewards are much less than deepbit on average. As far as I know they use the same port however.

Edit

Just tried Ufasoft and since the login for deepbit is your email (with @) I think it is confusing my email with the server address and I am getting 0 Mhash. So much for that idea.

I have used Ufasoft, pheonix and now CG Miner with Deepbit and haven't ever had a problem like you describe.  The other pools that you can connect to, do they use the same TCP Port as Deepbit?  Do you get a reliable continuous ping to pit.deepbit.net, f1.deepbit.net and f2.deepbit.net?
Sam

I seem to always have a heck of a time trying to connect to the deepbit mining pool. It usually takes anywhere from 10-25 minutes to be able to connect and I have had 0 success with phoenix miner (using guiminer). polcbm seems to attempt to connect more often and thats the only one I have had any success with. Any other pool I connect immediately but I would prefer to mine with deepbit due to the way their reward system works. Does everyone have this problem and does anyone have any suggestions on how to fix this other than mining at another pool?

Top miners list only includes those who are mining in teams and the teams itself. Currently there is no "global" top list for individual miners, but it may be added later.

Check the teams link at the right panel of stats page.

Hey, does Deepbit has a LEADERBOARD ? Can someone send me the link plz ?

LP occur anytime anyone in the network (not just DeepBit) finds a block.
LP can also occur for non-block reasons like including a valuable transaction (high fee), change NMC header (not used by DeepBit), a server side issue,etc.

LP *may* only issue LP when a block is found but that is a bad assumption to make AND even if it is valid an LP will be issued on any block that is found (by any pool or solo miner).

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.

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

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 :-).

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...

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.

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.


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.


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?


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?

As I said above, I have not forgotten that

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

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

P/D: Sorry for my English...

In other words : Move on, nothing to see here

This looks exactly like you forgot about stats delay.

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.

Never received it.

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.

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

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.