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

I'm actually noticing alot LOWER stales. Across 10 workers, They all used to be about 1.5+% stale. Now my highest is 0.5%, with 4 workers at 0%!

I also am seeing a significantly lower number of stales on both poclbm and phoenix (phatk).  I am guessing there is some balancing to a deepbit pool server near you (near is relative on the Internet ).

You upgraded phoenix?  To 1.48?  Or did I miss a new one?

I seem to be submitting a whole lot less stale/invalid shares lately. It could be that I upgraded phoenix, but I thought I would share, [Tycho], since you had asked if anyone's experience had changed recently.

Very odd indeed.  I assume somewhere NAT should be doing all the work for you.  What I have done is to setup QoS such that outgoing connections to 8332 are given priority over everything [even multimedia and VoIP].  For wireless [since two miners are on wireless via an 802.11n bridge [solid connection repeatedly and thoroughly tested] and I setup 8332 as priority with WISH as well, so that my Wife watching videos while syncing iTunes [files on NAS] over wireless don't interfere with MY priority traffic .  Netflix and multimedia get the 5.0GHz band so no issues there.

Perhaps nothing I have said is of help here, but I find it strange that you are setting the routing tables to make this work when NAT on the border router(s) should take care of this [minus priority].

Oh ... is your DNS honoring TTL?

No, everything is looks fine at my end.
Do you have any packet loss between your PC and the pool ?

Also, PM me your IP please.

I'm starting to get quite a few of these messages from GuiMiner using Poclbm:


2011-06-16 12:59:49: Listener for "Default": 16/06/2011 12:59:49, warning: job finished, miner is idle
2011-06-16 13:00:58: Listener for "Default": 16/06/2011 13:00:58, long poll: new block 00000b2fc502b15e
2011-06-16 13:01:12: Listener for "Default": 16/06/2011 13:01:12, long poll: new block 000006d043689583
2011-06-16 13:02:22: Listener for "Default": 16/06/2011 13:02:22, long poll: new block 00000f2ef239bbb8
2011-06-16 13:03:55: Listener for "Default": 16/06/2011 13:03:55, Problems communicating with bitcoin RPC
2011-06-16 13:03:59: Listener for "Default": 16/06/2011 13:03:59, warning: job finished, miner is idle
2011-06-16 13:06:00: Listener for "Default": 16/06/2011 13:06:00, warning: job finished, miner is idle
2011-06-16 13:06:01: Listener for "Default": 16/06/2011 13:06:01, Problems communicating with bitcoin RPC
2011-06-16 13:10:54: Listener for "Default": 16/06/2011 13:10:54, warning: job finished, miner is idle
2011-06-16 13:10:54: Listener for "Default": 16/06/2011 13:10:54, Problems communicating with bitcoin RPC
2011-06-16 13:13:25: Listener for "Default": 16/06/2011 13:13:25, Problems communicating with bitcoin RPC
2011-06-16 13:13:25: Listener for "Default": 16/06/2011 13:13:25, warning: job finished, miner is idle
2011-06-16 13:15:25: Listener for "Default": 16/06/2011 13:15:25, warning: job finished, miner is idle
2011-06-16 13:19:15: Listener for "Default": 16/06/2011 13:19:15, long poll: new block 0000008e02cfb5b9
2011-06-16 13:24:41: Listener for "Default": 16/06/2011 13:24:41, warning: job finished, miner is idle
2011-06-16 13:24:42: Listener for "Default": 16/06/2011 13:24:42, Problems communicating with bitcoin RPC
2011-06-16 13:26:14: Listener for "Default": 16/06/2011 13:26:14, warning: job finished, miner is idle
2011-06-16 13:26:14: Listener for "Default": 16/06/2011 13:26:14, Problems communicating with bitcoin RPC
2011-06-16 13:29:05: Listener for "Default": 16/06/2011 13:29:05, warning: job finished, miner is idle
2011-06-16 13:29:06: Listener for "Default": 16/06/2011 13:29:06, Problems communicating with bitcoin RPC
2011-06-16 13:30:07: Listener for "Default": 16/06/2011 13:30:07, long poll: new block 000000322cee8a77
2011-06-16 13:31:10: Listener for "Default": 16/06/2011 13:31:10, warning: job finished, miner is idle
2011-06-16 13:31:10: Listener for "Default": 16/06/2011 13:31:10, Problems communicating with bitcoin RPC

For the last 1/2 an hour.  Is this normal or due to a problem on your end or maybe mine?  Any help or suggestions would be great. As I'm typing this it seems that the whole pool when down.

Yes, the machines are on an intranet but by setting up routing rules to the deepbit.net IP I can get them to mine.

Some changes were implemented.
Report please if you feel that your deepbit mining experiense is now better or not.

Ahh thank you.  I'll add this to the FAQ.

Are you using some special routing rules for mining ? Usually this shouldn't affect users.

This link shows that the transaction is already received.
Do you see it in your wallet or not ?

Average shares per block display is automatically hidden after each difficulty adjustment because otherwise it will show some meaningless jumps up and down for a few next hours.
Will be enabled again soon.

blah, the constant changing of IP's for deepbit.net is killing me. I have to go around and change the IP in the routing table on each computer I'm mining from every time it changes,

not stable yet ?

Lol. Ok that makes more sense.. I was shocked that you put Veldy's name in that statement. He is absolutely right in what he said and i to am annoyed at all these newbies asking the same question over and over which all they had to do was look back one page and they would get there answer. Or just do a quick search. Instead they are freaking out on the forums.... He was much more polite than i was going to be before i came to his post

I meant eodchop and pennytrader.

If it is of any help to Tycho in debugging the problem, my withdrawal has been stuck for 9.5 hours again (had problems yesterday too, it was about a parameter change in Deepbit end causing it?), 0/unconfirmed and shows up in bitcoincharts as 0 priority again.

I find it interesting that the moderators are planning on banning users asking legitimate questions - if it's only Deepbit that's having problems with payments, why shouldn't people be allowed to ask about it on the forums? If the explanation given 5 or so pages ago had to do with a software bug causing the problems, obviously it's good that people report that it's happening again; How else would Tycho notice that there is a problem?

Here's the bitcoincharts info:

2011-06-15 21:00:37 81fd5135f82b829d1ea3fefb9679185ef89d52225d413aba45587dfa068a727f
This is a low priority transaction.
size: 257 bytes priority: 0 input: 100.35616430 BTC

100.35616430 BTC from unconfirmed e62d17f875d5a24c886c00ef1d1af102ae68fea023d2b7b0bc9f8367fc7c6b34:0 (12Y396c7Xk3kEKJbUnqtLMLj5MEyG9QaUh)

output: 100.35616430 BTC

    95.68616430 BTC to 1CnuiE129kiXqEDywYBHiQbNqRZASoTHs3
    4.67000000 BTC to 16XrZP4z3Q6JtBMC8MgKg9p7x3UnU3YSVF


[Edit: Added the bitcoincharts info]

No, there is a level where a fee is not charged.  I am not sure how that is determined.  Setting the fe in your client gives your transaction higher priority to get your transaction included in a block.  It is a means to facilitate a faster transaction.  As it stands now, Tycho has said that deepbit handles most of the zero fee transactions.  With the recent backlog, I am not entirely sure that can continue, but I am just speculating.  Tycho can say for sure if they can keep it up (he works miracles, so I suspect it will continue).

So when you send Coin do you always get prompted to pay the fee?  I see in the client where I can set a fee as a default, but that seems to be less than desirable.  Some transactions I would want expedited and some can wait.  So I wouldn't want to pay a fee on every transaction I create.  I guess if I were selling a good or service I could require my customer to pay a fee, but how would I know that he did?

I guess this is a little off topic, but good info.
Thanks,
Sam

The sender pays the transaction fee.  If you try to send a small amount, say 0.05BTC, you will almost certainly be prompted for a transaction fee of 0.01BTC.  Supposedly after the mining is done [and before], that will be a means of revenue generation; somebody has to continue chaining blocks and distributing them for confirmation.  If you think about it, the sender has to pay the transaction fee.  There is really no way to get it to the recipient and have them decline the fee and then send the coins back to the sender; that would be double the work for the transaction with a fee declined than with a fee accepted.  Charge the sender and there is no issue.