Sorry, guys, I accidentally turned on var diff on port 8332. Fixed. I guess ztex btcminer only supports diff 1?

I have been watching port 9000 to make sure that noone left a cgminer unattended and getting everything rejected. Since that's not the case I will leave GBT up for testing.

GBT (getblocktemplate) testing is up on port 9000.

Testing so far:

cgminer isn't sending a workid and so every proof-of-work is rejected with the message "unknown-work". Have to look into this.

bfgminer works. But it occassionally says "Failed to get next data from template; spinning wheels!". It also sometimes says the pool is issuing old work right after a block change. Not sure yet what causes this.

Not much point testing cgminer (2.9.3) further before the workid issue is resolved. But please do test bfgminer and any GBT proxy you may have. Let me know how it runs.

There's a nice and friendly guide for how to clear the java temporary files here: http://www.java.com/en/download/help/plugin_cache.xml

If you're not on Windows you can use at the command line to get to the java control panel. That works on Windows too.

Maybe this can help:

http://bitcoin.stackexchange.com/questions/360/what-are-the-bandwidth-requirements-of-a-mining-rig

With rollntime and variable difficulty BitMinter client will use very little bandwidth. Even a bit less in the future when I add Stratum support.

My name is DrH and I paid for approve of this message. Thanks

Not yet. Here's the status right now:

Variable difficulty is still only in testing on port 9000. Waiting with putting that on port 8332 since hashpower.com doesn't support var diff yet. If ASICs hit the market soon then I will of course turn on var diff.

GBT (getblocktemplate) is almost ready for testing. Will be up on port 9000 soon.

Stratum is next on the list.

Fixed. Lots of coins just went out.

The payments got stuck last night. All payments for blocks were set up as usual but were not being processed, so coins did not go into user accounts. Some blocks were showing in the block list with negative number of confirmations remaining and prepay was not working either. This has now been fixed, user accounts credited and payments have gone out for those who are above their auto cash out threshold.

Apologies for the late payouts.

Payouts appear to be stuck. Working on it!

Nice service. You can go the oppsite way of the mobile apps with this and fill a big screen with loads of stats.

Thanks for adding BitMinter templates!

BitMinter now supported at http://json.karasoft.com/ with predefined templates. While BTCmon and Bitcoinium are great on phones, this one is perfect on big screens - it can show a lot of information at the same time and is very configurable.

I added a new menu on the bitminter website, "tools" -> "third party apps", where you can find the apps and sites with BitMinter support.

Yep. Thanks for the hint on that one. Works much better than Nagios just telling me something is broken.


Working on it. I wanted to see first how Monit worked out, and it is looking great. I could get used to this sort of hands-off server administration.

I'll have to add pidfiles for my own apps - I don't think Monit will work right without those.

namecoind managed to deadlock itself AGAIN.

Did anyone notice? No? Because Monit just killed and restarted it. Monit is an awesome tool

This should allow us to keep namecoins for a while without issues. But if namecoin is no longer maintained and security problems start to appear then it's good night namecoin. In my opinion namecoin has a lot of potential, but if developers don't keep working on it then it becomes a security risk running old unmaintained software. Let's hope they don't let it end like that.

That's the plan, and I don't see any reason why it wouldn't work out.

By the way, there's a thread at https://bitcointalk.org/index.php?topic=123607 and petition at http://www.change.org/petitions/six-interbank-clearing-include-a-symbol-for-bitcoin-in-iso-4217 to get bitcoin an ISO-standard three-letter currency symbol. Seems like a good idea.

Signed 

So if I create two contradicting transactions, send one to pool X and the other to other nodes on the network, then miners would see pool X as the odd man out and stop mining there?

I'm not trying to be annoying, I'd just like to see one example where this works and isn't easily abused.

My thinking so far is that the best we can do is "allow small forks because they happen naturally, but never help create large forks." Perhaps that's good enough.

I missed something about SatoshiDice. If they always make sure that the output of your betting transaction is one of the inputs for the transaction paying out your winnings then you can't both get the winnings and your bet back. But you can still take your coins back if you lose. So you'd win almost every bet, except when the block for your Finney attack is orphaned.

Anyway, my point was that if you can't create an automated way to make Bitcoin/mining safer by use of the transaction data while mining, then it makes no sense for it to be mandatory to push all that redundant data back and forth.

You can mine the block displacing your bet first. After you successfully create the block, hold it back. Now you place some bets and get a winning payout from SD. Finally you release the block to the bitcoin network, getting your bet back as well. (= Finney attack)

Sometimes your block will be orphaned and your bet will be lost. But in most cases you get the winnings (if any) AND your bet. An orphaned block also means losing 50 BTC (soon 25), and holding a block back increases the chance of that happening. But if each of your blocks contain bets for hundreds of bitcoins then the profits should far outweigh those occasional losses.

I don't see any way for GBT to fix this. Services just have to stop accepting payments at zero confirmations.

Less than 6 confirmations should involve only very small sums. I think in that case it would be good enough to detect after the fact. So a mining pool may be able to help someone pull off a 1 bitcoin "heist". But it would have huge consequences for the pool afterwards.

In the case of 0 conf it may be necessary to have some miners detecting it as it happens. I'm not sure if there is any evidence otherwise. But what if you spread 2 conflicting transactions to different parts of the bitcoin network. When a pool creates a block with one of those transactions it may look like a Finney attack, while the pool is really just including the transaction it sees. Anyone can do this to make a pool look evil, so detecting something like that doesn't actually mean anything.

Is SatoshiDice really 0 conf? So if you have some hashpower you can easily defraud them of large sums using a Finney attack?

I always thought about defenses against this in the direction of deciding which fork to build on. So if you have your own bitcoind or public service that you trust, you can refuse to help a pool build more than 2 blocks on a fork parallel to the "main chain" as defined by your trusted source. This should make 6-confirmation double spends practically impossible if a majority of miners followed this scheme, I think?

To implement this you only need a trusted source that you can query for the current height and the block hash at height X. It should work even with getwork as you only need the "prevblockhash" from the block you are mining. A complication is getting the prevblockhash from a block your trusted source doesn't know about (yet).

I guess you could also do this by remembering transactions from before a chain reorganization and refuse to include transactions on the new fork that send those coins somewhere else. You'd probably have to force those transactions into the next few blocks.

You could try to do both. Don't be part of a 51% attack, but if one does happen try to get the orphaned transactions into the new fork as quickly as possible. But chances are that when the chain reorg takes place there is a double spend in the new fork already, if the attacker did his job properly.

You could also use a trusted source to see that a transaction you are currently including in a block you are mining is actuallly a double spend of a transaction from a different fork. But in this case it seems easier to just refuse to deviate much from the main chain.

I think GBT would run pretty smoothly if it was allowed to skip the transactions.

What harm can a pool op do when miners don't see the transactions until after a block is created? What exactly would a "dirty job" be?

Filter out transactions? I think miners seeing this a little later is good enough.

Including transactions that should be filtered out? That assumes we should be blacklisting someone. But who/what... stolen coins?