While this is definitely really cool, it won't benefit anyone if you release it. After two weeks, the difficulty system will adjust and we'll be back to generating bitcoins at the same rate but using much more computer power. Although I suppose this will benefit those with fast video cards instead of just fast CPUs.

I'm one of those people, so full steam ahead!

That's my process as well, although I apply a variety of patches to things before hand. And I have boost and I think libdb from Ubuntu's repos.

I know that where I live there wouldn't be enough people who have Bitcoins for me to sell anything that way.

I'm not in the room 24/7 either. I decided to go off IRC and to the forums so I wouldn't need to wait around all day.

I need to learn some more C++. There are a lot of things that would improve bitcoin like encrypted wallet files, built-in performance monitoring, RPC extension, etc. Is there any system for submitting patches for inclusion in the SVN and/or default builds?

I don't mean to come accross as confrontational. I love Bitcoin and just want to help improve it.

I don't know if there are any technological safeguards to prevent this, but there is a social one: if you drop transactions, others might drop yours.

I thought about that. I don't know if 0.5 is valid or not. I'll continue to take observations. I wonder if it writes to the debug log when it has success.

Actually, that formula assumes that you're working on one block until you figure it out. In Bitcoin, aren't multiple nodes working on the same block? When one finishes, the others abandon work on it and choose another block? That was the impression that I had, but it might be wrong.

Hello, and welcome!

Yes, it would be very exciting if you created such a site. Bitcoin needs merchants and consumers (who are often the same people), and one of the best ways to inject value into the Bitcoin economy is exactly what classified sites often do: sell what you already have.

You would probably be able to convince the devs to include you in the Bitcoin-accepting site list on the main page, also.

Anyways, welcome to Bitcoin and good luck generating and trading!

My system has jumped up to about 1200 khps. Also, I got Bitcoin running on a VPS which is giving about 2350 khps. The formula which you posted (and I arrived at myself later) predicts a block every 8.2 hours for my laptop and one every 4.2 hours for the VPS. Since I started yesterday afternoon, I've only generated the one block.

Sound strange? Or am I just having bad luck?

Laszio, I've remade your patch to spam the debug log less (1/10th as often). I also the extended JSON-RPC library to add "gethps" (which returns the same string displayed in the UI). It also adds listgenerated, which returns a list of the strings from the UI representing generated blocks. In the third and final patch, I modified net.h to compile with -O2 on my machine (which it wouldn't before).

Here are the patches:
http://www.alloscomp.com/bitcoin/bitcoin-svn-80-perfcounter-less-debug-spam-2010-06-05.patch <- Apply Laszio's patch first, then this one.
Sorry, that patch ^^ is completely broken. The changes are trivial (the same line in 3 places), but I failed at diffing. I'll upload a better patch when I have time.
http://www.alloscomp.com/bitcoin/bitcoin-svn-80-rpcextended-2010-06-05.patch
http://www.alloscomp.com/bitcoin/bitcoin-svn-80-netpatch-2010-06-05.patch

Thanks to Laszio for the original performance patch.

I can't build r80 from the SVN with -O2 in the makefile. I'm running Ubuntu 10.04 LTS 64-bit on an Intel Core 2. If I remove -O2 (switch back to -O0), it builds fine.

The problem seems to be line 15 of net.h. My googling suggests that statement-expressions, some non-standard, GCC-only extension to C++, are not allowed outside of functions at that level of optimization. htons is implemented as a statement-expression for linux. I managed to get it to build by replacing the htos(8333) with 0x8D20, which is 8333 in network byte order. This compiles and runs fine on my Intel processor, but probably wouldn't work on a big endian processor like a PowerPC.

Is anybody else experiencing this bug?

Also, I'm somewhat disappointed. -O2 didn't help me generate hashes any faster. Perhaps I'll try -O3.

Laszio, I tried that but it failed. I'll see if I can't address the specific error. Line 15 in net.h failed to compile.

I can try if nobody else replies and this doesn't get accepted into mainline. Not sure what the Windows dependencies are or if I can cross-compile. Win64 or 32?

Hello all! This thread is exactly what the title says: a place to post about the node(s) that you are running, including their performance and hardware.

To find out your performance, you'll need to build from source with laszlo's patch. The performance in hashes / second will be listed in the UI where it used to say "Generating..." and will spam your debug.log.

I'm currently running Bitcoin on three machines (and I tested it on a fourth, but that one is for a business, so I can't keep it running).

