You seem pretty certain about it, creighto.
I'm not trying to change your mind, and if I and a merchant can find a system that works for "handing over" physical Bitcoins, I suppose it doesn't have to involve anyone else.

As a thought experiment, imagine the "scratch off" lottery tickets.  You can't see the receiving key until you scratch it, which makes it visibly void.  A drawer full of these ought to alert the shift manager than an employee isn't following SOP. 

I don't really get the difference betwen "checks" and printed coins, except that a check sounds like it involves an intermediate processor -- a cashing authority or bank.  No can do.  The whole point is anonymous payer, anonymous receiver.  I don't want to know who cashed the check, and I don't want them knowing who wrote it.

If I'm willing to divulge everything, might as well have a Bank Of Bitcoin MasterCard and leave it at that.

Maybe I'm dense, but I still don't get it.  The whole point in handling paper bitcoins is to do so without a central "issuing authority".  I want to print my own, and accept them from anyone's home printer.

I totally understand that "showing your bills" to someone gives them a chance to photograph, and "receive them" (steal them, intercept, cash in, whatever).

That's just part of the deal.  You're carrying machine-readable (2d barcode) bearer-coins.  Show them only to the party you are paying, who is expected to transfer them on-the-spot to another account.

The receiver needs a network connection, the payer does not.  Perfect for customer/merchant scenarios.

I'd love to see printed bitcoins.

Basically, a bearer-bond note in a 2D barcode.

The receiver would have no protection against double-spend, so it would behoove them to scan it on-the-spot and get it into the Bitcoin network.  They could wait for a confirmation, or not.

It seems like this would be pretty simple -- get the client to generate a one-time receiving address, pay to it, and then print out the address public/private key pair onto the note.  Any scanner would then have the required keys to receive the transaction and re-spend the coin.

Assuming the receiver has a method to scan & post the note, it's no less secure than any other means of bitcoin payment, right?

Intel Atom 230 @ 1.60GHz.  Linux 32-bit.
(Acer Aspire Revo)

Stock: 438 khash/sec (1 proc gives 354)
4way:  254 khash/sec

So you can take this one off the powerhouse list.
 

It seems like this could be accomplished via UI change..

Instead of presenting 50.00 on generated block, compute how long it took and "trickle" the coins into the wallet to feel better about them for longer.

So once you generate a block, you would see pennies start appearing.  Hopefully they would trickle in for as long as it takes to generate your next block, more or less.



(I kid, I kid..)

Yow -- anyone look at the 24hr chart today?  Someone brought some serious hash power on-line.

It's now almost double yesterday.

You're on the right track.

The I/O requirements are almost zero.  You just need the 80 initial bytes, target hash, and a starting nonce.  You really don't need to talk to the FPGA again until you receive more transactions you want to include, or another block.  For speed, you would test against the target hash in-circuit, and the only output is on 'success'.

No need to randomize either -- any kind of value walk (increment, grey code, whatever) should suffice.

So yes --- the BTC 64,000 question is how many unrolled hash rounds you can fit into your part(s).

