Me too. However a lot of people stored tens of BTC on the pool, which was the reason why I set top limit to (if I remember well) 20 BTC.

My attitude is: secure your wallet, set "send threshold" to some value which will trigger payout once per day or two and you're done. In the worst way, you'll lose one day payout. Again, no one lost single bitcent on my pool unless he breaks very basic rules of security.

Locking of addresses have many side effects. As an example, I already solved many issues when people lost their wallet. Now imagine that their wallet will be locked to this lost wallet, with significant amount of the pool balance. Should I send bitcoins to black hole even when user ask me in advance (before automatic payout triggered)? Or should I break the rule and change wallet to new one?

Actually I really think that the probability of hacking/hijacking pool account AND hacking also mailbox AND NOT hacking the receiving computer is negliable. Because when user's computer is compromited (so attacker can have easy access to mailbox and pool account), wallet locking isn't any problem for the attacker anymore, because he can steal coins directly from the computer, after the payout.

My pool offers email confirmations + users cannot change registered email. However I don't see any benefits in locking payout wallets, it's more like security thru obscurity for me.

Few moments ago I commited some stuff. Http transport is still under construction.

As a homework I implemented broadcasting transaction to Bitcoin network, it's method "blockchain.transactions.broadcast". It is using ArtForz's halfnode code for talking with trusted Bitcoin node over P2P. However no patch for bitcoind is necessary, which is significant improvement against current Electrum server implementation .

There's electrum.php in repository. Just put this to /electrum.php and configure URL inside the script (to tcp connection to localhost). I also encourage you to increase the buffer from 2048 to at least 20480. ThomasV changed that on his node already, but obviously forgot to commit it yet...

ThomasV, maybe you should mention somewhere that electrum.py needs disabled 'magic quotes' feature of PHP. I think it's default in PHP, at least in some distributions, so I needed to add "php_flag magic_quotes_gpc Off" to my .htaccess file.

Edit: bottom line - ports 80 and 443 are working on electrum.bitcoin.cz, too.

Yes, it failed in reading from config for some reason. jsonrpc library then try to ask on standard input... Unfortunately have no idea what you're doing wrong...

New Electrum server appeared at electrum.bitcoin.cz:50000 few minutes ago. Ports 80/443 are not configured yet.

Red Emerald: yes, it's only a warning and can be ignored.

John, will Abe check database consistency after startup from initial db import and check if db and local blockchain in bitcoind are the same? I mean - isn't blindly using export from some unknown entity potential attack vector?

At least torrent file have a checksum, so anybody who trust me can trust the torrent download, too. But would be nice to know that Abe is checking it by self...

The problem is that with every new round, you'll see all hashrates as 0 Mhash/s, which is mostly unusable for normal users. This is the reason why worker hashrate is hidden and you can see it only in HTML source of profile page...

Thanks!


I think that security is at comparable level with all other pools. To be honest, I see some "security solutions" more like "security thru obscurity". For example, locking payout addresses is nightmare to resolve for me as sysadmin when somebody lose his wallet and have significant amount of coins on the account. Should I leave it "as is" and potentially send his bitcoins to black hole or should I do "an exception" and change his payout address manually? Where's the point of such security option?

Actually all significant changes must be confirmed from registered email, so locking address have no sense. If anybody use same password for the pool account and for his email, it's his problem, this is not a kindergarten. If he has computer compromited (so the attacker have an access to pool account and to mailbox), then the attacker can do the payout to 'locked address' and steal coins from compromited computer. I still don't see the benefit of address locking.


Honestly, I'm trying to push people to don't keep their balance on the pool. It's a pool, not a bank and I don't want to be responsible for already mined coins. You know, my pool has no security issues so far, but a) there's no reason to keep high balances on pool b) higher balances motivate attackers...


Do you have any issue with payouts? Afaik it's 'set it up and forget', so I don't think it's necessary to check every transaction... Simply use some amount which will lead to one payout per one or two days and everything will work for you automatically...

About the hashrate - it's more technical issue, I can display 10-round average or current block average. First one has significant latency and second one is inexact. Unfortunately current pool solution don't let me provide worker hashrate in some standard way, like '30 min average'.

I very much like the idea of locking in the bitcoin and namecoin addresses for one day after updating them, as well as a notification email when a change of payout address / or even email address / account password has been made, sent to the formerly registered email address.

MORA, actually I don't know how Abe handles bitcoind's blockchain, but I would be really surprised if two initial imports of blockchain should lead to two different database structures.

This.

Actually I don't care about all potential services which can be done on top of Stratum protocol at this time, but server side storage of seeds/keys can be done. In such case, ultramegalightweight client using such feature don't need to implement any crypto part, just use Stratum server as a standard web wallet, if he wants.

Two weeks ago I installed Abe to one of my VPS because of running Electrum server. Although it's quadcore Xeon, it has poor I/O performance, so initial indexing took around four days. Few days ago, my database crashed and Abe turned into inconsistent state for some reason, which forced me to reindex whole blockchain (=another four days of waiting) again.

Because of such experience, I decided to provide a MySQL dump of Abe to public, as a torrent file. If you want to install Abe, feel free to download following file, it's clean blockchain index up to block 160095:  http://mining.bitcoin.cz/media/download/abe-160095.sql.gz.torrent . You can also help me seeding the file, of course

Two weeks ago I installed Abe to one of my VPS because of running Electrum server. Although it's quadcore Xeon, it has poor I/O performance, so initial indexing took around four days. Few days ago, my database crashed and Abe turned into inconsistent state for some reason, which forced me to reindex whole blockchain (=another four days of waiting) again.

Because of such experience, I decided to provide a MySQL dump of Abe to public, as a torrent file. If you want to install Abe, feel free to download following file, it's clean blockchain index up to block 160095:  http://mining.bitcoin.cz/media/download/abe-160095.sql.gz.torrent

Not sure why, but some miners which were reporting themselves as "phoenix" already performed some ghetto-style ntime rolling. They were using one job for many minutes, only extending the ntime, which is corrupted behaviour (miner should ask for new job even when there's no new bitcoin block, to refresh his merkle tree). Not sure if it was done by unofficial patch floating on the Internet, but I implemented few workarounds especially because of such issues with phoenix.

Bemtje: No, I even don't know i0coin project. Actually I'm not a fan of alternative currencies, because it is splittling development effort between many small projects, instead of focusing to improve Bitcoin as much as possible. There's still a lot of unused potential in Bitcoin.

I did only one exception with Namecoin, for a good reason. Namecoin mainly isn't a currency, but general-purpose decentralized key/value store. Another benefit is that Namecoin was created especially for storing non-financial data into blockchain, so existence of Namecoin keep Bitcoin blockchain (potentially) cleaner.

hashrate is generated from last 10 rounds, so it has some delay. Also btcstats.net have it's own cache, which can provide additional latency...

7 day luck average is still 102% ;-).