I don't know if I have the same quirky problem, but I'm still waiting from my payout from more than 3 weeks ago:
http://multiclone.us.to:18080/user/?address=18jkF8XQHRPoNYfJKFNWnfT4Xz2sAEwkb7
http://multiclone.us.to:18080/user/?address=1GxYHKL445GiyXa2XHpQHzDqr4ixeemSSB
http://multiclone.us.to:18080/user/?address=1B5dUoXDzF1EamzxLejWW2Z7uty5VepYff

May you look into that?
Thanks.

Well, actually I was talking about individual shares. Of course that's a few 100 MiB for longer rounds. But it would be enough to keep them online for 10 days or so. And they compress really well. The individual shares are needed to check if the scoring works. And I think the pool will change to difficulty-2-shares somewhen anyway, that would again half the size.

Of course that should not hinder you to also provide nice aggregated statistics. 

[edit:] Maybe I could volunteer then to write some python or perl script that does some statistics on the dump file if there are requests.

I think it would be enough to put the score next to every share. It should be possible for everyone to recognize it's own shares. So you would publish the parameters for the algorithm (I know, you already did, but on the homepage or somewhere where it can be easily found) and how the miner can identify it's shares. I think that just hashing the workers user name would be anonymous enough.

With this information everyone can verify that every share got the right score and if the relation of his/her sum of scores and the payout conform. Actually, I never did that yet. But that's because I assumed that Meni himself checked this at Continuum. 

Sorry, I thought that's a known issue? I thought everybody is still waiting for the payouts. I thought this was all just a stats-page-not-yet-parsed thing.

http://multiclone.us.to:18080/user/?address=18jkF8XQHRPoNYfJKFNWnfT4Xz2sAEwkb7
http://multiclone.us.to:18080/user/?address=1GxYHKL445GiyXa2XHpQHzDqr4ixeemSSB
http://multiclone.us.to:18080/user/?address=1B5dUoXDzF1EamzxLejWW2Z7uty5VepYff


Well, that's new. Are my really old shares also affected?

Well I didn't think that the pools are so childish to ban multipool/multiclone. They should fix their scoring instead of hunting down those few hoppers that they can identify. That's really stupid.

That's true, of course.

Nick, I know that you are doing this as a favor. It's just that original Multipool went down, promised to pay out, but didn't yet. So I have about 25000 shares pending there. And now it's similar here. Two thirds of my shares are not payed yet. In this case it doesn't help much to have a efficiency of 1.2ish. That's still a huge loss.

It's probably that I'm angry about myself being a bit naive. If you read the multipool thread, you can see that I always had faith of multipool coming back. But it seems that I was wrong and he is off with my coins. I just don't want that to happen again.

For me it's 8 days pending. That's why I didn't use this pool anymore for 7 days. I lost too many shares at the original multipool. I don't want to repeat that here.

DNS Server down.

I can't resolve your domains. But Google can?


I doublechecked that on a different machine in another country with different network.

[edit:] If you have the same problem you can reach the US server at 208.110.73.247. The EU server also doesn't respond at it's IP.

(All times in UTC)

Yes. It was working more or less from 00:17 - 03:29 and in the last half hour. Outside of those times poclbm was switching back an forth all the time. Is there a miner who writes a log-file? I'm already using -v but that's not verbose enough.

Sounds good, I'm staying here ...


Well, right now it's working, but it wasn't until a few minutes ago: (time in UTC+2)

Unfortunately I can't tell what the problem is from this output.

Looks promising: http://forum.bitcoin.org/index.php?topic=16385.msg335985#msg335985

Excellent! So which values do you use for the variables c and f?

The reason I'm asking: Continuumpool shuts down (http://forum.bitcoin.org/index.php?topic=8660.msg330007#msg330007) and this pool was also using Meni's scoring method. Now there are plenty of refugees (about 13 GHash/s) searching for a new home - probably we just found it. 

What would be nice though, would be round dumps as we had at Continuum: http://www.continuumpool.com/history/
Probably you could just use a hash of the worker name as (anonymous) identifier and produce similar output?

Regards,
tschaboo

PS: EU-server is not working for some hours now ...

Inaba,

you mention your scoring system in a few posts (#59, #112, #142) and seems you implemented it but I can't find any details! Can you please publish your algorithm?

Meni, thank you very much for your analysis. I can't judge if you are right, but I also have the feeling, somethings wrong with the MaxPPS-method. I think it would work, if old shares wouldn't count forever. If for example all shares from more than 20 rounds ago wouldn't be considered anymore such problems as you described should not arise.

Anyway, if Eclipsemc really uses your scoring method [1], my problem will be solved and you'll find me there. ;-)
Of course I'm still sad that Continuum goes away...



[1] I'm going to find out / ask and report back.

I would stay and pay the 1%.

Actually I don't really know where to go. PPS-pools are out of the question, the original Multipool is not operated anymore (and I didn't see my coins from there yet), Multiclone is also not stable, deepbit-PPS is too expensive.

Meni, would you care to comment on Eligius' new MaxPPS-system?

 

I hope somenone cares to take this fine pool over...

martok, thanks for your work.

Sorry for the most probably stupid question, but that


isn't the reason we're not finding a block, right? I mean, as long as the miners get work, everything should be okay?

Hello John,

thanks for your comments.


Regarding the build instructions: you can remove "libboost-all-dev" as it was meant as an alternative to installing the smaller packages. -all-dev includes them.

I pulled your changes but it doesn't compile because of another occurence of setPlaceholderText in the file ui_sendcoinsdialog.h generated from sendcoinsdialog.ui (addAsLabel).

