Heh, "Intimated Passion Anus Expand Tool". Drop-shipping from www.intimategadgets.com by any chance?

Yeah, I considered that after noticing the handy removable jumpers on the inputs to the regulators (intended for current measurement, I believe) - ended up just disabling the 1.2V regulator totally and feeding it from an external buck converter board though.

Definitely. Also, the power regulation circuitry on it's horribly inefficient and I'm not sure it can cope with full-speed mining - I'm actually running a modified board with an external power supply. To be honest, it's probably not worth the effort for mining on. The only reason I run one is for development purposes.

For the past few weeks I've been mining by hooking my DE0-Nano up to my PC directly via USB - no JTAG or microcontrollers or USB-to-serial, just full speed native USB. The code to do this has actually been publicly available in my git repository for about that long too, but I'm not entirely happy with it for various reasons. The licensing on the USB function core from OpenCores it uses is a bit odd, the code quality isn't that great, and I'm interfacing the FPGA pins directly to the USB port when I should really be using something like a TUSB1106 chip for better reliability and to protect the FPGA from being damaged by shorts to +5V.

Anyway, if anyone's got a use for this the Quartus project is in the projects/DE0_nano_USB directory of the de0-nano-usb branch, and the code to mine using this is in the usb-miner branch of afpgabm. You'll need to connect USB ground directly to pin 30 of JP1 on the DE0-nano, D+ to pin 25 and D- to pin 23 through say 10 to 47 ohm resistors (not sure what the exact resistor value should be), and connect a 1.5k pull-up resistor from D+ to a source of 3.3V that's only enabled when the 5V USB power is on. Better yet, rip out the fake USB transceiver logic from fpgaminer_top.v and use a TUSB1106 or similar. Users of expensive Spartan-6 boards should always use a real transceiver chip, partly to stop your hardware getting damaged and partly because some of them run on non-USB-compatible IO voltages that need to be converted.

Apparently SolidCoin 3.0 is going to introduce a daily fee for each address you own that has a non-zero balance in order to reduce the total number of addresses in use:


RealSolid is also planning to introduce exponentially increasing fees for accounts that haven't been touched in over 6 months in order to quickly redistribute the funds to active users:


So if you stick some SolidCoin savings on a USB stick in a bank vault for a few years, they'll be gone by the time you come to collect them. If my math's right, you could have nearly all the SolidCoins in existence in your account and it'd still only take 36 months of account inactivity for it to be totally emptied through fees.

110 MHz at 4 clock cycles per hash, actually. The design scales down reasonably well to smaller devices.

That's slightly older code. It's probably better than the newer versions with LOOP_LOG2=0 but it gives invalid results if you change it to anything else.

I suspect from looking at the code that you might be running into an alignment issue. The code in regeneratehash assumes that it can take a pointer to an array of type "unsigned char", cast it to a pointer to uint32_t, and access the contents of the array as though it contained 32-bit integers. This works fine on normal x86 machines which have very lax alignment requirements, but ARM requires memory that's accessed in this way to be aligned on 4-byte boundaries in RAM and it probably won't be because the compiler wasn't told that the data needed to be accessed in this way. So cgminer is going to crash.

I suspect - based mostly on the vagueness of the descriptions and the prices - that they're full of BS. Alibaba.com is basically a marketplace where a whole bunch of different companies can list their products and services, it doesn't do that much in the way of checking, and some of them have most likely just grabbed a big list of components and created entries for them all regardless of whether they can actually obtain them in the hope that they can source them if someone is willing to pay them money. Then of course there's fake components and outright scammers...

Ah, so it was that. A quick Google at the time turned up this mailing list message which has an interesting explanation of what apparently happens if you do that. Not sure if it's accurate though.

Just out of curiosity, are non-gitian Windows compiles of bitcoin-qt safe now?

I believe GPUs are designed to process batches of computations, so you pretty much have to do it that way. There's no reason why FPGAs can't be designed to return nonces as they're found and continue processing the work though, and unlike with GPUs there's not really an efficiency penalty for decreasing latency this way on the designs I've seen.

If you're clever you can make this latency more or less irrelevant to the total hashrate on FPGAs, though I don't think the BitForce boards do that either.

There's no reason why it couldn't in theory, but as far as I can tell it doesn't support one right now. Could presumably be added by a firmware upgrade in the future though.

Looks like cgminer will do actually. There are basically two choices. You can carry on working on every work unit to completion even though you get a longpoll, which is what cgminer does, or you can submit a new work unit to the single and it'll discard any results it found so far for the old work unit and start working on the new one. Either way you lose out, it's just a question of whether you lose by throwing away shares or lose by working on work units that are stale.

