[9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining

[firefop]

I've thought of a few possibilities to bring some form of PPS back without needing large reserves. One approach might be to split the 25 BTC reward so that 5BTC is distributed via PPS and 20  BTC via DGM (or whatever split). A single share gets a PPS payment computed from the value of the 5 BTC and a DGM share at the value of the 20 BTC. At 5 BTC provided for PPS and a 5% fee the pool would need a 230 BTC reserve to cover that with a 1 in 100 risk of ruin. This provides at least some regular, no need to wait for a block, type of earning with a chunk that becomes available when a block is found via DGM. The split could be adjusted based on reserves the pool has. What are the thoughts of something like this?

Please don't take this the wrong way doublec, I'm not trying to be mean or sarcastic here or anything, and do love the simplicity and elegance of your pool's website (which is the primary reason I've stuck around even when the pool has had issues or lower pps rate than other pools). But...

In traditional businesses most keep at least 3 months and 12 months of funding sitting around ready to be used... when a business struggles and has to go into credit to make payroll that's a sure sign that it's being mis-managed.

That being said:

I assume that you started out with some reserve to cover the pps payouts - and that over time that reserve has become depleted (either through growth or bad luck re:block generation). I also assume that you've been making some sort of income off the pool (otherwise why would you desire to continue at all). If both of those are correct then it comes down to mismanagement on the business side of things. Either through not taking enough control over the amount of hashing allowed at your pool (so you could keep smaller reserves) or through profit taking rather than building up your reserve as the pool hash-rate grew.

