Les offten than you saw .

I analyzed overnight logs and decided to disable free relay again. I've new version of getwork patch, will test it today and hope that it will definitely solve this irritating problem.

Because the current bitcoin does not support block maturity after 100 confirmations, I temporary disabled this feature back, too.

I also opened registration back again, there's no reason to keep it closed.

Today update:

a) Pool is accepting free transactions again, as you can see in blocks #114887 and #114890. Currently the limit is very tight, I'll monitor the situation and if everything will be allright, I'll rise the limit tomorrow. I'm especially waiting to next spam flooding to analyze logs for timings and latencies. I'm also sorry for higher occurrences of RPC errors and stale blocks in last two hours, I did few restarts of bitcoin backends.

b) Default Bitcoin client needs 120 confirmation for block to be valid, but only 100 confirmations are forced by Bitcoin network itself. Today I changed this rule, so pool is paying out blocks immediately after 100 confirmations. This improvement is targeted especially to impatient users .

Yes, this can be possible, I'm writing it to my TODO list. As I'm rendering reward graphs in javascript, for advanced users there are those data available already. You can check html source of graph page; there are dates and rewards encoded as json arrays . Of course it isn't too much user friendly

There are people who find funny that "they can" hurt the Bitcoin. Actually flood the network is two-line bash script, for example. It can be done by 10-year bored children. We cannot do anyting with spamming itself, so we have to invent some methods to live with that.

I accept that you write that only as theoretical possibility, but I'll still response to this.


The problem is real, people on #dev channel measured that processing block with 1000 spam tx on the network can block bitcoind for more than 3 seconds every 60 seconds. With current rate between 500-1000 requests/second on the pool, it is up to 3000 getwork requests timeouted or flooding servers (especially the retries from side of miners). So this is well documented problem of bitcoin client and many smart people are working on solution right now.


I noticed this in #dev channel week ago, that spammer press all people to pay fees. Actually you can search blockchain that I spent many BTC (maybe more than received) on transaction fees for sending rewards than received from the network (yes, I paid 0.01 fee even for 0.01 payout from the pool). If I'm the spammer, I could implement sendmany few days before I started spamming to save all fees for me. I implemented the sendmany as the (delayed) response for paying fees, which is quite strong evidence that I'm not a spammer .


Well, others have strong limits on accepting free transactions, too (there is limitfreerelay switch in new bitcoind). As I was probably the first person who had to solve that and I didn't know about this switch, I solved it quite radically. I'm compilling new bitcoind with limitfreerelay support right now, so the limited support for the transactions will be back today.

By the way, transactions with fees have always higher priority than free txes, so other pools/miners also accept paid tx with the priority over free one. By cutting nonfree transactions I actually don't improve the fee income. So there is no other motivation than solve technical difficulties with many second freezes on the pool.


OK, I just explained it a bit .

I like GPF, they have strong voice in Germany and they're supporting Tor. I'm also using their privacybox. When they publish bitcoin address as standard donation method, I'll send you my (3BTC) bounty even this is not an eshop.

dacoinminster, SunAvatar, thank you for your support .

Because payments are going well, I started automatic sending again. Block maturity checks and payouts are performed every hour at 0 min. First automatic payment will go at 17:00 UTC.

Not a pool block, where did you find this?


It's pool block, but your timestamp is bad, did you recalculate it for your timezone?

Time difference between BlockExplorer and pool stats (both UTC) is 13 seconds. Keep in mind that the timestamps are not identical. Block timestamp is from time when block was created (by getwork()), but pool stats are when the block was reported.


Not a pool block.

Sorry, maybe I totally missed your evidence, but I don't understand what exactly happen.

Because first two batches were processed correctly, I send the rest right now. Few thousands of BTC is on the way, expect them every minute .

Well, to be honest, I don't understand all your claims clearly, which is probably problem of my poor english. I'll try to explain a bit:


Yes, I didn't found a block for a while. Why? Because I'm probably unlucky and also I'm disconnecting my rig pretty often because of Long Polling testing.

This wallet is not mine. That explain a lot - the wallet balance is absolutely unrelated to my mining . You probably found them from link to blockexplorer on pool stats page. Two comments to this:

a) I explained in the pool thread before that there is bug in block number detection in stats page. Again: It's because I'm using many bitcoind instances. When one instance found a block and I ask another instance for current block number, it can give me incorrect answer. It isn't critical and I have too much work to do before fix it.

