Yes, until this project matures a bit more (i.e. beta 0.4 is reached) it will remain a solo project.

There is a lot of complexity involved with multi chain merged mining, most of it related to shares logging, configuration, correct handling of stales etc. However, ecoinpool has partially be designed to support multi chain MM at some point in the future without having to rewrite the entire server component.

Yes, ecoinpool still crashes if the blockchain wasn't loaded by the local bitcoind/namecoind as mentioned in some posts before.

There won't be any console output except warnings, so this is normal. Try to follow the logfiles in the log folder for more detailed messages.

Yes, there should be an ebitcoin client for namecoin or the system will fall back to block change polling 5 times per second. The document update conflict seems to be a bug. Try reloading the page before you fill out the form and click save.

If only I had more time at the moment. Now I know how shadders felt back then... Got work up until night; free time is rare and when I finally have some, I rather use it to relax a bit. Looking at my deadlines, I need at least one more week before development can continue.

It's kind of funny that there are now bounties for setting ecoinpool up while I'm working on the bugs and features which will make setting up so easy that everyone should be able to do it

But well, I'm not fast enough due to real life work load.

Hello, I finally got some time to write this.

Development is proceeding slowly as my calendar is full of appointments in this month. At least I can tell you that the new server has already been purchased and was set up with some extra security measurements. However, there is no pool software running and the front-end is also far from finished.

You can find the new server temporarily at http://btcserv.p2k-network.org/ because I couldn't reach cuqa/wtfman yet (he seems to have even less time than me).

For the relaunch of BTCServ.net, we are moving in completely new directions in the areas of server programming, databases and security. An attacker will have a very hard time breaking in and also, by enforcing auto-payouts, no large amounts of Bitcoins will ever linger around on the payout server anymore. Beneath the front-end of the new BTCServ.net site, practically nothing will be the same as before.

p2k

Hallo, jetzt melde ich mich mal.

Also die Entwicklung geht nur schleppend voran, da ich einen vollen Terminkalender habe. Allerdings kann ich vermelden, dass der neue Server bereits gekauft und eingerichtet ist und schon einige neue Sicherheitsvorkehrungen getroffen wurden. Es läuft aber noch keine Pool-Software und auch das Frontend ist noch lange nicht bereit.

Der Server ist vorübergehend unter http://btcserv.p2k-network.org bereitgestellt, da ich cuqa/wtfman bisher nicht erreichen konnte (sein Terminkalender scheint noch voller zu sein).

Wir beschreiten mit dem Neuaufbau von BTCServ.net völlig neue Wege in den Bereichen Server-Programmierung, Datenbanken und Sicherheit. Ein Angreifer wird es sehr schwer haben und außerdem wird auch das berühmte Schild aufgestellt: "Einbruch zwecklos, Kasse wird mehrmals täglich geleert". Hinter den Kulissen wird kaum etwas von der alten Seite übrig bleiben.

Gruß,
p2k.

Hi,

sorry I've been busy the last days and will be away the following days too.

Cache size and work age aren't that important for ecoinpool because it can create work so fast that the cache never really gets empty.

Max work age is the time that workunits stay in the cache until they are discarded it mainly has to do how "good" you want to support new transactions coming in. On larger pools, this is never really hit, because work is requested faster than cached workunits are discarded; this could even be true for your small pool.

As for the cache size: It is not printed as an info message how the cache is refilled, you'd have to set the server logger to "debug" to see that. The fact that the number never gets below 19 is because the cache is being refilled to 20 only milliseconds after it was accessed. The value of 20 has been determined by watching the cache on a relatively big pool where the cache got below ~15 in only 2% of all cases (that's mostly on block changes, where the cache has to be drained anyway). Maintaining a cache of 20 workunits should be ok for any server as they just take a couple of cycles to make and only use a few bytes of ram.

The essence of all that I said: It's not really worth changing the default settings for those two values as what you gain from tweaking the numbers is pretty much marginal and will probably never impact work delivery at all. If you're really a perfectionist and want to save ~4kb of RAM and 100ms CPU time, then set the cache size to 10.

p2k

To quote from the README:


I'm not lying in that README, it's true!

Congratz on setting it up, so it was possible to bypass the frontend error messages involved in first worker creation. Good to know.

p2k

Thanks Graet!

And I will take this opportunity to say that ecoinpool is running on ozco.in with very special settings which are not yet covered by the built-in frontend, all of them are listed on the ticket (<- click me!). I had to help ozco.in at great lengths and most of the features on that list were actually developed to get eco to work ozco.in.

