Bitcoin does not use UDP. It's not trivial to add a reliable UDP transport on top of a TCP-based application. Certainly possible, but usually not worth the hassle.

Bitcoinica.com has an invalid DNSSEC configuration and is not reachable for users with DNSSEC validation enabled (this is known for a few weeks).
Most ISPs do not validate DNSSEC, but a few do, like Comcast. Comcast set up a temporary exempt to allow DNS resolution for bitcoinica.com despite the DNSSEC validation failure. This exempt will be removed on Tuesday, May 29 (http://www.dnssec.comcast.net/). Thus, bitcoinica.com will be offline for Comcast users.

Test here if your DNS resolver validates DNSSEC signatures: http://dnssec.vs.uni-due.de
If the result is YES, then you're either a Comcast customer or you already can't reach bitcoinica.com (like "Could not locate remote server").

Solution: Bitcoinica has to login at their registrar and remove the two erroneous DS records (see dnsviz.net)

Workaround: add 8.8.8.8 as DNS server in your network configuration (this disables DNSSEC validation – make sure you want this).

You should use iptables to measure the traffic (view data amount of your ALLOW rules with -L -v). With vnstat you measure whatever the host receives over its LAN interface, including broadcasts and filtered port ranges.

Die Frage ist hierbei, wie vergleicht man die Hashrate von Bitcoin mit den FLOPS von folding@home? Das Bitcoin-Netz rechnet mit genau 0 FLOPS, weil Hashing auf Integer-Operationen basiert, nicht auf Floating-Point-Operationen.

Der Genesisblock ist nicht Nr. 1, sondern Nr. 0: http://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Fremde Transaktionen können nie gefälscht werden, da deren Sicherheit von ECDSA abhängt und nicht vom Proof-of-Work.
Ein Cheater mit Mehrheit kann Double-Spending seiner eigenen Transaktionen durchführen und fremde Transaktionen blockieren (nicht verändern), wobei ein Erfolg nicht garantiert ist, insbesondere nicht bei dünnen Mehrheiten wie 51%.

Je nach Ausführung können Angriffsversuche im Netz nachvollzogen werden, sofern die Community auf die richtigen Muster achtet. Ein Pool müsste schon einen sehr großen Coup landen, damit sich die Gefahr der Demontage durch die Community lohnt.

1. It must be allowed for random clients because there is no server that could arbitrate who is allowed and who not. If there was an arbitrator, you would have PayPal.
2. Bitcoin ensures that private keys cannot be cracked offline by using a computationally intensive algorithm and long keys. If the TANs have the same size as the private keys, there is no point in using an extra TAN because they do not provide any benefit over the private keys.

It's not a TAN because it isn't unique for one transaction. It's a way of keeping the private key private by not storing it on your computer. It's a good idea if you manage to keep the printed keys in a secure place.

There are two problems associated with this approach:
1. Storage space is limited in the block chain as it is mirrored on all clients. If you're allowing random clients save their TAN in the network, it could be easily spammed. So you would have to introduce a fee for saving TAN hashes in the network, similar to the transaction fee.
2. Online banking TANs with their 6 numbers have a very small search space which is only secure because your bank locks your account after 3 or so wrong entries. This is not possible in Bitcoin because you can brute force the public TAN hashes offline. Thus, the TANs must be impractically long like 30 characters or so.

Thanks, I'll take a look at it.

Yeah, the word "wasted" is too judging, I will change that to something neutral.


Ok right.


Interesting, I assumed orphan forks are removed when main chain matures.


You really mean derive the public key solely from the signature? Do you have additional information on that?

Thanks for your feedback!

Regarding scalability I say basically the same as the Wiki page does: scalability is limited and there are ideas to improve it in future.

Hi,

I'm holding a talk about Bitcoin in a couple of days. Target audience are computer scientists and it's focused on technology.

http://dl.dropbox.com/u/212148/bitcoin-talk.pdf

Any corrections appreciated.
I'm also preparing some backup slides about recent hacks, Namecoin and why non-scalability isn't the end of the world.

Regards,
Theo

This works if it isn't too annoying for experienced users to find the correct keys on the reshuffled board. The annoyance factor however limit the number of ambiguities. If you watch the user entering the password 2 or 3 times you can probably nail it down.
Graphical passwords are immune against keyloggers, but then mouse/screen loggers would probably come up.

If you're interested, there are some other ideas for graphical passwords, e.g. http://www.acsac.org/2005/papers/89.pdf.

Namecoins have only a value if people are using namecoin resolvers. If not, they're worthless. Similar applies to Bitcoin: if nobody accepts or buys Bitcoin, they're worthless too.

The solution to the multi-mega-dollar ASIC industry is to change the hashing algorithm and let their multi-mega-dollar project become worthless. If they didn't burn enough money, do it again. The solution to the ASIC lockdown is to change the hashing algorithm anyway and let the miners either use GPUs again or buy new ASICs.

We did a test with 40 random NAT users in Germany, out of which 10% had UPnP enabled.

Yes, lower the number of GPU threads (worksize). The number depends on your graphics card.

What's the point in this? CPU-mining is not worth it because the hashes/power consumption ratio is bad compared to GPU. If you don't mind wasting electricity, run a CPU miner at 100% with lowest priority. It will only utilize idle CPU time and won't interfere with other programs running.

I think it went like this: we need some BTC amount to be generated with one block. Let's take 50. Some built-in deflation would be good, so let's half the amount in some intervals. We need to define a minimum and 10^-8 seems reasonable. Put everything in a jar, stir well and you got 21 million max.