My Workstation
Specs:
HP HDX 16t - 16" laptop
Intel Core 2 Duo P8700 (x64) @ 2.53GHz w/ 3072KB cache
4GiB DDR2 RAM
nVidia GeForce GT 130M (OpenCL needs to get its act together!)
Ubuntu 10.04 LTS 64-bit (2.6.32-22)
Performance:
**Perf - thread 3 : 446k iter/sec
**Perf - thread 4 : 451k iter/sec
**Perf - total : 897k iter/sec (2 threads)

My Home Server
Specs:
1400MHz Intel Celeron w/ 512KB L2 Cache
512MiB of (ancient) RAM
Debian testing 32-bit (not sure the kernel version)
Performance:
**Perf - total : 169k iter/sec (1 threads)
Puny!

My Xen VPS
Specs:
Not 100% sure about this, but it's using 4 cores.
256MiB of (fast) RAM
Ubuntu 10.04 LTS 64-bit (not sure the kernel version)
Performance:
**Perf - thread 1 : 436k iter/sec
**Perf - thread 2 : 410k iter/sec
**Perf - thread 3 : 419k iter/sec
**Perf - thread 4 : 429k iter/sec
**Perf - total : 1694k iter/sec (4 threads)

So, anybody else?

Sounds completely reasonable. I just started generating today, so I'll let you know once I get more blocks. Thanks!

+1
Is there any way to access this information?
EDIT (June 4th, 2010):
First of all, I am not a C programmer. That said, I wrote my own extremely janky, hackish JSON-RPC method "listgenerated". I basically took the code from ui.cpp that builds the transactions list and copied it to an RPC method. Then I removed parts until it would compile. I'm SURE it doesn't work right, but it shows me when I have generated a block, which is all I need. If anyone would like the patch, send me a PM. That said, you probably want to wait for a real implementation from the devs.

Can someone share the math required to compute the estimated amount of time to generate a pack of bitcoins?

Basically, a formula that integrates the difficulty (either as a hex number (currently 000000000f675c00000000000000000000000000000000000000000000000000) or as the difficulty factor (currently 16.62)) and number of hashes checked per second (currently like 1M for me) which would return the average time between blocks found?

I have access to a couple of VPS instances running on Xen that often have a LOT of spare cycles. Since the only thing I'm billed by usage on is bandwidth, I might as well get my money out of the things.

The cheapest one I have is $8 / month. They don't give any good info about CPU strength (and are generally unreliable), but at that price you only have to generate about 1.3 blocks a day, or one every 18.5 hours. That's still a bit high, but even if I only make $4 a month, that's a nice dividend since making BitCoins isn't what this box is primarily all about.

At the moment, that isn't true (at least in the CLI version). Bitcoin rounds to the nearest 0.01 BC. Of course, that's just an implementation detail, and there's no reason that couldn't be changed. Just throwing that out there. Also, even so, currencies that undergo an unstable rate of inflation or deflation (second derivative of their value) tend to be untrusted. If a dollar today might buy you $50 worth of goods tomorrow but also might only be worth $0.05, would you want to have a dollar?

I haven't tried that. Just got an AWS account, though. Their storage solution looks interesting ($0.10 / GB).

Have you read about Spot Instances? You can set a maximum hourly price that you're willing to pay in order to keep your server up. The "ask" price from Amazon fluctuates with supply and demand. If the BitCoin app could be made to save frequently and recover from downtime quickly, you could set your spot price to something that you know will make you profitable.

Just set your maximum bid price to:
(max bid price) = (blocks / hour) * (coins / block) * (USD / coin)
Where blocks per hour is how many blocks you expect / test to generate in an hour. That's the only tricky part of the equation.

Until recently, the "ask" price for a m1.small instance appears to have been hovering around 2.9 to 3.1 cents USD. There was a somewhat prolonged spike to 6 or 7 cents lately, but that might not continue. At an average spot price of $0.03 / hour and an exchange rate of $0.0041 / Bitcoin, you would need to generate one block every 6.8 hours, or 3.5 blocks per day. Is that unreasonable? Probably, but I'm not sure how fast a m1.small instance is. Also, that assumes that your instance is generating blocks for every moment it is up, which isn't true, since the instance has to reload and restart every time it goes down. On the flip side, Amazon doesn't charge you for partial time if you get shutdown (or perhaps they don't charge you for the ENTIRE hour -- it's a bit unclear).

It's an interesting idea, and might work well for you.

By the way, how did you get a metric on how many hashes your Mac checks per hour?

I throughly agree with this. In the long run, IRC should be completely phased out and replaced with something like Gnutella's host caches or Tor's dictionary servers (as others have suggested).

At the very least, Bitcoin should disconnected from IRC as soon as it has a list of peers to connect to. It should also cache that list so it wouldn't need to reconnect upon the next startup.

Just my 0.02฿.