However, I will fix this up in some days (I'm currently blocked by RL jobs, shadders, your chance to catch up) making ecoinpool as easy to setup as it is meant to be and removing the pressure on me that I always have to be around if something has to be changed in the configuration etc. Yes, with ozco.in being currently the only pool which uses eco on a large basis, it's still ok for me; but I don't want to be responsible for the inner workings of all the pools in the world in the end... I'm only one guy... (yeah, ok, I claim that I'm a one-man-army, but even an army can run out of troops )

Also @Tittiez: I've heard that you want to start your own private pool with some friends. Keep in mind that ecoinpool currently doesn't have any payout mechanisms (neither do PoolserverJ nor pushpool), so you would have to manage that yourself. There is another ticket on my tracker that promises payout support for a future release, making ecoinpool the true all-in-one backend solution for mining. But - as you can imagine - it's a lot of work to get there.

p2k

This error tells us that ecoinpool could not connect to the local bitcoind. Either it is not running, or you've set it to another port than the default 8332 in your bitcoin.conf. In the later case, you can configure ecoinpool to use a different port in the CoinDaemon configuration dialog of your Subpool.

In general, ecoinpool is currently not very tolerant towards any errors you might have in your CoinDaemon configuration and if bitcoind is still loading blocks or crashes, ecoinpool will terminate as well. It is on my todo list to even this out and present you a more informative error message and let ecoinpool reconnect on errors etc.

Also, while helping EnergyVampire to set it up, I've discovered some more problems with the built-in frontend that have to be fixed. We used a not-so-easy workaround to get it running. For you and others, it would be better if you could wait until I've fixed those problems properly; you can subscribe to the tracking ticket via RSS. The first ticket entry is a blocker, as it is not possible to create your first worker properly. Please be patient, you won't regret it.

p2k

Well that actually shouldn't work because bitcoin is not fully synced to the network... if you get errors before block 166359 (at the time of writing) is reached, don't blame it on ecoinpool.

@EnergyVampire: Your issue should be fixed. Just pull the new version.

p2k

This is a simple error: CouchDB is not running or ecoinpool is unable to connect.

Ok, there was a slight design error on my part if the subpool crashes while starting. The real error message (the first error after starting) is pushed away in your console history. I've just committed a fix for that, please pull and try again, then send me the real error message.

Hi,

I've fixed the link in the original post (copy&paste fail). Here is it again, so you don't have to go back.

@Tittiez: You sent the supervisor report telling us that the restart logic has given up. Unfortunately this message doesn't provide anything about the actual error; try to scroll up and post the first error report you see instead (only the part about "** Reason for termination") - if it gets too long, consider using pastebin.com.

@EnergyVampire: Ok, thanks, I'm investigating. It has nothing to do with your browser.

p2k

Hello EnergyVampire,

you need to be able to access the ecoinpool mining port you specified from your browser. The link in that error message should directly take you there (click it!), presenting you a greeting message. If your browser cannot connect to ecoinpool in this way, you either have too restrictive firewall settings (if not running on localhost only) or ecoinpool crashed because of bad configuration or it's unable to connect to bitcoind or bitcoind is still loading the blockchain or ecoinpool is unable to connect to CouchDB and other reasons which are fatal for ecoinpool.

If you get an error message, try to paste it on pastebin.com after you read this guide and send the link as a pm here or contact me on IRC. Maybe I can help you then.

p2k

Oh yeah, sorry that I didn't mention it here. Namecoin coinbasing is implemented since two weeks. But I need some more time to fix up the buit-in frontend and update documentation.

Well, technically it does support merged mining but you cannot set a custom payout address for Namecoin yet (the getmemorypool coinbasing has to be implemented for that). Like this, the share processing scripts on ozcoin's main server would not be able to detect Namecoin blocks, because they depend on polling the local namecoind for generate transactions.

It all has to do with the multi-server setup of ozcoin, something that other pools usually don't have. If you run ecoinpool on a single site, merged mining is working fine.

PS: Thanks to all the ozcoin staff for supporting me and helping to set this up. This is the first real test in the Bitcoin world for ecoinpool.

Hi eleuthria, hi rjk,

it's nice to have some discussion going on here. I've been thinking about this "federated" or "distributed" pools idea a lot, also got some input from various chats and other sources. Here are some problems and tentative solutions or thoughts that came up, feel free to add comments:

Workers

• Sharing workers between servers is no problem if you have a database which offers replication
• CouchDB is very good at this, syncing up changes in nearly realtime; after a server crashes and recovers, all changes which have been made are grabbed from peer servers; also it offers streaming changes to applications (like ecoinpool)
• MySQL also has replication features, though I've never tried that out; polling for changes from the application would be required though
• A custom database and replication engine for ecoinpool could also solve the task of worker sharing and would be even faster

Shares and Statistics

• Besides worker configuration, all other pool services revolve around shares
• Large pools have to handle shares in masses
• CouchDB can easily get to its limit there and I wouldn't recommend it for shares storage anymore
• Having a central database would produce a bottleneck or single point of failure; only a hidden dedicated server where only the shares database is running would be ok
• The other option is to store & process shares on each server separately; however, this requires a mechanism to sum up the number of shares from each server and present them correctly to the user
• Creating long-term statistics out of short-term shares is also not an easy task; yet this could again be achieved with replication-enabled databases like CouchDB as the amount of data is reduced greatly and record sets drop in comparatively slowly
• Live monitoring is something really cool, everyone who experienced that in ecoinpool's testing phases instantly fell in love with it and wanted to keep it - but it relied on CouchDB which isn't built for monster rigs...
• Work has started on an alternative way to provide live monitoring without CouchDB, but this gets complicated if multiple servers are involved
• The current idea is to have a server-to-server protocol for shares announcement; like this, shares could be pushed via HTTP longpolling from any server to the user's browser

Daemons and Block Solves

• Current pool website software (i.e. cron jobs) detect block solves by querying a coin daemon (bitcoind, namecoind, litecoind...)
• This requires either to connect to all servers in order or having a central instance of the coin daemon or setting all daemons to the same payout address of the central server (currently not supported for namecoin)
• ecoinpool, having a built-in block monitor, could do block solve detection by itself and publish the information somewhere (block hash, Tx ID, number of confirmations, etc.) leveraging the requirement of those cron jobs

Payout

• Payout usually involve processing shares
• If not done correctly, shares could be paid out more than once
• First solution is again having a central shares database and payout
• The alternative is to let each server manage their own presumably partial payout; this is a good decentralized solution but requires some server-to-server communication to make it convenient for the user
• Different payout mechanisms put different demands on the shares database; not all payout mechanisms can be used in a decentralized way
• Legacy systems rely on existing structures (e.g. cron jobs working on SQL databases)

Hallo eckmar,

nun, es gibt bisher kein Auszahlungssystem in ecoinpool. Aber sollte es ein solches System später geben, so müsste es entweder an einer zentralen Stelle passieren oder die Bezahlung müsste von allen teilnehmenden Servern zuerst bestätigt werden. Denkbar wäre auch nur die Shares am Standort ausbezahlen zu lassen und vielleicht per Rundruf die anderen Server auch aufzufordern das Selbe zu tun; ich glaube das ist die sicherste Methode, da dann auch beim Server-Ausfall zumindest noch teilweise Ausbezahlt werden könnte.

Danke für den Hinweis. Das ist sicherlich ein guter Punkt, den ich in die Planung übernehmen kann.

Gruß,
p2k

PS: Ich habe den Thread jetzt abonniert, dann passiert das nicht nochmal.

Oh, tut mir leid. Ich war so beschäftigt mit den Tests, dass ich nicht mehr beim deutschen Thread vorbeigeschaut habe.

Also, an sich arbeitet ecoinpool mit einer verteilten Datenbank, die sich durch Replikation ständig mit seinen Nachbarn synchronisiert (was du meinst wäre eine zentrale Datanbank). Damit ist jede Instanz physikalisch autark aber gleichzeitig gibt es nur eine logische Datenbank.

Momentan arbeite ich allerdings an einer Umstrukturierung von ecoinpool. Für das Abspeichern der Shares ist die verwendete Datenbank (CouchDB) ungeeignet. Hier werden andere Möglichkeiten untersucht. Die Funktionen zur Replikation der Konfiguration und der Worker möchte ich zudem direkt in ecoinpool implementieren. Ziel ist es, dass von sich aus überhaupt keine externe Datenbank gebraucht wird (Standalone-Betrieb), gleichzeitig aber gegenüber den bestehenden Systemen eine offene Schnittstelle geschaffen wird (MySQL, PostgreSQL, CouchDB, Flatfiles).

Die Entwicklung wird noch einige Zeit in Anspruch nehmen, sich aber wesentlich auf die Qualität der Software auswirken, um sie von den Bestehenden abzugrenzen.

Gruß,
p2k

Yeah, I lust left the desert. I'm declaring it to someone else's problem. Have fun!