 Show Posts
|
|
Pages: [1] 2 3 »
|
Are you talking about each share individually or a aggregate of each score per miner? 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. |
|
|
|
Ok, finished rewriting all the scoring code in C from PHP and it's running on all servers (US, EU and PACRIM).
Can anyone more familiar with Meni's scoring system tell me what data is valuable to you as far as output goes? I will make an output for blocks like Continuum after a block is completed, but is there other scoring data that is valuable/interesting to know?
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.  |
|
|
|
If you want me to look into something like that, you're going to have to tell me your worker address. And I'm not going to explain the BTCmine issue again.
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=18jkF8XQHRPoNYfJKFNWnfT4Xz2sAEwkb7http://multiclone.us.to:18080/user/?address=1GxYHKL445GiyXa2XHpQHzDqr4ixeemSSBhttp://multiclone.us.to:18080/user/?address=1B5dUoXDzF1EamzxLejWW2Z7uty5VepYffAlso, bitcoins-lc recently froze Multiclone's account, along with several days' earnings.
Well, that's new. Are my really old shares also affected? Of course the pools are going to ban you
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. so you should have been collecting the rewards at least daily.
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. |
|
|
|
btcmine and bitcoins-lc are over 2 days still pending!
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? dig @8.8.8.8 eu.eclipsemc.com
; <<>> DiG 9.7.1-P2 <<>> @8.8.8.8 eu.eclipsemc.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7149
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;eu.eclipsemc.com. IN A
;; ANSWER SECTION:
eu.eclipsemc.com. 17638 IN A 46.137.73.24
;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jul 9 23:17:42 2011
;; MSG SIZE rcvd: 50
$ dig @8.8.8.8 eu.eclipsemc.com ns
; <<>> DiG 9.7.1-P2 <<>> @8.8.8.8 eu.eclipsemc.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 957
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;eu.eclipsemc.com. IN NS
;; AUTHORITY SECTION:
eclipsemc.com. 1682 IN SOA ns4.communityhosting.net. bovine.cowmail.org. 2011070803 900 3600 86400 10800
;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jul 9 23:17:44 2011
;; MSG SIZE rcvd: 112
Your authorative nameservers are not responding:
$ dig @ns4.communityhosting.net eu.eclipsemc.com ns
; <<>> DiG 9.7.1-P2 <<>> @ns4.communityhosting.net eu.eclipsemc.com ns
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ dig @bovine.cowmail.org eu.eclipsemc.com
dig: couldn't get address for 'bovine.cowmail.org': not found 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. |
|
|
|
Are you still getting the errors as of this post?
(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 ... As far as the EU server goes - there are people connected to it and submitting shares. What error are you getting?
Well, right now it's working, but it wasn't until a few minutes ago: (time in UTC+2) eu.eclipsemc.com:8337 07/07/2011 17:38:28, Setting pool XXXXXX_X @ eu.eclipsemc.com:8337
eu.eclipsemc.com:8337 07/07/2011 17:38:28, Attempting to fail back to primary pool
api.bitcoin.cz:8332 07/07/2011 17:38:33, Setting pool XXXXXX.X @ api.bitcoin.cz:8332
api.bitcoin.cz:8332 07/07/2011 17:38:33, Still unable to reconnect to primary pool (attempt 4), failing over
api.bitcoin.cz:8332 07/07/2011 17:39:26, 831cccc6, accepted
api.bitcoin.cz:8332 07/07/2011 17:39:37, 98f64c76, accepted
api.bitcoin.cz:8332 07/07/2011 17:40:01, f25431d9, accepted
api.bitcoin.cz:8332 07/07/2011 17:40:09, 29c5be14, accepted
api.bitcoin.cz:8332 07/07/2011 17:40:28, b69a9207, accepted
api.bitcoin.cz:8332 07/07/2011 17:41:53, d3873a62, accepted
api.bitcoin.cz:8332 07/07/2011 17:42:04, c50e060d, accepted
api.bitcoin.cz:8332 07/07/2011 17:42:25, 087cdb44, accepted
eu.eclipsemc.com:8337 07/07/2011 17:44:57, Setting pool XXXXXX_X @ eu.eclipsemc.com:8337
eu.eclipsemc.com:8337 07/07/2011 17:44:57, Attempting to fail back to primary pool
api.bitcoin.cz:8332 07/07/2011 17:45:02, Setting pool XXXXXX.X @ api.bitcoin.cz:8332
api.bitcoin.cz:8332 07/07/2011 17:45:02, Still unable to reconnect to primary pool (attempt 5), failing over
api.bitcoin.cz:8332 07/07/2011 17:45:08, 97b47e83, accepted
api.bitcoin.cz:8332 07/07/2011 17:45:12, 470ed549, accepted
api.bitcoin.cz:8332 07/07/2011 17:45:34, 4e60bd05, accepted
api.bitcoin.cz:8332 07/07/2011 17:47:00, 4d9dfb3b, accepted
api.bitcoin.cz:8332 07/07/2011 17:47:42, 58bab409, accepted
api.bitcoin.cz:8332 07/07/2011 17:47:43, 7a0da52e, accepted
api.bitcoin.cz:8332 07/07/2011 17:49:03, 52565484, accepted
eu.eclipsemc.com:8337 07/07/2011 17:52:11, Setting pool XXXXXX_X @ eu.eclipsemc.com:8337
eu.eclipsemc.com:8337 07/07/2011 17:52:11, Attempting to fail back to primary pool
api.bitcoin.cz:8332 07/07/2011 17:52:16, Setting pool XXXXXX.X @ api.bitcoin.cz:8332
api.bitcoin.cz:8332 07/07/2011 17:52:16, Still unable to reconnect to primary pool (attempt 6), failing over
api.bitcoin.cz:8332 07/07/2011 17:52:20, d260c4fa, accepted
api.bitcoin.cz:8332 07/07/2011 17:53:54, f76e2c85, accepted
api.bitcoin.cz:8332 07/07/2011 17:56:07, df858b59, accepted
api.bitcoin.cz:8332 07/07/2011 17:57:04, 74298ea5, accepted
api.bitcoin.cz:8332 07/07/2011 17:57:15, 1ef04616, accepted
api.bitcoin.cz:8332 07/07/2011 17:57:31, 8769c239, accepted
api.bitcoin.cz:8332 07/07/2011 17:58:24, 80c620ce, accepted
eu.eclipsemc.com:8337 07/07/2011 17:59:19, Setting pool XXXXXX_X @ eu.eclipsemc.com:8337
eu.eclipsemc.com:8337 07/07/2011 17:59:19, Attempting to fail back to primary pool
eu.eclipsemc.com:8337 07/07/2011 17:59:21, f998fc18, invalid or stale
eu.eclipsemc.com:8337 07/07/2011 18:00:02, 93921bb7, invalid or stale
eu.eclipsemc.com:8337 07/07/2011 18:00:46, 8dda2ba0, accepted
api.bitcoin.cz:8332 07/07/2011 18:01:35, Setting pool XXXXXX.X @ api.bitcoin.cz:8332
api.bitcoin.cz:8332 07/07/2011 18:02:48, 470affb0, accepted
api.bitcoin.cz:8332 07/07/2011 18:03:23, b766c482, accepted
api.bitcoin.cz:8332 07/07/2011 18:04:07, 76b55c97, accepted
api.bitcoin.cz:8332 07/07/2011 18:04:16, ba0a0cc1, accepted
api.bitcoin.cz:8332 07/07/2011 18:04:31, 145ac1c3, accepted
api.bitcoin.cz:8332 07/07/2011 18:04:46, 3b765ef6, accepted
api.bitcoin.cz:8332 07/07/2011 18:04:48, 50e48afa, accepted
api.bitcoin.cz:8332 07/07/2011 18:08:14, e6e85b60, accepted
eu.eclipsemc.com:8337 07/07/2011 18:08:15, Setting pool XXXXXX_X @ eu.eclipsemc.com:8337
eu.eclipsemc.com:8337 07/07/2011 18:08:15, Attempting to fail back to primary pool
eu.eclipsemc.com:8337 07/07/2011 18:09:55, ed952462, accepted 0 2
eu.eclipsemc.com:8337 07/07/2011 18:10:39, 96c10445, accepted
eu.eclipsemc.com:8337 07/07/2011 18:10:55, fbc1f900, accepted
eu.eclipsemc.com:8337 07/07/2011 18:11:00, 4e44d940, accepted Unfortunately I can't tell what the problem is from this output. |
|
|
|
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.
|
|
|
|
Have you considered taking a fee for the pool? Maybe something like f=c=0.005 (1% average). I don't know if many people would mind, and it might make it worth your while even without participating yourself.
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? |
|
|
|
Sorry for the most probably stupid question, but that <br />
<b>Warning</b>: fopen(http://rpc.continuumpool.com:8330/rpc) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: HTTP request failed! in <b>/home/bitcoin/web/www/jsonRPCClient.php</b> on line <b>132</b><br />
<br />
<b>Fatal error</b>: Uncaught exception 'Exception' with message 'Unable to connect to http://rpc.continuumpool.com:8330/rpc' in /home/bitcoin/web/www/jsonRPCClient.php:140
Stack trace:
#0 /home/bitcoin/web/www/roundstart.php(5): jsonRPCClient->__call('roundstart', Array)
#1 /home/bitcoin/web/www/roundstart.php(5): jsonRPCClient->roundstart()
#2 {main}
thrown in <b>/home/bitcoin/web/www/jsonRPCClient.php</b> on line <b>140</b><br />
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. 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.
I'll update the instructions... I've also changed the placeholders to only be compiled for Qt 4.7+. 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! What would be the fair way to fill in the blanks - would miners assent if I distribute the last day's earnings to the miners in proportion equal to their previous day's work? Tough luck though for the guy with the thousand pending shares and one confirmed . 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. They did send notice. On Friday evening. And the server went down sometime Saturday/Sunday. Since I don't have proof of malicious intent, I am not going to libel them. Just something to be on the lookout for when VPS shopping.
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. WTF! Please tell us which host this is. Everyone should stop using it. Shutting down and deleting your instance without notice, that's just unacceptable.
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 ) |
|
|
|
|
