Im curious what you are doing about the botnet?Just blacklisting wont do much, whoever is running it will direct its bots to another pool (assuming those machines are rooted too). Anyone think it would be a good idea to keep it mining, but send the payouts to some charity?

But keeping it, or redirecting it back to the thief is ok?A pool can make its own rules, no contract is signed between the pool and the miners (or bot net), I dont see the problem. A pool could donate my share to a charity, if I dont like that, I can only switch pools.

A pool can make its own rules, no contract is signed between the pool and the miners (or bot net), I dont see the problem. A pool could donate my share to a charity, if I dont like that, I can only switch pools.

... or if you have a botnet, you can DDoS the pool for making rules you don't like, which we already have enough of without asking for more.

We're now testing a CUSTOM implementation of merged mining with namecoins.

What is merged mining? Basically it means the pool gets some Namecoins in addition to the Bitcoins we're already getting, at no cost to us. In return, the namecoin network gets more hashpower confirming their transactions/domains.

Why custom? Vince's implementation inserts a proxy between pushpool and bitcoind, adding yet another untested point of failure and bottleneck. In fact, people have already begun reporting issues with it. Eligius's implementation puts all the merged-mining stuff BEHIND bitcoind, where it can be ignored if it malfunctions (while Bitcoin mining goes on as usual). Unlike most merged mining pools out there, I have taken great efforts to ensure it does not affect the Bitcoin mining in any negative way.

Distribution of earned Namecoins is still to be decided. Suggestions welcome. Long-term plans is to have it work the same as the Bitcoin mining, but that requires a rewrite (which I'm actually started working on!).

Also, on the rewrite... current plans are to support TWO reward systems:

We're now testing a CUSTOM implementation of merged mining with namecoins.

What is merged mining? Basically it means the pool gets some Namecoins in addition to the Bitcoins we're already getting, at no cost to us. In return, the namecoin network gets more hashpower confirming their transactions/domains.

Why custom? Vince's implementation inserts a proxy between pushpool and bitcoind, adding yet another untested point of failure and bottleneck. In fact, people have already begun reporting issues with it. Eligius's implementation puts all the merged-mining stuff BEHIND bitcoind, where it can be ignored if it malfunctions (while Bitcoin mining goes on as usual). Unlike most merged mining pools out there, I have taken great efforts to ensure it does not affect the Bitcoin mining in any negative way.

Distribution of earned Namecoins is still to be decided. Suggestions welcome. Long-term plans is to have it work the same as the Bitcoin mining, but that requires a rewrite (which I'm actually started working on!).

if you dont want to add registrations maybe this:you could simple add a text field where the user could enter his nmc address (and forbid any changes after it has been entered).

of course this has the drawback that some users may be forced to change their btc mining address (if someone else was faster)

if a user has not entered a nmc address you could take it as a donation.

Why custom? Vince's implementation inserts a proxy between pushpool and bitcoind, adding yet another untested point of failure and bottleneck.

Since merge-mine-proxy 0.2.2 there's chance to use this proxy only for share submits and ocassional aux update by pool software, which cannot be bottleneck at all. However yet another custom implementation is giving some chance that those versions become incompatible .

Quote

In fact, people have already begun reporting issues with it.

Because they're using naive way of putting merge-mine-proxy between pool and bitcoind. It's not necessary at all.

Quote

Eligius's implementation puts all the merged-mining stuff BEHIND bitcoind, where it can be ignored if it malfunctions (while Bitcoin mining goes on as usual).

Which can be done also with vinced's proxy version without a problem, as I did. Pleae don't spread the FUD .

Why custom? Vince's implementation inserts a proxy between pushpool and bitcoind, adding yet another untested point of failure and bottleneck.

Since merge-mine-proxy 0.2.2 there's chance to use this proxy only for share submits and ocassional aux update by pool software, which cannot be bottleneck at all. However yet another custom implementation is giving some chance that those versions become incompatible .

Quote

In fact, people have already begun reporting issues with it.

Because they're using naive way of putting merge-mine-proxy between pool and bitcoind. It's not necessary at all.

Quote

Eligius's implementation puts all the merged-mining stuff BEHIND bitcoind, where it can be ignored if it malfunctions (while Bitcoin mining goes on as usual).

Which can be done also with vinced's proxy version without a problem, as I did. Pleae don't spread the FUD .

Or maybe because nobody knows where this "merge-mine-proxy 0.2.2" is, if it's even publicly available?

That doesn't support anything but proxy, and is in fact the exact code my merged-mine-manager is based on.

1. ask proxy for actual aux using getaux method2. use this aux in getworkaux(aux) for asking directly bitcoind for new work (no proxy call here)3. filter out shares with lower difficulty than min(bitcoin difficulty, namecoin difficulty), send the rest to proxy. It still make almost no load to proxy4. If your pool detect that namecoin or proxy crashed, use latest aux for all getwork requests, so you don't need proxy.5. If you receive share during proxy outage, call getworkaux('submit', <datastring>) directly to bitcoind to submit a block6. Profit! (And without any custom code)