I am very sympathetic to either of these situations, it is a challenge that every business manager runs into sooner or later. The traditional ways of dealing with it are either taking a loan out to cover the operating costs needed (if you have faith in the process changes you'll make to fix it) or going out of business.

and while ~3000 btc would at current market value be a huge loan - I would consider funding your reserves. But of course, I'd have to be getting something in exchange, as well as being made aware on the entire process and how much income you're actually making or have made from the pool. If you aren't willing to disclose this information I have a couple of other ideas that we could go over on how to build up your reserve quickly (with the consent of your miners) in a fair way that I suspect most of them would be enthusiastic about.

But if the situation is different than I've described above, there's no point to you operating at a loss - just leave it as DGM and tell me to get lost.

[1714109954]

1714109954

[1714109954]

1714109954

[1714109954]

1714109954

[roy7]

Guess I'm mining at backup pools until the pps side comes back. Always sad when a good pool can't stick to an easy to understand payment system.

If you can provide the funds for the reserve I'll switch it on now.

I'm not sure what DGM settings you are using, but if you want to offer a PPS style system you could go with f=-1 (and whatever c and o are supposed to be for that, I think Meni provides an example) which still pays people per share and out of your pocket on a long round once a block is found, but a lot less variance and operator risk.

[zapeta]

I'm not sure what DGM settings you are using, but if you want to offer a PPS style system you could go with f=-1 (and whatever c and o are supposed to be for that, I think Meni provides an example) which still pays people per share and out of your pocket on a long round once a block is found, but a lot less variance and operator risk.

This might be viable if you can figure out the settings, but I don't think you should take on any sort of risks to your financial health to operate a pool.  You definitely shouldn't agree to fund some huge buffer out of pocket just because some people want to whine about a payout scheme that isn't going to bankrupt you.

[razorfishsl]

I think if you don't sort out your pool soon, then I will be forced to  switch.


It was mining fine at a consistent 1.8GH/s until you started to fool about . Now Your stratum is continually starving my rigs of work and it is down by 50%.
Really if you are going to roll out serious modifications, then you should be doing so on a test rig rather than just throwing them at a live server.

2013-05-02 10:53:58.237   [400]   Razorfishsl_stratum_DGM:    Successfully authorized Stratum worker razorfishsl
2013-05-02 10:53:58.264   [200]   Razorfishsl_stratum_DGM:    Received unexpected Stratum response: {u'id': 10000, u'method': u'client.get_version'}
2013-05-02 10:53:58.735   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:02.462   [200]   Worker_102:    Exhausted keyspace!
2013-05-02 10:54:04.541   [350]   Worker_104:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e000000003dbaf8e de3b2f661db9796ced5ec3cae20d12b3f94e46c9a657d49b60551dd965181d5151a01aa3d:380712aa
2013-05-02 10:54:04.584   [350]   Worker_107:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e00000000f16b670 e908afb03d426faec72e865c2af83c8c7657072e162470b8fa224a9e15181d5131a01aa3d:e83cdac2
2013-05-02 10:54:05.006   [250]   Worker_104:    Razorfishsl_stratum_DGM accepted share 380712aa (difficulty 1.43710)
2013-05-02 10:54:05.275   [250]   Worker_107:    Razorfishsl_stratum_DGM accepted share e83cdac2 (difficulty 1.92376)
2013-05-02 10:54:05.338   [200]   Worker_103:    Exhausted keyspace!
2013-05-02 10:54:06.554   [350]   Worker_108:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e000000008f508d2 17634e141205c903dbb33db1f9386eb6a648805fb2ebdb49291d158645181d51e1a01aa3d:98746db7
2013-05-02 10:54:07.015   [250]   Worker_108:    Razorfishsl_stratum_DGM accepted share 98746db7 (difficulty 3.67269)
2013-05-02 10:54:09.006   [350]   Worker_104:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e000000003dbaf8e de3b2f661db9796ced5ec3cae20d12b3f94e46c9a657d49b60551dd965181d5151a01aa3d:b978a7d4
2013-05-02 10:54:09.470   [250]   Worker_104:    Razorfishsl_stratum_DGM accepted share b978a7d4 (difficulty 6.70452)
2013-05-02 10:54:10.994   [200]   Worker_107:    Exhausted keyspace!
2013-05-02 10:54:13.551   [200]   Worker_104:    Exhausted keyspace!
2013-05-02 10:54:14.163   [200]   Worker_108:    Exhausted keyspace!
2013-05-02 10:54:16.521   [200]   Worker_106:    Exhausted keyspace!
2013-05-02 10:54:25.298   [200]   Worker_101:    Exhausted keyspace!
2013-05-02 10:54:27.653   [200]   Razorfishsl_stratum_DGM:    Stratum connection died: Traceback (most recent call last):

013-05-02 10:54:29.793   [400]   Razorfishsl_stratum_DGM:    Successfully authorized Stratum worker razorfishsl
2013-05-02 10:54:30.090   [400]   Razorfishsl_stratum_DGM:    Successfully authorized Stratum worker razorfishsl
2013-05-02 10:54:30.105   [200]   Razorfishsl_stratum_DGM:    Received unexpected Stratum response: {u'id': 10000, u'method': u'client.get_version'}
2013-05-02 10:54:30.106   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:30.106   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:30.585   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:30.603   [200]   Worker_103:    Exhausted keyspace!
2013-05-02 10:54:37.838   [200]   Worker_107:    Exhausted keyspace!
2013-05-02 10:54:40.395   [200]   Worker_104:    Exhausted keyspace!
2013-05-02 10:54:41.007   [200]   Worker_108:    Exhausted keyspace!
2013-05-02 10:54:47.200   [200]   Worker_106:    Exhausted keyspace!
2013-05-02 10:54:52.993   [200]   Worker_102:    Exhausted keyspace!
2013-05-02 10:54:55.869   [200]   Worker_103:    Exhausted keyspace!
2013-05-02 10:55:00.122   [400]   Worker_106:    Mining Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e00000000096c1c9 7cfa4008c3f7d17e5b37f635013a38577af7393a8683542abcb39f70c5181d5811a01aa3d
2013-05-02 10:55:01.090   [200]   Worker_101:    Exhausted keyspace!
2

and so on.......

and yet the  non DMG strat is fine with no dropout:

2013-05-02 10:38:18.494   [400]   W1:    Mining Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d
2013-05-02 10:38:21.889   [350]   W1:    Found share: Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d:a82f4d22
2013-05-02 10:38:22.347   [250]   W1:    Razorfishsl_stratum accepted share a82f4d22 (difficulty 1.22497)
2013-05-02 10:38:29.267   [350]   W1:    Found share: Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d:bd6ffe6c
2013-05-02 10:38:29.726   [250]   W1:    Razorfishsl_stratum accepted share bd6ffe6c (difficulty 4.75615)
2013-05-02 10:38:36.869   [350]   W1:    Found share: Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d:bad706ba
2013-05-02 10:38:37.317   [400

[doublec]

and yet the  non DMG strat is fine with no dropout:

Can you give me the exact servers you are connecting to. There is no "non DMG strat" anymore.

[juhakall]

Can you explain the prolonged low luck? Over a period between Jan 17 to May 1, blockchain.com shows pool luck at 60 percent. Statistically this just doesn't seem likely.

That site claims that Eligius has had ~250% luck over the same period, with a total of 273 blocks. Why would you even consider Bitparking if you believed that site, Eligius is clearly enjoying some divine luck.

[razorfishsl]

and yet the  non DMG strat is fine with no dropout:

Can you give me the exact servers you are connecting to. There is no "non DMG strat" anymore.

K there Is something wrong.


IF I submit EVERYTHING on the PPS section (yep i know it does not exist as PPS)

mmpool.bitparking.com:15098

my mining rate and credit is WAY higher using the same equipment (it is currently creeping up >1.65GH/s)
 Because I have a couple of boards out I'm working on.
It should settle just < 2.0GH/s for this rig with a full load of boards.


stratum2.bitparking.com:4333 (what I call DGM)

gives all the errors and about 1GH/s, even with a full complement of boards (which is why I Fruitlessly spent the last 3 hours faultfinding)



stratum2.bitparking.com:3333

is also 'fine' if not loaded up with work, I.E if I start throwing load at it, then it starts to fail

Code:

PING stratum2.bitparking.com (50.116.38.44): 56 data bytes
64 bytes from 50.116.38.44: icmp_seq=0 ttl=56 time=228.456 ms
64 bytes from 50.116.38.44: icmp_seq=1 ttl=56 time=229.857 ms
64 bytes from 50.116.38.44: icmp_seq=2 ttl=56 time=229.272 ms
64 bytes from 50.116.38.44: icmp_seq=3 ttl=56 time=229.027 ms
64 bytes from 50.116.38.44: icmp_seq=4 ttl=56 time=229.550 ms
^C
--- stratum2.bitparking.com ping statistics ---
6 packets transmitted, 5 packets received, 16.7% packet loss
round-trip min/avg/max/stddev = 228.456/229.232/229.857/0.477 ms

Code:

PING mmpool.bitparking.com (206.71.179.116): 56 data bytes
64 bytes from 206.71.179.116: icmp_seq=0 ttl=53 time=194.617 ms
64 bytes from 206.71.179.116: icmp_seq=1 ttl=53 time=193.556 ms
64 bytes from 206.71.179.116: icmp_seq=2 ttl=53 time=194.526 ms
64 bytes from 206.71.179.116: icmp_seq=3 ttl=53 time=194.527 ms
64 bytes from 206.71.179.116: icmp_seq=4 ttl=53 time=194.383 ms
^C
--- mmpool.bitparking.com ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 193.556/194.322/194.617/0.390 ms

Code:

PING stratum.bitparking.com (206.71.179.116): 56 data bytes
64 bytes from 206.71.179.116: icmp_seq=0 ttl=53 time=193.621 ms
64 bytes from 206.71.179.116: icmp_seq=1 ttl=53 time=193.632 ms
64 bytes from 206.71.179.116: icmp_seq=2 ttl=53 time=194.077 ms
64 bytes from 206.71.179.116: icmp_seq=3 ttl=53 time=194.533 ms
^C
--- stratum.bitparking.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 193.621/193.966/194.533/0.376 ms

[doublec]

...stratum2 issues....

Ok, thanks. I'm going to take stratum2/dgm2 out of rotation and see if I can find out what's going wrong with those servers. It sounds like 'mmpool.bitparking.com:3333' and 'mmpool.bitparking.com:4333' are fine? You mention '15098' but that's the getwork server.

Edit: What miner are you using?

[razorfishsl]

...stratum2 issues....

Ok, thanks. I'm going to take stratum2/dgm2 out of rotation and see if I can find out what's going wrong with those servers. It sounds like 'mmpool.bitparking.com:3333' and 'mmpool.bitparking.com:4333' are fine? You mention '15098' but that's the getwork server.

Edit: What miner are you using?

That is what I am saying the results are not consistent, the 'get work server' should be 'worse', but it seems it is the most stable.
mmpool.bitparking.com:3333 .. seems to be ok

The miner software is:
https://github.com/TheSeven/Modular-Python-Bitcoin-Miner

Yep I know it is Gash and it is python... but none of the other mining software give me the 'simplers232' RS232 interface
which I use because it is easy to implement in the FPGA's (i know it works, so it is one less thing to check)
I've not found anyone who will   write me some C++ code for a plugin so i can use another  miner

[doublec]

That is what I am saying the results are not consistent, the 'get work server' should be 'worse', but it seems it is the most stable.
mmpool.bitparking.com:3333 .. seems to be ok

It looks like there's a network issue between the 'stratum2' server and the pool backend which is causing the problem. I'm looking into it but in the meantime I'll disable the stratum2 functionality. I've changed the DNS to point to the mmpool server and will shut it off when it has propogated. Thanks for pointing out the issue!

Edit: I'll also try the same mining software you are using to see if there's some incompatibility.

[doublec]

There's now a #mmpool irc channel on freenode irc for those that want to discuss the pool or get support.

[Dhomochevsky]

I think there is something wrong with the pool... or does the time counter reset after 24 hours? I'm shown a new round began about 25 minutes ago, yet the paid rounds table doesn't show it, like it didn't actually finish. I'm not seeing the amount credited either in my payments area. Best explanation I think is a quirk of the timer or something... so, what's this about?

[gektek]

I think there is something wrong with the pool... or does the time counter reset after 24 hours? I'm shown a new round began about 25 minutes ago, yet the paid rounds table doesn't show it, like it didn't actually finish. I'm not seeing the amount credited either in my payments area. Best explanation I think is a quirk of the timer or something... so, what's this about?

It's a roll over issue...round has been going for 24 hours plus 25 minutes... EXTREMELY bad string of luck for the pool right now

[Chemicalbro]

Hate to say it, but this is why I prefer PPS (and came to this pool).

Quite a bit of bad luck lately. Sure you can say it'll even out, but I don't see it that way.

At any point of time and looking to the future, you can assume the luck will be even from there on out. So if we've seen bad luck for the last little while, looking ahead from now doesn't mean that it should be lucky and make up for it. Looking ahead in time it should be even, and the last bad luck is a loss. Maybe I'm over simplifying.

[doublec]

I think there is something wrong with the pool... or does the time counter reset after 24 hours? I'm shown a new round began about 25 minutes ago, yet the paid rounds table doesn't show it, like it didn't actually finish. I'm not seeing the amount credited either in my payments area. Best explanation I think is a quirk of the timer or something... so, what's this about?

The timer wrapped. I'm not showing days, I'll add that. I didn't think it'd be much of an issue when the pool was 5+Th/s

The low hash rate makes it look like this is a long block. Luck is currently 30% (that's difficulty divided by number of shares). That's not excessively long. We've had luck lower than 15% before. But that was at a higher hash rate so the actual time for the round was only 12 hours or so. Now it seems much worse because of the longer time to solve.

[doublec]

Hate to say it, but this is why I prefer PPS (and came to this pool).

Quite a bit of bad luck lately. Sure you can say it'll even out, but I don't see it that way.

At any point of time and looking to the future, you can assume the luck will be even from there on out. So if we've seen bad luck for the last little while, looking ahead from now doesn't mean that it should be lucky and make up for it. Looking ahead in time it should be even, and the last bad luck is a loss. Maybe I'm over simplifying.

You are pretty much correct. Past events have no effect on future events. You can't jump onto an unlucky pool based on an assumption that their luck must turn and therefore you'll be mining at a lucky period for example. Even if you prefer PPS this is bad for a PPS pool you mine at. Then the pool takes on this bad luck and eventually disappears.

[doublec]

I've fixed the duration wraparound.

[jinyan0072005]

BQX15yoCQcjCQdK6XQrgbVJAmq5qQc7zyj

[Dhomochevsky]

Well, long stretches of bad luck like these, especially when they occur to a smaller pool can really put it down. Since you removed pps the pool hashrate went down 80 percent (!).  I don't care about the payout method one way or another, but it's fairly frustrating, even for me, to see 40 hrs without a block. On a larger pool with a more constant rate of block generation, in the last 2 days I would've had over 12 btc by now. Since I chose to stick to Bitparking, I only have 2,8. I can feel that loss and I realize it will most likely not be returned by better luck in the future. I'll stick to Bitparking for now, but no amount of alt coins being merge mined can hedge such losses.

[davebodger]

When viewing the DGM Estimate on the http://mmpool.bitparking.com/blockstats stats page, I noticed that the longer this block runs for the higher the estimate is getting.
Is this correct?
Surely the length of time it takes to solve the block has no bearing on the reward?

Not currently feeling very lucky at 23%