After talking with a few groups of people, I decided a good use of Bitcoin Faucet funds would be compensating miners who had blocks that were orphaned in last week's Bit Chain Fork.

This is a one-time thing-- don't expect orphaned blocks in the future to be compensated! It is just a coincidence that I haven't had time to fix the Faucet, and have a bunch of coins waiting to be given away.

Transaction id paying the to the addresses in the coinbases of the orphaned blocks: c931f1aa9f0d211dca085342ec472e77b538b55980a2c7b0ff9fab9a20a9acd2

I think you're exactly right.

FinCEN cares mostly about big-time money laundering and terrorist financing. If I was running a cash-for-bitcoins service in the US and started moving more than a few hundred bitcoins a month through my bank account, then I'd talk to a lawyer. If I was running an exchange, I would have already talked to a lawyer. If I was a US-based miner exchanging more than a few hundred freshly-made bitcoins for cash every month, then I would talk with a lawyer. If you hold other people's bitcoins... then I'd talk with a lawyer (even if you're not a money transmitter, there might be consumer protection or banking laws that might apply).

Otherwise, I wouldn't worry. If I was a miner transferring my bitcoins to an exchange and selling them, then FinCEN won't come after me. FinCEN will get reports from the exchange, and that's what they really care about. The IRS might come after me if I don't report the income, but I think they'd charge me with tax evasion, not being an unlicensed money transmitter.

I just used some bitcoins from the Bitcoin Faucet fund to compensate the p2pool miners who's block was orphaned in the Big Chain Fork.

Transaction id 6521b0513f3077a983b82eb92cc95ecc24ad2a7ca3afdba082ef71ea8d25a868

PS: this was a one-time thing, don't expect orphan blockss in the future to get paid for!

Suggestion: instead of talking endlessly about possible attacks, try them out on the -testnet test network.

That is what it is for.

Oh:  except Sybil attacks, which just aren't very interesting on a network like testnet that has only a couple dozen peers on it.

There are three stages to the rollout:

1. Before 75% are producing block.version=2 blocks: no special checking
2. Between 75 and 95% : block.version=2 blocks MUST have height in coinbase.  We are here.
3. 95% or more:  all blocks MUST be block.version=2 and MUST have height in coinbase.  Should happen soon.

Shell script to count block versions:

The bottleneck for getting this pulled is testing.

It needs a thorough test plan that tries to test edge cases where things might break, and then it needs people to carry out that test plan to make sure it is solid. "It works for me" isn't good enough for wallet-touching code.

See https://github.com/bitcoin/QA  for a suggested process.

No; the only 0.8 users who should upgrade are miners who are creating blocks themselves (mining pool operators, solo miners, or people using p2pool).

Big merchants/services/exchanges who want to be as certain as possible they don't end up on the wrong side of a blockchain fork should also upgrade, although I think the risk of that happening if they keep running 0.8.0 is small.

Last July, BIP 34 was accepted. It specifies a "soft fork":


We are getting close to that threshold: 821 out of the latest 1000 blocks were version 2.

If you are mining in a pool: there is a list of pools and what versions they are producing here. If your pool is producting version=1 blocks, you should urge your pool operator to upgrade or patch.

If you are mining with p2pool or solo and using a very old version of bitcoind: you should upgrade, or you risk your blocks getting orphaned.

Bitcoin-Qt/bitcoind version 0.8.1 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/

This is a maintenance release that adds a new network rule to avoid
a chain-forking incompatibility with versions 0.7.2 and earlier.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues


How to Upgrade
--------------

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you
run 0.8.1 your blockchain files will be re-indexed, which will take
anywhere from 30 minutes to several hours, depending on the speed of
your machine.

More documentation is great, so yeah, if you want a formal spec, go for it.

Here's a tricky question you can start with:

Assume there is a fork consisting of max-block-size blocks. How deep a fork/re-organization MUST a conforming implementation handle?  6 blocks? 1000 blocks?  as-many-blocks-as-there-are-in-the-chain blocks?

Does that imply that a confirming implementation MUST be running with a certain amount of memory, or MUST a conforming implementation be able to handle such a chain fork within a certain amount of time?

.. and once you answer all that:  what if the network consists entirely of non-conforming implementations that take shortcuts and just assume that there will never be a re-org more than X blocks deep?

Please stop the "Gavin's decision" meme, too:  I went with the in-the-moment consensus when it became clear that it was POSSIBLE to switch to the 0.7 fork.

And as Melbustus said:  that was only possible because the split was close to 50/50.  If more miners had already upgraded to 0.8, an alert would have been sent to non-0.8 peers telling them to either upgrade or shutdown until we could find a workaround for the problem.

No, that is not true.

The only condition of my visit to the CIA was that I not use the fact that I visited there in any type of advertising.

Well, that and to abide by their normal security while I was there:  no cell phone or other electronic devices allowed, no trying to wander off by myself unescorted.

I am completely free to talk about what happened, and if you buy me a beer sometime I'd be happy to answer any questions you have.  Just not here, too many trolls and I've already spent too much time before and after the trip trying (and failing) to keep the conspiracy theories in check.

The first part of the chain that got orphaned, starting at block 225,430, is here:

  http://skypaint.com/bitcoin/fork08.dat

The first three blocks in the 0.7-compatible chain starting at block 225,430 is:

  http://skypaint.com/bitcoin/fork07.dat

If Mr. Augustus found some documentation that I don't know about it, I genuinely want to know about it, because it will save me time. Right now I'm throwing blocks at an instrumented v0.7.2 bitcoind that tells me how many locks are taken, so I can be sure whatever fix we implement will always work.

Ah, excellent, can you please send me the documentation that says exactly how many locks will be taken by each bdb operation?  I haven't been able to find that.  Thanks!

I think you don't understand how mining works-- there is no such thing as a "faster" miner, just miners with more or less chance of creating the next block.

I think this is exactly right.

But I also think that choosing a larger-but-still-limited block size won't kill Bitcoin (but not raising the block size at all might-- a payment system with a hard seven-transactions-per-second limit is not Satoshi's vision).

It is a problem if you send a transaction from one of the copies of the wallet while it is catching up with the blockchain. You can easily accidentally double-spend yourself, and end up with a transaction that will never confirm.

Deterministic wallets don't solve that problem.

Sigh.

Ok, fine, so do a back-of-the-envelope for what THAT cost is.

Big +1 to d'aniel for doing the work of actually calculating a number, that is very helpful.

Why did you pick 0.0005 BTC ?  That is a mostly arbitrary number.

I estimate a current-worst-case "orphan cost" of an average 250-byte transaction is 0.00008 BTC. See https://gist.github.com/gavinandresen/5044482 (more accurate analyses welcome, I don't pretend to have a monopoly on the "right" answer).

That number will drop as CPUs get faster/cheaper, or bitcoin value rises. So you could argue that even though dust is not economical to spend today, in 20 years it will be.

So I guess I'll rephrase my question again:  Rough, back-of-the-envelope: how much does it cost to keep a dust-like transaction output in the unspent outputs set for 20 years?

If it is a lot, then we should set the "expected time when it will be economical to spend" to either "right now" or "very soon."

If it is tiny, then we shouldn't worry so much about optimizing unspent txout size, and concentrate on other things.

I have no idea what the answer is.