I'd save that for the guy that set up a website handling millions of dollars' worth of other people's money without even basic security precautions. At least those e-mails are vaguely useful. He or she is even recommending a sensible replacement for Mt Gox; as far as I know Tradehill's the only bitcoin trading site that no-one's found CSRF vulnerabilities on yet, which hopefully means they're actually taking security seriously.

A few days before their entire user database was publicly published, someone was trying to flog it for sale. MagicalTux insisted that it was a lie, that there was no way it could've been leaked. We know how well they delivered on that promise.

Bear in mind that anything shorter than 8 characters isn't "complex enough" these days, and your password will probably already have been cracked if it is shorter than that. GPUs are very fast at cracking password hashes, even salted ones, and the Bitcoin mining community has a lot of compute power.

What Waltibaba said. If you're particularly desperate you can try searching your disk for the BerkleyDB magic bytes or paying someone else to... though I'm not sure how well that would work.

Not possible as far as I know. All the other clients are meant to check the transactions are valid and reject the entire block if even a single one isn't. The only thing miners could achieve by trying this is to hurt themselves.

Nope, you were vulnerable just by visiting a malicious site whilst logged into Mt Gox - or even just an otherwise-trustworthy site with a malicious ad on it, in theory. The problem was with Mt Gox. They failed to verify that form data sumitted from your browser telling the site to do stuff was actually submitted by you rather than from some random evil webpage you've visited. This is a well known type of security issue and the methods of preventing it are also well-known.


Javascript makes CSRF slightly easier to exploit but not much. If you had Javascript disabled the malicious website would have to trick you into clicking a button on the page in order to hack you, but the button could be named and styled and presented however they wanted. (Also, as joepie91 says, it doesn't matter whether Mt Gox itself used Javascript or not.)

And I think people would be quite sensible if they refused to use bitcoin as a result.

No, far too many groups consider any opinion contrary to their own to be a result of brainwashing. It's pretty much the only thing they all have in common, so they can't all be right...

How traceable and easy to fence are those items, and how many of them have been robbed so far?

In what way is coming to the conclusion that the effort required to securely use bitcoin plus the risk of losing your money despite your attempts at security isn't worth the benefits to be gained not exercising "personal responsibility" and thinking for yourself? It sounds very much like you're implying anyone who doesn't come to the same conclusion as you must be brainwashed, which is a very annoying and tiresome argument indeed. (Partly because I've heard it far too many times from far too many different groups.)

Edit:

Well, yes... which is why pretty much no-one keeps all their savings in cash, banks have various methods to prevent fraudulent credit card and bank transactions and contractual obligations to refund them, there's infrastructure in place to identify and track stolen vehicles, and only people who are both rich and naive buy houses via quitclaim deeds.

I'm pretty sure your argument is wrong, by the way. No matter how long it's been since the last block has been generated, the average time until the next block is always ten minutes (plus or minus any change in network hashing power since the difficulty adjustment). This is kinda counter-intuitive, but it has to be the case because the probability of a block being generated in any given second is not in any way affected by when the last one was generated.

The basic flaw here is that the probability of your craving for a sugary snack falling in any one interval of time between consecutive blocks depends on the length of that interval of time. Your purchase is less likely to fall within one of the shorter periods between two consecutive blocks and more likely to end up in one of the longer ones. This would be quite difficult to calculate, but fortunately we don't need to because we know the next block is always 10 minutes away on average.

Oh my god, you're right - if we're not careful, people might come to a rational decision that the risk of getting all their Bitcoins stolen is too high and not use them! We must stop all discussion of this at once!

Let's face it, anyone that can't understand the difference between an issue with bitcoin and an issue with users protecting their computer's security isn't going to be able to protect themselves any better than allinvain did, so it's entirely reasonable for them to conclude that Bitcoin is too risky for them. Why should someone store their money in a way that requires difficult-to-follow precautions lest it gets stolen from them through means that they don't understand which make it impossible to recover?

That's their marketing claim which you and a lot of other people evidently bought into, but key management is an important issue - and at Dropbox, their employees have access to the keys required to decrypt your data. In fact, for all we know the keys are stored in the same place as the data. (Dropbox also has a similar issue to Bitcoin itself - once someone manages to break into a device connected to your account and steal your Dropbox settings file, they have access to your files forevermore.)

Hmmmm, "un-a-lien-able" as in liens? That'd make you a member of the sovereign citizen movement, or something similar?

If they want Bitcoin to be widely used, they kinda do. There are existing methods of transferring and storing money that are easier to protect against this attack than Bitcoin is, and are accepted in more places to boot. What's more, if no-one uses Bitcoin, then the bitcoins themselves are fundamentally worthless.

Not using bitcoin seems like the most sensible way of protecting your wealth from attackers who're trying to steal your bitcoin wallet to me.

Ouch. The usual recommendation is to use light oil/sewing machine oil rather than WD40 for sticking fans, but yours really shouldn't have failed this early on. Besides, I've generally found that it only helps for a few months before you have to re-oil.

I've never oiled the fan bearings on anything as high end as a 5850, but you'll almost certainly have to remove the fan and heatsink from the card completely, because the hole for oiling is pretty much always hidden under a sticker on the underside of the fan.

Warranty replacement is probably your best option?

One obvious thing to bear in mind is that, at some point, the pools will inevitably all increase the difficulty of each share in order to reduce the work required to check all the submitted shares. So any ASIC-based mining system needs to be capable of checking hashes against difficulty levels above the minimum, either in the ASIC itself or in the processor controlling it. It looks like BTC Guild is actually making this change right now - there's a notice on their website saying they're doubling the difficulty per share. (This also requires changes to the software controlling FPGA miners.)