Any non-Mac i5 love?
Windows i5 64-bit got slower here.
[correction -- not true.  Windows doesn't have -4way, and the Linux machines are Xeons.]

Best thread evar.
What would you even do with VHDL code, anyway?  With your Ubuntu Pentium-III?  Yeah.

My point was that if you are willing to spend a summer learning new tools & technologies and decomposing SHA256 to map around your hardware of choice, with a master/controller to mate with it, you're probably best off buying a moderate GPU (GeForce GT240 at $90, or GTX460 $200) and diving into CUDA.  At least two people here have already done it.

An Intel i7 870 (3GHz, 4core*HT) is $265, so I'm not talking about exotic gear here.

My whole point is that 5 million hash tries a second is nothing to shake a stick at.

So is it accurate to say that, so far, only Intel Core i7 processors and certain (Phenom?) AMD processors enjoy a speed bump from -4way?

Ah, I see!  Simpler than I thought.
(difficulty * 2^32) is the odds of a hit on EACH try.
That's the 2.20e12 value again.

So total network power, in hash/sec, is then
(difficulty * 2^32) / 600

Where 600 is a smoothed approximation of last-block-interval-in-seconds.

I'm puzzled.  Why would anyone do this?

Effectively, we're already pooled today.  Over the long haul, every 10 minutes, someone gets 50 bones, and it's apportioned based on CPU speed.

If a slow machine isn't worth running hot for months on end to search, then why would it be welcomed (at greater value) to a pool including faster machines?  Seems to me that if you found a group of like-minded honest individuals, you'd end up with a cluster of really slow machines, rarely finding a treat, and doling out pennies to each.  Further, anyone inclined to join the pool is already running their machine anyway.

I guess I'm missing the point.

Statistically, you're not very lucky.  In fact, out of a hundred people, you would be one of the two least lucky ones.

I suspect something is Not Right with your setup.  Either you're running an old version, firewalled, or somehow not keeping up with the block chain.  Are you at block 75040 or greater?

I'm especially concerned that your 'span' of attempts has also covered lower difficulty eras.  That makes you even less lucky.

The last time I was that unlucky, I was running a broken 64-bit Linux build.
 

How does the Difficulty number (511) relate to the hash target?

511.77353426 * 2^32 = 2.2e12 hash/day, or 25 Mhash/sec.  I'm not sure how to interpret that, but it doesn't seem to reflect the 3.7 Ghash/sec total.

Also, the difficulty web page here:
http://www.alloscomp.com/bitcoin/calculator.php

seems to think that 3,600,000 khash/sec is a 10minute average rate.

The simplest way is to derive it from the hash target (difficulty).

If you take the present target value
0000000000800e00000000000000000000000000000000000000000000000000
and divide it by the total search space (all 0xF), you get the odds.

In decimal: 5.26786429665E+64 divided by the total search size (2^256) shows you have a one in 2.19e12 chance of finding a new block with every hash try.

We know that the network, as a whole is guided toward 6/hr, and the difficulty reflects that.  If the average generation rate is one every 10 minutes (600 seconds) then we know that the network as a whole is trying
3,663,473,554
hash attempts per second.

So the aggregate network power is around 3,663,473 khash/second.  Call it 3.7 gigahash/sec.   Further, if my machine is plugging along at 4,000 khash/sec, then I know I represent about 0.1% of the active network, and have a 1/1000 chance of finding "the next block".

If you use the *actual* recent block find rates (instead of the 10 minute average), which you currently track and graph, then you can see the interesting graph over time of how many total attempts likely produced that result.

I believe the 1/x characteristic would be more interesting to watch for trends than the seconds/block you currently graph, since the number of seconds is forced into a normalized 600 over time.  Total network strength should show an always-upward trend, with some notable spikes, dips, and steps.

I'll offer a BTC 100.00 bounty for an addition to
http://nullvoid.org/bitcoin/statistix.php
that shows the inverse (1/x) data: Computing power.

Specifically, total khash/sec for the entire network, based on either current difficulty or (preferably) observed block intervals / moving-average.

How "strong" is the bitcoin community now, and how is it trending?  That's what I'm looking for.  I'm not picky.

I'm not an FPGA expert, but I dabble.

I asked some folks (much smarter than I) to run some back-of-envelope calculations for my preferred Xilinx Spartan-3E.
It has 1200k gates, runs at 50 Mhz, and so on.  You can get into it for $150 or so.  (Digilent Nexys2 is hard to beat)

The upshot was that a modern desktop machine has such a huge clockspeed advantage (8 cores at 3 GHz?), so only a massively parallel implementation would have a chance of competing.  There really isn't much of an I/O constraint, so it's just grinding on the nonce and testing for success.  Most of the commercial SHA256 cores focus on I/O bandwidth, for the typical application of passing a lot of data into the hash.  This is something much different, with self-generated inputs and a test on the output of each cycle.

So.. How many rounds can you fit in a million gates?

A modern GPU and some crafty OpenCL/CUDA code seems like a better avenue for research, rapid turnaround, and scalable speeds.  You'd have both high clock speeds and parallelism at work.

How much confirmation does it wait for?  The first 1.00 hit right away.. the second one seems to be taking longer? Nothing showing up yet.  0 confirmations.

Whooo!  I'm in early on this one.   

http://fxnet.co.cc/?ref=18

Folks, get in at the TOP!  Reap the REWARDS!  These berries will lubricate your insides, whiten your teeth, and stop acne.

You get a whole bucket of detergent for the same price you're paying for one department-store bottle!

You'll go from being in BTC debt, to running a balance.  Maserati?  Lambo?  These are the tough decisions you will have to make over a fruity adult beverage.

You can be your own boss, and your own best customer!

Act now.
http://fxnet.co.cc/?ref=18

More than just Accounts, I'd really like total visibility into what bills are in my wallet, the specific transactions in/out, some total register view that has all the details available.  I feel like the UI is a bit dumbed down, and most of the early adopters are curious about the machinery, not just their total balance.

Just my BTC 0.02.