Actually, that's not quite true. If an attacker manages to achieve over 50% of the hash power of the network indefinitely, they will eventually manage to get the longest blockchain and rewrite the transactions they want to with probability one. Anything less and they're very unlikely to succeed. Rewriting transactions within a finite timespan is harder and requires a larger proportion of hashing power, of course.

(Also, double spending isn't the only issue. If you control a large enough proportion >50% of hashing power you can stop anyone else from mining blocks and control which transactions actually get through.)

If you earn money from manual labour, you're getting money from providing your skills and labour in order to do work; what you have to offer comes from you. If you instead earn money from pre-existing wealth, you're using your control of assets external to yourself that are required to do productive work in order to skim some money off the top. What makes you a better person to decide how those assets should be used than anyone else, such that you should be able to profit from controlling that decision?

Glad to hear a success story!

Unfortunately, some manual merging of changes is probably going to be required because both this and serial support modify fpgaminer_top.v. Shouldn't be too difficult to do in theory though, especially now that teknohog's merged his serial code with an older version of my modificatiosn.

I wasn't even aware there was such a device...

It gets even better if you noticed:
So Bitcoins are illegal there and that's why they don't want to run the miners themselves, but you need to pay them Bitcoins in order to reserve one. Right.

Out of interest, is 6mil trace + 6mil space good enough? That's what Laen's PCB group order for hobbyists provides, and supposedly someone's done a PCB with this pitch of BGA on that service. Of course, the turnaround times on that are probably less than ideal, especially if you're not in the US.

I'm pretty sure annular ring is generally defined as the width of the copper ring on each side, so D_via = D_hole + 2 * annular ring.

Curious. I'm all out of ideas, so it's good to see fpgaminer is here.

Bit-pay have to convert the bitcoins to USD somehow, and they apparently charge an unspecified fee for doing so (plus apparently the vendor doesn't get the payment from them instantly if they want it in USD).

If I'm reading the Cyclone III and IV handbooks correctly, the EP3C80 and EP4CE75 have exactly the same JTAG ID, so that's not surprising.

This seems odd. Are you sure you're measuring the right pins? It's getting late, but I can't see how TDO could be toggling if TCK is stuck...

Edit: Also, I assume you've pulled nCE to GND like the diagram instructs.
Edit 2: Oh, and pulled nCONFIG high, either through whatever non-JTAG method of loading bitstreams you've got or directly if you don't have one.

I think Xilinx's tools default to creating bitstreams that pull down unconnected pins to ground. Not sure what happens if you try and connect them to a different voltage externally, but finding out probably wouldn't be the best idea.

I don't think that's a terribly useful measure of the size of the economy. In any case, the problem isn't just that most of the Bitcoin "economy" involves buying bits of paper with presidents on, it's that people are getting Bitcoins by selling bits of paper with presidents on in the hope of buying more bits of paper with presidents on with them shortly after, and that's just not sustainable.

I think you might be suffering from a misconception. The amount miners are risking by holding onto their bitcoins isn't their electricity costs, it's how much they could make if they sold immediately because that's the amount they potentially lose out on. (This is a fairly common fallacy; from an economic perspective it's irrational and no-one should act this way, but people don't act the way economists think they should.)

Exactly. This argument doesn't work for inflation because you can invest the money now in something that will hopefully give you good returns, so it doesn't matter that it would eventually be worth nothing if you just sat on it. The problem with deflation is that just sitting on your money is actually a realistic scenario.

Except that the problem is that if we had price deflation, no one will be able to charge $120 to buy the product in a year's time, because the money would be worth more by then and that'll force prices down, not up.

Ironically, the thing you're not quite grasping here is the time value of money. Receiving 995 BTC now is worth more than receiving 995 BTC in two months time, because having it now encompasses both the possibility of having it in two months' time and the possibility of spending it in the meantime. This is still true if deflation means that 995 BTC is worth more in two months' time, because you can take advantage of this even if you're paid it now. So if you're willing to sell delivery of some good now in return for 995 BTC later, you should be even more happy to do it for 995 BTC right now.

No. My point is that predictable deflation cannot be built into the price, because the only rational price would be infinite (at least in this oversimplified scenario). More interestingly, look at what happens when everyone's only mostly certain about future deflation: the effects of predictable deflation on the price cancel out and price deflation occurs at exactly the same rate as it would have anyway. (This is again slightly oversimplified: in practice future expectations should help smooth out the rate of price deflation, but over the long term it has no effect.)

There might be slight practical issues with logging on to Tor from a prison cell.

Have you calculated the fees required to convert Bitcoins to some currency that can pay the bills? I suggest you try it sometime...

By the way, anyone running with LOOP_LOG2=1, 2 or 3 might find the experimental partial-unroll-opt branch useful - it reduces the resource usage somewhat. Unfortunately it also breaks LOOP_LOG2=4 and greater and hasn't been tested on actual FPGAs.

Except that because Apple make a profit without paying a dividend, their total assets increase and your shares represent the same proportion of a bigger pie, so they're worth more. In practice shares are generally valued at a premium to assets, representing the expectation that the company is expected to make future profits. You could slice up the company and divide up the value of the assets between the shareholders, and this does sometimes happen when one isn't using its assets efficiently, but generally it's worth more as a going concern.

For example, there was an interesting period where Acorn Group plc, who created the ubiquitous ARM processors that are now used pretty much everywhere and spun this off as a joint subsidary with Apple, had shares in ARM worth more than their entire market capitalization. Acorn Group was bought and split up as a direct result of this.

Bitcoins are different in that they're just numbers in a database; there's no underlying assets and certainly no-one doing useful business using said assets. Or to quote another /.er:


Also, an important distinction between the two is that Apple's value is not simply "what it does", it's that they can take their assets and use them in a way that makes money. Bitcoin's value, on the other hand, lies solely in the fact that you can find someone else willing to pay you for the bitcoins either in fiat money or in goods. The two are not quite the same.

"HDL Options" section of the XST configuration, options "Shift register extraction" and "Shift register minimum size". The default is to create shift registers as short as 2 stages, which is a bit daft. (I assume you've already figured out this quirk of ISE, but for some reason you have to select fpgaminer_top in the hierarchy before it'll show you the list of process steps and let you configure them.)

This probably matters most for Spartan-6; other Xilinx FPGAs don't seem to have such annoying limitations on adders.

My personal suspicion is that support for this particular Spartan-6 misfeature in ISE is buggy and badly tested; I'm fairly sure that at one point I was trying to cram on more adders than there were even SLICEM/Ls it could fit them in and it tried to map them anyway without realising this was impossible. It also doesn't seem to report usage of this particular resource in any useful way. It's possible that their routing design is also bad too, of course. I recently upgraded to ISE 13.2 and its behaviour in this department seems to have changed quite a bit from ISE 13.1, though I'm not sure if this is entirely for the better...

Edit: Think I may have been wrong about this; it's a bit under the maximum number of SLICEM/Ls available in theory.

Also, have you tried disabling shift register inferrence or turning up the threshold for it? Those compete for the same resources as adders.

Heheheheheheh. They certainly seem impressive, though I'll wait until someone's actually submitting shares with one, or at least until they're actually available for sale, before I actually believe it ;-).

Edit 2: 200 MHash/sec, though that increased total build time to over an hour. I have a feeling this isn't even pushing the tools slightly yet...

By the way - and this is probably what I get for not reading data sheets - I only just realized that the Virtex-5 and Virtex-6 series don't suffer from the annoying "only half the CLBs have fast carry logic" restriction of Spartan-6 FPGAs. Guess that could partly explain why Spartan-6 FPGAs have so much trouble with this design...

It appears ISE has no trouble at all fitting a 150 MHash/sec design on the Kintex-7 XC7K70T either (as in, it reaches that clock without even trying hard) - though note that this is an untested tweaked design and obviously I don't have the FPGA to run it on anyway. Kintex-7 is supposed to basically be a much cheaper 28nm equivalent of the Virtex-6 series.

AVRs are definitely the strong version though; they have hardware write-protect for the bootloader that as I understand it can't be overridden without connecting up a programming cable, and neither can anything else that would prevent you from booting from said bootloader. At least that's the theory...

Ah, sorry. Well, Cyclone IV and earlier can, as can Spartan-6 obviously. Kintex-7 and Cyclone V will apparently also support 3.3V IO on at least some pins, though I'm not sure if they do for the configuration pins...