Bitcoin isn't a fad, and never was. It is more. The initial excitement isn't over, it has actually yet to begin. Bitcoin is the light that shines upon us as the world economy enters its darkest hour. Just don't stare directly at it. It's very bright.

Or just look at the print preview and write it down the old fashioned way. Like I always say, you just can't trust printers these days. They keep a record of everything you print. And add invisible patterns to your pages to identify you. That's how The Man gets you. ¬.¬

Your subject line is interesting enough to get people to read it, yet your content-free post ensures nobody will actually respond to it. Well, nobody except me. Dammit, now look what you made me do.

Of course Bitcoin is a bigger joke than the US dollar. The real question is, who is the joke on, and do they know it yet? I would say it's safe to say that we Bitcoin users will be the ones laughing in the end.

Wallets -> Restore from Paper Backup

You can trade bitcoins for money in your PayPal account at Spend Bitcoins. You can probably trust them not to reverse the payment, but can you trust PayPal not to freeze your account if when they find out the money came from selling bitcoins (which is against their TOS)? If you want to buy something online from a vendor that doesn't accept bitcoins, Spend Bitcoins has other options which you might find suitable (and which are much safer than PayPal).

Or you could just ask the customer if he wears a seat belt, then refuse to pay out if he claims to always wear a seat belt but the accident investigation reveals that he wasn't wearing it at the time of the accident.

MMX, SSE, 3DNow!, etc are not instruction sets in their own right, but rather extensions of the standard IA-32 instruction set (this is the common instruction set for x86-32 CPUs). Any code which is compiled to use these extensions will not work on any CPU with an instruction set that doesn't include these extensions. As I understand, it is possible (in assembly) to write two versions of a function (one using the extended instructions and one using the just the standard instruction set) and have the program select which version to use by querying the CPU at runtime, but that's far beyond my level of expertise. Note that this is only possible because these extended instruction sets simply add new instructions without replacing or changing the standard instructions.

Are you sure it works, though? On all IA-32 systems? Unless you're absolutely positive the default is safe, -march=i386 is the only way to be sure. Compiling for any other architecture is very likely to result in a binary that is guaranteed to crash on certain systems.

If you think for a moment about what a CPU is and how it works, you'll realise what you're suggesting makes absolutely no sense. Every CPU has a single instruction set, and cannot use any other. IA-32 (i386) is a subset of all the various instruction sets used in x86-32 CPUs, and that's about a close as you're ever going to get to one instruction set being supported by a majority of CPUs. The instruction sets of other CPUs such as PowerPC, ARM, et al, are all totally incompatible with each other and with IA-32, so there's absolutely no way to compile code so that it works on all of them.

Actually, that may be what broke it in the first place. Specifying the target architecture is mandatory for the above reason. If you don't, the compiler will use the system default, which may not always be what you want. You must always specify what architecture you're compiling for if you want it to work on systems other than your own. I strongly recommend that you use -march=i386 -mtune=generic to avoid any future surprises.

-mtune doesn't actually have anything to do with what instruction set your target architecture uses - instead it just optimises your code for things like the cache size of a particular CPU and so on. Setting it to the wrong CPU (even a CPU that doesn't use the same instruction set as the one you're compiling for) won't ever break anything, but it can have a detrimental effect on your code's performance. Always set it to "generic" unless you have a specific CPU in mind.

I've never cross-compiled either, but yes, that should work. Let me know how it goes.