Edit: The other is that there's a good chance pools will eventually move to making miners compute midstates locally, again to reduce their resource usage. That's almost certainly best handled on a controller CPU rather than the main hash-computation hardware. What's more, since the rate of midstate computation is roughly proportional to the number of gigahashes/sec, mining ASICs would probably mean both of these happen sooner than they otherwise would.

Wow. Quartus II is claiming 108MHz and 78k LEs for my latest tweaks to the fully-unrolled DE2-115 code. I expect I could've hit at least 110MHz if the optimizer hadn't given up once it reached its 100MHz target. Surely this is too good to be true, especially since I haven't done anything fancy like precomputing W? Sadly I don't have a board to test this with but ModelSim seems to indicate it's not obviously broken. Anyway, it's up on github if you're feeling brave, and watch your cooling.

Edit:

The Cyclone II EP2C35 based one? Should be able to fit a partially-unrolled pipeline onto that in theory, though it probably wouldn't be massively fast. You'd have to port the HDL over to that board and compile a bitstream yourself, but that probably just means changing the device setting and pinout and turning down the level of loop unrolling.

(Edit 2: Apparently Fmax=110.34MHz for this design on the EP4CE115. Interesting. I think I should be able to improve on that a bit )

They're kinda neat, fairly powerful, and the chips aren't massively expensive either. I actually have an XMOS XK-1 boards here flashing an LED at me accusingly. The caveats are that USB is a bit tricky, requiring external components and using up nearly all available I/O ports on that core (so you really need a more expensive dual core chip for that), the chip has some slightly interesting power sequencing and reset requirements, it has no internal Flash so you need a seperate SPI Flash chip for firmware, and it has no internal driver for a crystal oscillator. (Edit: oh, and you're limited to 64 kilobytes of RAM per core and your code needs to fit into that too.) An ARM microcontroller with integrated Ethernet MAC and USB might work out better.

Of course, there'll be some tricky board design and manufacture anyway for the ASIC, so that may not necessarily be a huge obstacle.

Edit 2: Also, a totally untested 90MHz/90 MHash/sec bitstream for the DE2-115 is now in a branch on my git repo. PowerPlay estimates 4.4W of heat, I think? Anyway, don't blame me if you blow up your expensive board. There's a reason I'm not including instructions here.

(Edit: Altera Quartus II claims FMax = 90.16 MHz on EP4CE115 for the xilinx-shiftreg branch, with one or two tweaks to the build config that may not be necessary. Took over 3 hours to build and used pretty much all the FPGA though, so not terribly useful - you would be better off adding another mining core.)

Been messing around some more with fpgaminer's code. Users of largish Altera FPGAs might want to try this branch, which skips the last 3 rounds in the fully-unrolled version and allows optimisations based on the fact that part of data is constant. Xilinx users can additionally uncomment "`define USE_RAM_FOR_KS" and combine this with teknohog's serial miner, though this may not work too well. (There's also the xilinx-shiftreg branch which only works for fully-unrolled miners.)

Note that I don't have an actual FPGA to test any of this on, so be sure to double-check the thermal results to make sure you're not going to damage your expensive hardware, and make sure it's actually submitting blocks successfully. Also, these are more size improvements than speed improvements, and most people that could benefit have probably got their own better version already.

Brief explanation: with the original code, which is what you get with USE_RAM_FOR_KS disabled, Xilinx's xst was doing something daft involving shift registers for K[ s]. Without the xilinx-shiftreg changes, it also failed to use shift registers for W where it kinda made sense to do so; unfortunately with the changes Altera's Quartus tools no longer find the shift registers.


If you're doing HardCopy-style structured ASICs, in theory you could put a fastish 32-bit processor and Ethernet MAC on the ASIC itself. It'd probably only take up a smallish proportion of the chip and you'd just need  boot flash and Ethernet PHY chips externally. Not sure how much sense this would make though.


Unfortunately, OrphanedGland and a lot of the other posters in this thread can't reply to it anymore because they're too new. The forum admins have blocked users with a small number of previous posts from posting anywhere except the Newbie forum. Try this thread.

Wow - that's fairly impressive. I guess precalculating must pay off in a big way, though that's probably not really surprising if you think about it. Managed to get it submitting shares yet? (I'm also curious if you've found a clean way to handle the parts of W that can't be precomputed; it's obviously doable but the obvious ways are really messy.)

Also, you're right about the Cyclone FPGAs not being able to combine combinational functions with registers very effectively. All their registers are hard-wired to the output of the LUTs and other logic devices, which means that if you need to feed a register from somewhere else (like from the output of a register) you can't use the LUT attached to that register for anything else.

I wonder if this'd fit into the EP4CE75...

Hmmmm. It looks like Xilinx's synthesis tools aren't very good at inferring the right meaning from various constructs this uses. I'm now seeing if I can convince them to interpret it in more efficient ways, but to be honest it looks like they may just be slightly rubbish. It ought to be possible to cram a full hashing pipeline into a XC6SLX75 in theory, but the current code isn't even getting close.

Hi. Having looked at the code I've got a question about the configurable loop unrolling. It appears from looking at sha256_transform.v that feedback is feeding the saved W and state into every stage of the hashing pipeline, not just the first, and I can't seem to see why this is necessary. What's more, if I'm reading what Quartus II is telling me correctly, doing this is costing me several MHz of clock speed and more importantly appears to be using fairly large amounts of logic resources. Is there any way to avoid this?

Edit: Ah, having actually read the comments I now understand. You're doing feedback seperately at each stage of the pipeline, so each pipeline stage computes 2**DEPTH rounds and outputs at 1/(2**DEPTH) speed. Interesting. The trouble with this approach is that I don't think 512-bit wide muxes are exactly cheap.