It may not be that simple. p2pool has its own, much faster parallel block chain which means that unless you want a whole bunch of stales you need to have a reasonably low latency miner. Last time I looked the BitForce singles had a latency of several seconds between finding a share and reporting it because they didn't return any shares until they'd completely processed every nonce in the work unit. That would absolutely wreck your p2pool profits. Because they also threw away any shares when they got a new work unit, this wouldn't necessarily show up as stales either - you just wouldn't find as many shares as you should.

I have a poclbm fork but it's a bit quirky, I've no idea if it works with the non-prototype hardware, and it probably doesn't work anyway right now due because there's a bug in the core poclbm code which that branch doesn't have the fix for. To be honest CGminer is better anyway.

Errrm, you might want to read my post in the Technical Discussion subforum. Turns out that once BIP16 is enabled, all other miners will be forced to upgrade pronto or risk losing money. (In fact, arguably it's even worse than that - apparently if BIP16 went live with only 55% of mining power supporting it it'd make 6 confirmation double-spend attacks against old nodes quite a bit easier than they ought to be.)

That's not entirely true. One interesting quirk of Bitcoin is that if you somehow managed to convince 51% of miners agree on a SolidCoin-style reduction in the block payouts then everyone else would be forced to go along with it, because according to the existing Bitcoin rules it's perfectly valid for miners to pay themselves less than the maximum allowed. Of course getting miners to agree to take less money would be a bit difficult.

Oh dear. If you use your MtGox Yubikey on there you're effectively giving them the ability to log in to your MtGox account and according to the MtGox TOS you'll be liable for any losses that result from this. (In fact, that's quite likely to be how they do it. The other possibility is that they only bother checking the static bits of the Yubikey authentication string, which they can do without knowing the secret embedded in it but which doesn't add any security.)

Not only that, but some code out there already takes advantage of this particular optimization. For example, I know that my variant of fpgaminer's code does so for fully-unrolled miners - in fact it totally omits the last three SHA-256 rounds - and it looks like ztex's code (which is what most people are using these days) does too in all its variants.

Edit:
Ooh, very impressive - will be interesting to see what you manage to get up to in the end.

As far as I know it's basically only luke-jr that doesn't check IsStandard, and even he's been known to forget to disable it on occasion.

BIP 17 might be even worse actually. Obviously, correct attempts to spend BIP 17 transactions won't be included in blocks by miners like this because the spends won't pass IsStandard, but I think it should be possible to create transactions spending them that are invalid according to BIP 17 but treated as both valid and standard by non-BIP 17 miners.

One of the claims about BIP 16 - the "pay to script hash" change supported by most of the Bitcoin developers - is that it should be a reasonably non-disruptive change. In particular, it wasn't expected to affect pools and miners running unmodified Bitcoin clients too much even if they didn't upgrade. There was a small risk that they'd try and build on blocks containing an invalid attempt to spend a BIP 16 transaction, but the IsStandard check would supposedly stop them from trying to include any BIP 16 transactions they couldn't properly verify in blocks they created themselves.

This isn't true. As gmaxwell pointed out when he discovered p2pool was allowing miners to put non-standard transactions in their coinbases, IsStandard doesn't actually check that the scriptPubKey of the transaction being spent was standard at all - it only checks the scriptSigs and scriptPubKeys of the transaction being spent. This means that attempts to spend BIP16 transactions pass IsStandard in older clients and they'll include them in blocks they mine even though they can't do the extra BIP 16 verification required to do this safely. I've even tested this works using a couple of test nodes running on mainnet rules; unfortunately this can't be tested on testnet.

What does this mean? It means that once BIP 16 is switched on, anyone can send out a couple of simple transactions, the first paying money to a BIP 16 address and the second trying to spend it to a normal pubkey address in a way that pre-BIP 16 clients will accept and BIP 16 ones won't. Once they do, all the nodes that don't support BIP 16 will mine blocks that the BIP 16 nodes will treat as invalid and rewrite out of existence using their majority of hash power. Worse still, everyone running or mining on a pool that supports BIP 16 has an incentive to do this because it'll eventually push difficulty down and make them more money.

In retrospect, someone should've probably started asking questions once Gavin Andresen listed the fact that transactions spending from BIP 16 addresses would pass IsStandard and be forwarded by older nodes as an advantage over BIP 17. The rules for forwarding transactions are almost identical to the rules for including them in blocks. (BIP 17 probably has the same issue though.)

That's... surprising. From what I recall, one of the things that was really slowing SolidCoin mining down on GPUs was writing to the scratch buffer. The SolidCoin algorithm writes to a small enough scratch buffer that it could be migrated to fast local GPU memory, though for some reason I'm not sure anyone's actually managed to do this yet. Scrypt writes its data to a buffer that's far too large to fit into GPU local storage.

The other curious thing is that the SolidCoin algorithm has some interesting time-space and logic-memory tradeoffs that Scrypt was specifically designed to block, and in theory they make FPGA mining of it a lot more feasible than it should be. I'm actually somewhat surprised ArtForz hasn't been FPGA mining it.