b) Why I should point stats page to stolen blocks?


Lol, I remember to the h00ters post, but I took it as fun. I really didn't mentioned that somebody will take it seriously and start such investigation .


Erm, why I should, as a scammer, stop scamming all of you when somebody just call me a scammer? as far as I remember, h00ters didn't tell any reason, maybe except it was unusually long round at the moment or whatever. This don't make a sense for me.


OK, I'm sending payments again (not automatically, with some delay, but it is working). You are saying that I cannot have technical troubles, right? Join us on #bitcoin-dev or watch the logs, you'll see all details about my troubles and how I'm solving that. There is nothing magical, I'm using bleeding edge bitcoin with custom changes, it may happen. You can ask m0mchil or jgarzik, two well respected guys about specific troubles which I had with payments. Again, it did not affect mining, I didn't lost single coin. You're doing problem from something which is not related to possible scam at all.


I many times claimed that pooled mining IS vulnerable from side of cheating operator and it IS trivial to scam. But nobody will do it in the way as you proposed, because he must be an idiot to scam like this. For example, there is no reason to collect all stealed blocks under one mining account, there is no reason to show those stealed block in stats and ABSOLUTELY no reason to make this mining account as top miner :-D. If you want, come to Prague, I'll show you my mining rigs (this is old version of the first one, I have two like this).


Ok, it's your opinion. Only me know the truth if I'm stealing blocks or not. So it is pointless to say anything to you; looks like you're convicted that I'm the biggest scammer around. But I hope that I explained a lot to see that IF I'm stealing blocks, I'm DEFINITELY not doing it this way.

Everything is fine, your payout has been processed and is waiting to confirmation. You can cross-check it on BitcoinCharts page.

Current status:

The issue with broken bitcoind is fixed correctly. The only one 'problem' is that people who had received payouts during yesterday(UTC) don't see those payments in 'payout history'. I'll fix it tomorrow manually. I paid out all pending "confirmed rewards" from yesterday before few minutes.

Today I also implemented "sendmany", the new way for batch payouts, which save Bitcoin network resources significantly. As it is in testing mode, I need to send payments manually for some time (one or two days) and watch if everything goes well. At this moment we're waiting to two batch transactions to be included in a block. If those two transactions will be included into blocks without problems, I'll send all pending payouts during next day.

You can also watch all pending batch payouts from the pool on BitcoinCharts. Pool transactions are usually those records with tens of addresses inside.

Pool unrelated note to sendmany transactions: This is very new feature and only few clients in Bitcoin network actually broadcast it. This means that you probably won't see transactions in your client before they have at least one confirmation. You'll see new balance in your wallet immediately after transaction will be included to block. This will get better as there will be more Bitcoin clients broadcasting sendmany transactions (probably version 0.3.21).

+1

As there is expected next slashdot wave, I closed the pool registration again. This is just precaution - I don't need yet another problem at this moment, need to sleep sometime . As the issue with transactions will be solved, I'll open registration again.

theGECK, thanks, I'll respond as I'll have free time (I have to fix payments now and run tx fix on stage, so probably tomorrow). I have (of course) strong evidence that this post is completely wrong, but I have to solve problems as they are going. As I'm scamming the pool all the time, I hope that few hours more to respond does not make a difference :-).

Payments are different problem, I'm working on it and they should go out in hours or two. Unfortunately there went break more things at the same time, I'm doing it one after one. The problem of TX spam and the crashed bitcoin node are both bitcoin client related, but unrelated each other.

I don't want answer to truthHurts here as I don't want flame here, but of course I have evidence that he's completely wrong. OK, let's talk about it in separate thread, please.

To all people - I understand that you can have some reason to complaining or for not believing me for some reason. Please start calm discussion, show me your arguments and let me talk about my arguments. It can be more constructive than showing middle fingers, really.

This problem is not related to the pool - other people (on IRC) have the same troubles. There is only the difference that I'm more on the eyes and people are more sensitive. I understand this can turn to politics. But for now it is just technical issue and the best thing to do is to solve it, not to chat about it.

I have probably the working patch already, I have to test it with my rig over the night. As this is very critical, I don't want to pull fresh patch directly to the production. I believe that people understand this (those who _want_ to understand).

OK, please create new thread (really!). This looks like loooong flame and I don't want to mix it with pool support. Thanks.