Me again ...  

I was thinking more about the sending addresses in the address book and I identified two use-cases that need a different handling:

A.) In my address book I want to have addresses of my other wallets, of my girlfriend, my children, etc. I can send coins to them repeatedly and I see whom I've sent coins to in the transaction list.

B.) I'm buying something with my coins. I'm getting an address for this transaction. I will never need it again -> it shouldn't show up in the address book. But still, I want to see in the transaction list, what I spent those coins for!

This could be implemented using the same "hidden" flag as proposed for the receiving addresses.

I'm curious to read your comments.

Hello John, hello everybody!

I found this thread a few days ago and finally had the time to build it and try it (on testnet). I'm trying to dump all my thoughts about it here ... sorry for being so unorganized.

1.) John & Co: thanks for doing this. I think the bitcoin-community is now huge enough to deserve a better GUI 
2.) Even though I'm a Gnome user I think Qt is the right choice for the GUI, it's relatively high-level and allows to write readable code. And the platfom-support is very good.
3.) I'm not that experienced with build-systems but my colleages advised me to only use autotools if it's really necessary or you are already fluent in using them, otherwise there are less frustrating options, cmake was mentioned explicitly; autotools was called obsolete. Maybe we should ask the core developers, why they want to use autotools and if they considered alternatives.
4.) Like others here, I also welcome the removal of this irritating "Your bitcoin address:" section, the solution here is better. But I think it's still suboptimal, because of the redundancy between address book and receiving addresses. My proposal: remove "receiving addresses" and add "Receive coins" right next to "Send coins". When the user clicks "Receive coins" you show a pop-up saying [1] "Your wallet may have an unlimited amount of receiving addresses. It's recommended to hand out a different address to everyone sending you coins, because the address is usually the only way to determine who sent you the coins. You might even want to create a new address for every transaction. Addresses are never deleted, although you may delete it from the address book, if you don't plan to use it anymore. If you later receive coins to a hidden address it will show again in the address book automatically.". Below is a checkbox "Don't show again" and an OK-button which brings you right to the receiving tab of the address book.
5.) Like mentioned in 4.) I'd like to have the delete button activated with a tooltip "Delete the selected address from the address book. You will still be able to receive coins to this address". It's clear to me that this new workflow will need a change in the backend, namely having the possibility to set an address record as "hidden" in the database. But IMHO this is worth the change.
6.) I think the "Set as default receiving address" is obsolete now? If not, please tell me what it does. (And it probably should be disabled by default).
7.) Dialog "Edit receiving address": Address shouldn't be a text field if you can't actually change it? Not sure about that though.
8.) Dialog Address Book, Tab Sending:
   a.) "Copy to Clipboard", "Edit" and "Delete" should be greyed out, if no address is selected.
   b.) If you add a new entry without giving the address (just the label) it says: "The address is already in the address book.". I think it should not even allow an entry without a valid address.
9.) Send Coins dialog:
   a.) Having a separate entry field for the [insert missing word] and [again] is a very good idea. It might save some trouble. I also noticed, that pressing "." or "," will send you to the second box. Excellent!
   b.) I'd like to suggest a different behavior for the "Add to address book"-shortcut. Remove the checkbox and the text "Add to address book". Simply add the text "Label:" right below "Pay To". The text-field for the address book entry stays disabled until the user inputs (or pastes, or chooses from address book) some address above. Now, if the address is found in the address book, just display the label from the address book. The user has the option to not touch it, or to correct the label which is automatically saved when pressing Send. If it wasn't found it shows a placeholder text with something like "Optional: Enter a label for this address to add it to your address book." If the user enters something it gets in the address book, if not not.
10.) You are giving instructions in your readme how to compile it in ubuntu. On a fresh install of Ubuntu 10.04 I needed the following not mentioned packages to get it building: build-essential, libboost-dev, [libboost-system-dev libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev | libboost-all-dev], libssl-dev and libdb4.8++-dev. Actually it didn't build, because setPlaceholderText in QLineEdit was introduced in Qt4.7 and Ubuntu 10.04 comes with Qt4.6. I commented them out.

Well, that was more to write than I expected. If you made it that far, I'd like to thank you for your attention. 
If anything is unclear, please ask. I know I understand my own "english", others might not?

[1] But please translate it to proper english first 

Well, what you should do: being transparent about incidents, informing the public as soon as possible, help investigating the issue. Looks like you did that.

What you shouldn't do: replace the lost BTC. Especially if you informed all your members right after the Mt. Gox incident to do the obvious: don't use the same passwords everywhere. Probably that loss is a good motivation for the affected people to "invest" into good passwords and that might prevent them to loose much more in the future.

What you absolutely shouldn't do: Give out your donations. They are meant to support you and the site.

Welcome back, Multipool! 


I think that would be okay, but then please merge the accounts 1NMF8V2raa6B7hE84hYm2D5Djkm2JnvM8D and 1NvfAA7TA647CNZxRpvqkKrSGEHa4oGEwA and 1QEm95rPr8EKMTqYDyQNkUHpChY8Jj8Wct into one, since I changed the payout address to get more compact statistics. It's possible, that only two of those are in your backup though.


Well, okay, they shut down your VPS, which is understandable if they think you didn't pay. But they REALLY shouldn't delete the data before - say - two weeks! Come on, that's a few GB. It's not too much to keep them until everything is worked out. That is malicious and unprofessional.


Agreed.

@Multipool: I hope you set up your pool again soon. Then it's going to be my primary pool again (currently I'm using continuum - very nice pool, but shares only have a utility of 1  )