No, that's totally different because this "taint" is visually obvious and can't appear on a bill while it's sitting in your pocket. A better analogy would be if the FBI regularly published a list of serial numbers of currency that would no longer be honored. Banks would refuse to accept bills on the list, and soon so would grocery stores and so on. That hundred dollar bill you got from the bank, now sitting in your wallet, could appear on that list at any time because the person who deposited it at the bank right before you withdrew might have stolen it.

Think about what using currency would be like in such a world. Could you even have ATM machines? In fact, it would be the death of cash -- forcing people to use cash only for small amounts of money they could afford to lose. Such "tainting", if it hit the Bitcoin world, would similarly be the death of Bitcoin if it caught on in any significant way.

Not necessarily...  If someone gave you a pile of fiat that was splattered with some bright colored dye or paint, such as what happens when a bank robber flees the scene of the crime and opens their bag of ill-gotten bills only to find an exploding dye canister going off in their face and all over the bills, would you really expect a bank or merchant to accept those "tainted" bills?  This is the fiat equivalent to "tainted" Bitcoin.

I haven't personally decided if I support the idea of "tainting" bitcoin yet, but this would be an example of the real-world equivalent.

Would it be possible to shift the entire mining process to a system similar to p2pool that would include a signature based on it's own tree?  Then just accept blocks that are also signed by THE decentralized mining pool so everyone has to use it.  I guess it's a "one true way" approach.

I'm loosely thinking about something like what p2pmining.com is attempting to do.  Perhaps existing pools would submit blocks through the main p2p pool where they would be signed, maybe paying a small fee that is distributed to miners in the process.  Basically all miners/the masses would work together in a single p2p mining pool as gatekeepers to the actual blockchain.  External pools could still exist but would need to still submit blocks through the main p2p mining pool and pay a small fee of each blockreward to be signed and accepted.  I know there would be a lot of complexities to work out, I'm just thinking out loud and wondering if it would even be possible and what the potential problems would be.

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

I suspect that at least some of this drop was caused by Mt Gox having bank issues in Hong Kong.

Was thinking a bit... about what would happen in the event of a 51% attack.

Imagine a 51% attack against Bitcoin that was begun in secret, to create a large alternate chain that simply reversed a very large number of blocks, and persistently prevented any transactions from confirming.  The chain would be published all at once as a surprise and would propagate across the network faster than any worm.

Even if many of us could deal with that, the news would say "BITCOIN HACKED", that would be the end of Bitcoin as we know it, at least for a short while, until we all scattered around and figured out what to do about it.  

The problem with a 51% attack done this way is its effects would be sudden and instant.  The repair would be several days while the developers figure out what to do, and several more while the bugs get fixed, and plenty more time while people download it, repair their block chains, backport the patch to their customized clients, get back in business... meanwhile, we'd have lots of angry miners whose mining work on the fake chain got reversed, etc...

I would like to propose a couple simple things now relating to checkpointing so that the solution is known and the disaster preventable all the way in advance.

Basically, what I am proposing is that a) trusted entities put signed checkpoints in the block chain - which are nothing more than assertions that "I have seen the block with hash x", and b) that the client have some sort of list of trusted public keys (modifiable by power users, but otherwise pre-seeded by client authors) so that trusted parties can be recognized but also removed if needed.

Signatures would appear periodically in blocks, which would be part of real or dummy transactions.  MtGox, for example, may occasionally initiate a transaction to itself (or embed in one of its payout transactions) a signature referencing the hash of a prior block, simply to say "I saw this".  MtGox need not sign every single block - since each signature acknowledges all blocks before it, there will be other signers participating, and the scheme is mainly targeted at attacks on 6+ blocks, the signatures could be done three or ten or any other reasonable number of blocks apart.

Mining pools would do the same except would likely use the coinbase transaction as the location for their signature.

Very simply - if I as a client have block X, which I know has been seen by MtGox, TradeHill, and a dozen mining pools and trusted parties... I can quickly and confidently reject block Y which purports to replace block X with a higher proof of work.

To implement this proposal, all that would need to happen is:

• client gets a mini database to track trusted public keys, possibly kept in wallet.dat, but pre-seeded from hardcoded values in the client
• client gets an RPC call to modify this database for power users
• definition of "standard transaction" amended to include one that packs an OP_DROPped signature so that trusted parties can count on their stamps of approval being relayed
• the logic for handling chain reorgs more than 3 blocks deep is revised such that blocks known to have been seen by a majority of the trusted crowd are impervious to being preempted by blocks that have not.

The vast majority of client users would be using the default list of trusted public keys and would be unlikely to modify it, so the onus would be on the authors of clients to appropriately judge who belongs to be on the list.  The idea of allowing the client author to update the list remotely isn't out of the question - a suggestion probably not appropriate for the reference client - but entirely plausible for smaller-time clients whose users could just quit using if the authors were up to shenanigans.

Cool. So how much are you shorting right now?

Cool. How much are you shorting right now?

+1... goddamn scammers

Sorry, I just get tired of hearing the same shit over and over.  Despite this account only being active since July, I've actually been around since February.  Yes mistakes were made, a bubble formed, and value was transferred from losers to winners.  However, I disagree that we will see a repeat of the summer bubble.  Just look at it on a weekly time scale and you'll see what a joke it was.  There's too much money to be made preventing it from bubbling, and much more legitimate volume this time around.  This time the greedy will learn patience and the fearful will learn resilience.