That'd leave some pretty obvious telltale signs...

It should have the second of those two optimisations (not calculating the last 3.5 rounds) but I don't think it has the first one, mostly because it's harder to do and requires changes to the supporting software.

That's surprising actually. PC motherboards and graphics cards have similar power supply requirements, and they're definitely available for below $200...

LUTs are sometimes involved in certain specialised kinds of routing, but most of the routing is done through a dedicated routing fabric in which the LUTs are embedded. As I understand it this is one of the things that distinguishes FPGAs from other forms of programmable logic like CPLDs.

Yeah, FPGAs very power-efficient but the upfront cost is nasty for every solution I've seen so far. On the plus side, as newMeat1 says you can keep going well after GPU miners have to give up...

Edit:
That reminds me, an interesting factoid: unless he's been deliberately misleading people, at the time he had the ASICs made he didn't actually know about the optimisation of computing H+K+W[0] in the previous round, which improves performance for free by reducing the critical path (at least on FPGAs).

The entire thread claiming Oldminer is Thomas Nasakioto was started based on someone's inability to read dates correctly, which is pretty damn stupid if you ask me. If you use the correct dates, in order for Thomas Nasakioto to be Oldminer he'd have to have started mining ixcoins a month before joining the Bitcoin forums and asking a bunch of tech support questions about mining (or fake the block timestamps, which is almost certainly beyond the capability of Thomas Nasakioto from what we've seen so far).

Welcome to the fun world of software releasing! It's why I don't release much software. This one would be even worse than average - in order to launch with a genesis block of verifiable timing they would have had to modify and compile the viewer immediately before launching, and the Bitcoin build process is really gnarly and non-automated.

Bitcoin has never run in server mode by default - I think the official client may even require -server if you run the GUIless bitcoind program. Anyone that didn't know this probably shouldn't have been mining solo anyway. At the block rates IXcoin and I0coin reached when they first launched, you apparently pretty much had to have long-polling support in order to get any non-stale blocks, which meant setting up pushpoold and blkmond. That's a lot harder than remembering to pass the -server flag and has lots of potential for breakage.

Errrm... none, because the rotations are just rearranging bits in a fixed way. They do use up routing resources though. (I'm not involved with the design and sale of this board but I did contribute a few performance-related improvements to the FPGA code.)

I'm reasonably sure Altera's compiler for Cyclone IV does because of the large decrease in resource usage. On Cyclone IV it uses less resources to store the partially pre-calculated T1 value than it does to store tx_state[`IDX(7)] because registering logic outputs is practically free but registering the output of another register ties up an entire LE per bit that can't be used for anything else. No idea if Xilinx's tools catch this though.


Oooh, cunning - nice one Anoynomous! Costs a register overall due to having to get rx_w[2] out of storage, but might be worthwhile. In theory could it be cheaper to do this with s1(rx_w[14]) + rx_w[9] instead?

I saw similar failures at one point. Try enabling register duplication for the Map stage and/or register rebalancing during synthesis. I think I can probably hit at least 140 MHz for 70 Mhash/s on SLX75 with two pipeline stages per round and both of those enabled, plus some other bits, but I need to fix some stuff and test the changes in simulation.

The transaction rate can't grow more than two orders of magnitude before we hit the artificial cap on the block size. In practice I'm not sure if the pools could even scale up that far; if I'm reading the code correctly the cost to pools of generating work scales linearly with both the number of miners and with the number of transactions per block, and they're struggling a bit as it is.

Here's something I literally just bodged together quickly using TomFastMath for a project I'll get around to any year now. Should hopefully be reasonably portable, if not the smallest or most efficient code in the world. Be sure to read the disclaimer!

What's the depth like, though - how fast would he have been able to sell that 25k bitcoins if he hadn't sold them in one go? Also, you've got to remember that a lot of the apparent depth on the trading chart is made of orders that will be pulled as soon as the price gets anywhere near them, so the only way to take advantage of it is one big sell-off that pushes the price right down.

It's pretty much definite that difficulty will going down if nothing changes, actually. Estimates over multiple non-overlapping periods of time have consistently indicated that the hash rate has dropped, and it looks like we should be in for at least a 3% drop in difficulty.

The only points I can see that seem to contradict each other are 1 (not anonymous) and 8 (thief's dream come true). Note that I say "seem" here: the reasons that they don't are that thieves are willing and able to put a lot more effort into obscuring their trail than honest folks are, and that getting away with theft only requires laundering the stolen money once whereas protecting your privacy is a much harder ongoing process that you have to think about every time you make a transaction.

From what I can see they're basically doing the bare minimum required to stop the community coming after them and nothing more. You're quite likely never to see any of your bitcoins again.

You just have to remember to never leave it inserted for too long (or it could get infected or hacked) and hope that no-one cares enough to write BIOS resident malware...

This is true, but with a major caveat: the only way to prove to someone else that the transaction data is safe to delete is to give them a copy of it, which means you need to have a copy of it. Without the ability to prove this, newcomers have to trust they aren't being lied to. I think this may open up a potential double-spending attack or possibly worse; while the nodes that had a copy of the expunged data at some point can safely mark the correct transaction outputs as spent no-one else can confirm what it spent.

(Also, if someone manages to get non-standard scripts into blocks, they can create transactions that are spendable but require you to keep a copy of arbitrary data in order to be able to validate future transactions that spend them.)

Of course, as I understand it the transaction ID is computed as the hash of the transaction, so you can no longer prove that the transaction in question has the ID you claim it has, that the block that contains it or any blocks building on that block are valid, or even that the block that contains it does actually contain it rather than some other transaction you want to maliciously replace.

Which again pretty much requires some kind of trusted central censorship body, with all the transparency problems that entails. At the very least they could maliciously render particular bitcoins unspendable, which means that someone could get a court injunction forcing them to do so.

Because it might be cheaper just to buy some bitcoins?

Not possible. He's using the block chain checkpointing feature to make his Ixcoin client reject any blockchain in which the first 6050 blocks aren't the ones he generated.

Finally got around to coding some maximum clock speed improvements for users of smaller Cyclone III and IV devices - now available from my new partial-unroll-speed branch. Expected minimum device size and speed is roughly as follows:

LOOP_LOG2=0: minimum device size ~75k LEs, maximum theoretical speed 110 MHash/s @ 110 MHz. Use the DE115_makomk_mod directory in fpgaminer's main git repository.
LOOP_LOG2=1: minimum device size ~50k LEs, max theoretical speed 50 MHash/s @ 100 MHz. Use DE2_115_Unoptimized_Pipelined directory in the partial-unroll-speed branch of my github repository.
LOOP_LOG2=2: minimum device size ~30k LEs, max theoretical speed 25 MHash/s @ 100 MHz. Use same partial-unroll-speed code, but edit the line after "`ifdef USE_EXPLICIT_ALTSHIFT_FOR_W" in sha256_transform.v to read "if(LENGTH >= 5) begin" rather than 4.
LOOP_LOG2=3: minimum device size ~20k LEs, max theoretical speed 13.75 MHash/s @ 110 MHz. Use partial-unroll-speed again, no modifications required.
LOOP_LOG2>3: not supported by either of these two code code versions, stick to the original partially-unrolled code in the DE2_115_Unoptimized_Pipelined directory of fpgaminer's git repository? (Bear in mind it may not be very area-efficient.)

It may be possible to get some of these up to 110 MHz or fit them onto slightly smaller devices (actual LE usage is currently about 74k, 46k, 26k?, and 16k respectively).

Also: remember that some or all of these may require extra cooling in order to operate safely.

If you accept Bitcoin in exchange for a product or service, the same argument applies - you have to offer actual goods and services, whereas the early adopters can obtain your goods and services without having to actually contribute anything productive to the economy themselves. (There's also the issue that if you sell for Bitcoins, you're the one that takes on the risk of the exchange rate collapsing due to early adopters selling their holdings and making it impossible for you to cover costs that are in USD or your local currency - and you will have costs that can only be paid in your local currency.)