It's not my strong suit either, I just have enough experience with Linux programs whose installation instructions consist entirely of "Run make and fix compilation errors" to have some idea of what I'm doing in that area. First of all, don't use -march=native when compiling binaries for general distribution! I don't know about Ubuntu, but most "32-bit" distros these days actually use the P6 architecture instead of i386, which has the advantage of allowing you to use up to 64GB of RAM with a supposedly 32-bit CPU, but the disadvantage that code compiled for such a system will flat out not work on a true 32-bit system. You should be using -march=i386 for IA-32 and -march=k8 (er, I think...) for AMD64 (as well as -mtune=generic, though omitting it won't cause any errors, but may (or may not) have an effect on performance). That should at least fix the "Illegal instruction" issue, which is almost certainly caused by accidentally compiling for a CPU-specific architecture.

Um, you guys do realise that i686 is actually a 36-bit architecture and is guaranteed not to work on a 32-bit system (or a VM that emulates one), right? 32-bit binaries should be compiled for i386 only. That's the standard architecture for IA-32 systems; the i[456]86 architectures are CPU-specific and should generally not be used without a good reason.

Another typo: "make bank deposite"

I also notice you've copied everything on your site from Spend Bitcoins - right down to the example bitcoin address (which is actually a real address controlled by Spend Bitcoins).

I just noticed the site title says "Welcome to MR bitcoin Lunching page". So when is the lunch scheduled? And is it BYO?

No idea why you would be seeing that. It's got a perfectly good issuer chain: kronos.io -> PositiveSSL CA 2 (COMODO CA Limited) -> CA Root. Are we both looking at the same certificate (SHA1: 0aa96a3a3ab2accaceb3d77847174b1427de6a37; MD5: 22c32d8cbe8eb27cf8f9e65e457deb48)?

All of these are "problems" with the Satoshi client specifically, not Bitcoin itself, except for 1 and 2, which are a necessary evil of running a full node (which is not something that ordinary users are required (or even recommended) to do). The Satoshi client has these issues because it implements everything that is required for the Bitcoin network to operate (including things that ordinary users don't want or need) and does not implement certain things that many people want but are not strictly necessary for Bitcoin to function. All of these issues are or can be addressed by alternative clients.

There are no rules to the minimum fee structure - miners and nodes are free to enforce whatever fees they want. Ultimately the market will decide what fee structure is best for Bitcoin, which is the way it should be.

This isn't "my" trick, it's a pretty well-known method of abusing file format quirks. It works quite simply: Most file formats (MP4 included) start with a header which describes the data contained in the file, as well as (in most cases) providing byte offsets to the data chunk(s). Any data beyond these offsets is ignored, and you can append whatever you want to such a file without breaking anything.

But ZIP files are different. The header of a ZIP files is at the end of the file, not the start, and the offsets to the compressed file entries within the ZIP file are relative to the start of this header, not the start of the file. This is completely the opposite of most file types, and allows ZIP files to be prefixed with arbitrary data without breaking them.

These two facts allow you to stick a ZIP file onto the end of another file, and the resulting file will function normally as both the original file and the attached ZIP file without having to use special tools to separate the two.

But that's not all. File type signature tools typically work by reading a few bytes from the start of a file and comparing it against a database of known file headers. This works for most file types, including undoctored ZIP files, because ZIP files normally start with a compressed file entry, which is not the header, but is treated as such by signature tools because it is uniquely identifiable as being part of a ZIP file. But this assumption fails completely for ZIP files which do not start with ZIP compressed data, and the tool will instead identify the file as being whatever type of data the ZIP file was prefixed with.

This is, of course, trivial to detect if you know what you're looking for (namely, the file size being significantly larger than the apparent data contained in the file), but most other steganography techniques have the exact same problem.

Actually, it is.



This is really no better than cat SomeVideo.mp4 SecretData.tc.zip > InnocentLookingVideo.mp4 (Zipping the TC file allows it to be easily extracted by just opening the resulting MP4 file as a ZIP file). The resulting file requires no special tools either to create or open, and it's no more likely to be detected than more complicated methods (the MP4 file still works, and is still identified as an MP4 file by all standard file type signature tools, so nobody's going to check it too closely and if they do, they would have found the secret data anyway).

I'm not sure what you mean... If you installed from the Linux tarball, typing which bitcoin-qt at the command line will tell you where you installed it. As far as I know, all the other installers install to the standard location for whatever OS you're using, and if you need to know this location, you're doing something horribly wrong.

The same way you buy any other currency: you buy it from exchanges. You can also recieve (extremely small quantities of) bitcoins for free from various sites, which is a good way to test if your software is actually working before you put real money into it.

Link to list of vendors
For vendors that don't accept bitcoins directly, you may be able to find third parties selling gift cards for bitcoins.

The file wallet.dat (in %APPDATA%\Bitcoin) contains your bitcoins (technically, the cryptographic keys needed to spend them). Just transfer this file to the computer you want to spend your bitcoins from.

Again, the wallet.dat file is all you need to back up (and you should be backing up this file regularly whether you're planning on formatting your PC or not), however you might want to back up everything in the %APPDATA%\Bitcoin folder, since this will save you from having to download the blockchain all over again when you reinstall Bitcoin.