First, that's antihyperlinked :<

Second, I'd rather see an ARM port, or possibly a SPARC port than a Cell port >.>

I get, on average, 100 a day with my P4@3200, I'd expect there to be only a small MIPS/MHz drop between P4 and celeron, so I'd guess vaugely at 50 somewhere between every day, and every day and a half. That's just a wild guess though, and difficulty only seems to be going up...

Heh, found this when i was cruising rpc.cpp when updating to r78... btw, it doesn't quite compile with GCC 4.3.4 from debian lenny backports, I had to change DEFAULT_PORT in net.h to a #define because the htons() wasn't allowed in the variable declaration for some reason... probably not the best solution, but it worked for the shirt term.

While a central database, or at least a partially-completed centralized copy of a certain number of blocks would speed things up, but then, so would mass-transfer between clients (requests for 500 blocks or so instead of one blocks at a time) and the latter would implement it within the confines of the network, without needing web hosting for a copy of the block database.

Currently, I believe one could grab a copy of someone else's blk*.dat files and speed the process up that way, but it really shouldn't be needed when the same thing can be done with a few snippets of code.

A draft standard for the bitcoin wire protocol would possibly be a help here, in that it would be possible for someone C++-illiterate to see what actually is possible in the current system ;-)

EDIT: if I understand correctly, a complete false start that wouldn't disappear as soon as a client connected to the network at large would require generating as many blocks as were currently in the network, so, one individual would have to generate 57525 blocks to do major harm to the network.

It could give someone a head start in forging a block, but not really. Having a rouge starter set of blocks would be just like having each new node started from that set of blocks be a rouge node, so it should be similarly impractical to forge anything.

So I'm poking around creating a simple web interface for simple bitcoin usage (something a little lighter and less stateful than a full-on wx/GTK GUI) and I haven't seen any way to see the status of generated blocks in progress of verification... I have seen my balance jump up by 50, but of course that doesn't show up in getallreceived.

For a headless coin generation box, being able to see my status right away would be nice, or at least, being able to know if I have 30 blocks awaiting confirmation, or am still trying to get the first... if it's purely automated and just checking-and-forwarding the balance, that's not a problem though.

Additionally, in the GUI client a transaction will appear as soon as it's seen, while getallreceived only shows a transaction after a block has gone by... yet the balance jumps up by the appropriate amount right away.

I can imagine some poor nervous customer pacing back and forth worrying about his payment going through, when that wouldn't really be needed. While this *could* be used to cheat the system if a malicious machine managed to generate the winning block and exclude its own payment, but some instant indication that something was happening would be nice none the less even if it needed a "don't accept transactions while the confirmations are still at 0" warning tag... perhaps a separate function that included 0-confirmation transactions? An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?

Well, to start with, integrating it would require there to either be a library, or a standard, and either way when the library or standard was updated it would need to be updated in every client using it.

Next, what if someone wants to stop running bittorrent (for example), but keep generating bitcoins? They can either close their merged client (and then open the standalone client), or they can just use separate clients to begin with... not to mention the same reason integrating an IRC client is pointless, people want to feel like they have a choice. If there is a merged IRC/bitcoin/bittorrent/gnutella/freenet/whatever client, it might be *convenient* for a number of users, but a good numbers of users would dislike certain features in the specific implementation of IRC, or bittorrent.

The same reason some people use irssi and some people use mIRC and some people use Xchat. No one client can please every person, and in some cases there is no "right" design choice. Even if the end result was a completely configurable client, it'd still wind up being bloated to please everyone.

If you want something, you're welcome to build it. An open specification for bitcoin is something I'd really like to see, just because it would allow someone with no C++ experience to do whatever they want with bitcoin without needing to know C++ to hack on stuff :-)

As to the idea of an "official" p2p currency, I could certainly see a micropayments-for-ratio system on a private torrent tracker or the like, and something like that could certainly popularize bitcoin a bit (though probably not in a good way, think "Evil hacker currency undermines US dollar, underground economy in stolen music, software", but no such thing as bad press, right? :p) but I don't really see integrating a bittorrent client and the bitcoin client as a helpful item in a system like this.

To conclude, I'm not opposed to the existence of an integration with other p2p apps, but just asking for it won't get anything done unless you find a motivated dev who *does* want to see the same thing.

Hrm, a third party account could hold money until the event finished, then pay the sum back to the winners... I'll have to implement something like this, at least as a proof of concept, once I manage to convince bitcoind to compile and run with 256 MB of RAM ;-)