Once again a change of plans: I'll be there at 16:00
Looking forward to meet you all ^^

According to my own measurement there are 321 clients accepting incoming connections online over the last 24 hours. No idea on how many NATed nodes are online.

Sorry, I'll not be able to show up. My gig has been moved up and I'll have to show up earlier. I'll attend next time though ^^

[mike]: are you still up for that beer? We could meet sometime next week

Ohoh, somehow this is worrying me:


Any idea what might be causing this? I'm getting it along with a few connection errors to slush's pool

There's an idea: offer your pool over Tor
Would be a nice alternative to using Tor exit nodes and would reduce latency (bigger choice of intermediate nodes) ^^

Well the client actually is pretty easy to reimplement. The problem is the protocol which is much harder to change. The SHA1 algorithm and Elliptic Curve algorithms are in fact anchored in the protocol. So my wishlist should the protocol be designed from scratch:

• Pluggable algorithms, that can be replaced once a vulnerability is found (with a transition time, and reaggregate all bitcoins with the new algorithms by sending them to a new address)
• Network Byte ordering (Big Endian!!!)
• Not a binary protocol, or the possibility to use another transport, like JSON (right now we hash the binary content of the transaction to get the transaction hash, same for Blocks)
• Not relying only on TCP (other transports such as HTTP, SMTP and UDP would allow more people to participate and it would be harder to filter)
• Better structured network to be able to detect network partitions
• Better structured networt to scale together with the network (I already proposed dynamic degree hypercubes in another thread)

And many more to come

You'd have to be really unlucky, it would be more lucrative to just replace all ads on the Webpages you visit with it's own
The Tor Proxy would have to be custom coded to intercept your pool communication and we're far from being big enough for it to pay for the hack.

Not a really good comparison since you'd have to have the hash of the password, and we could compile a rainbow table for almost anything. One way to defeat Rainbow tables is salting the password hashes (you are salting your passwords MtGox aren't you?)

Yeah, that's exactly my problem. It was fluctuating like hell but it stabilized over time right now I have a 5 hash/s standard deviation which is incredible. I had only a 5 minute warmup phase,a 5 minute hot phase and measured the average over the 5 minute hot phase and it didn't look nice. But with a longer warmup phase it looks better. Here's my monitoring graph for the last 24h.


Notice the high fluctuation and then the stabilization to a higher average

Any chances of an open source pool?

So until now we have 1 confirmed compromised account (cryptofo) and several other reporting some strange transaction 4 days earlier.

IMHO that transaction has nothing to do with the attack at all. Could cryptofo please check the strength of the used password?

Just trying to keep panic down and get the matter resolved

Next best guess: sniffing traffic. Are you using the HTTP or the HTTPS URL to log in?

Just to add another statement: I too am seeing the Payment Process united transaction, with exactly the same time, looks a lot more like a cron job to me. If the database were compromised as some people suggested there would not be any entry, they'd just sent the money off without being so polite as to inform the users where the money went. Same for the platform compromised discussion.

My best guess is that it was in fact a dictionary attack. Could the affected people please share the strength of their password using http://www.passwordmeter.com/ to not publish real passwords on the Forum?

My account doesn't seem to be compromised since it still shows me my dollar balance like I left it a few weeks ago.

Still waiting for an official statement by MtGox

It is possible as long as you stay on a managed platform with a shared wallet (so far not really different from stock trading), but should the transactions go out to the Bitcoin network the Bitcoins used in a trade will have to cool down for a few minutes before being able to reuse them for a new trade.

All this assuming that you don't trust the other side, and wait for confirmation, should you have a closed set of traders trusting each other you can in fact create new transactions with unconfirmed coins.

Time to extend the FaQ?

Strange, with -f 10 it now gives me similar results to what I got before ArtForzz's kernel was introduced. But I have a standard deviation of ~10%! Still not perfect but I'm going to tweak my settings further

Great work ^^
We do not need to be concerned too much about adjusting the testnet difficulty since it's all throw away anyway :-)

I do have a working implementation of the protocol that uses an event driven approach to communication. It'll allow you to get real time events from the wire without having to rely on the Bitcoin client to notify you or even worse, having to pull data out of it at regular intervals.

What sort of backend are you using? A database?

Exactly, it'll return to 0 and never confirm
Btw: all transactions could be invalidated, it's just incredibly unlikely, because someone would have to fork the chain before the transaction and overtake the current chain.

I'd be in for something between 200-1000 BTC