Patches welcome.

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

When we get close to bumping into the block size limitation it will be easy to convince a majority of the network to upgrade-- that's one problem that is obvious and easy to fix.

Pull request: https://github.com/bitcoin/bitcoin/pull/138/files

From a testnet-in-a-box test, here's what mature/immature blocks look like:

PS:  There is a feature in the core bitcoin code that bothers me because I don't completely understand it:  coinbase transactions are technically spend-able after 100 confirmations (COINBASE_MATURITY in the code), but they aren't counted as spendable by the GUI or the RPC until 120+ confirmations (GetBlocksToMaturity() in the code).  I suppose a big block-chain re-org could run into problems if a just-barely-mature generation was spent at exactly the wrong time, but I need to think about that a bit more (and maybe ping satoshi...).

So...  I'm working on a patch to add < COINBASE_MATURITY-confirmation generation transactions to standard listtransactions, and trying to figure out the right way to handle immature generation transactions.

Either:
a) list them as 'generate' -- they'll just happen to have confirmations < 100 (100 is the COINBASE_MATURITY, although the GUI doesn't show them until confirmations>= 120).

b) list them as 'immature' -- a new transaction category.

I'm leaning towards (b), because that way apps don't have to know that COINBASE_MATURITY is 100, and it is easier to double-check that listtransactions agrees with the getbalance API calls (immature coins are never counted in balances, because they can't be spent until they mature).

The only drawback I can think of is that adding a new transaction category might confuse existing code.

You can't see less-than-100-confirmation generations in listtransactions, but I agree, you should. 

Does anybody have experience with valgrind -helgrind or other automated tools for finding potential deadlocks?

Running it on bitcoind I'm getting a huge number of false positives...

Should we just document every method that holds one or more locks?  I'm worried there are other possible deadlocks lurking.

D'oh!

sendfrom should definitely CRITICAL_BLOCK(cs_main).  Nice catch ArtForz.

No.  The end of the chain can, and does, fork, but the forks are short and the network pretty quickly decides on the One True Chain.

Yes.
Short answer: no.

Longer answer:  it is complicated, and what you need depends on whether or not you're trying to generate new blocks.  To keep it simple, the original client downloads everything.

RE: fractional reserve bitcoin banks:

I think it will happen, too.  Because of the nature of bitcoins they could arrange so that their reserves can be audited by anybody (easiest way:  prove they own a particular bitcoin address by signing something with its private key, then send all their reserves to that address).

Wow!  Great job, excellent video (I like fast), fully deserving of the bounty in my opinion.

And yeah, if it is OK with justmoon I think replacing my Ignite talk on the bitcoin.org homepage with the new video is a great idea.

But how do you know that the transaction the hardware device signed is actually the transaction you wanted to make?  You might THINK you're sending 100BTC to your brother, your computer will SAY you're sending 100BTC to your brother, but the trojan might change the destination address that goes in to the hardware device.

Unless the hardware device has some sort of display and physical button to OK the transaction.  In which case the hardware device sounds a lot like a smart phone.

The Open Bank Project aims:


I was contacted by Ismail CHAIB, who wonders if bitcoiners "might be able and interested to contribute to the project."  If defining an API to help bring more transparency to government, nonprofit, and perhaps corporate finances sounds interesting to you (I'd personally like to see much more government financial transparency):

I think there is a strong possibility bitcoins will end up being used for something none of us is thinking about.  Maybe big multinational corporations will use them to pay their international supply chains in industries that are used to constant deflation.

Making IsStandard() return true if fTestNet is a good idea.

The process for getting a new transaction type into bitcoin would be to test it thoroughly on the testnet, get general consensus on its API and/or GUI and that it is useful, safe, and unlikely to be abused, and work with the 'infrastucture' sites (like blockexplorer and bitcoinmonitor) to make sure the right APIs or hooks are in place so they can do something intelligent with the new transactions.

Neat idea!

As theymos says, this will only work 100% reliably for addresses buried "deep enough" in the block chain that the likelihood of a block-chain-re-org is vanishingly small.

If more bitcoin adoption means bitcoin mining replaces actual, physical gold and silver mining then that should be a net positive for the environment.  Gold mining is dirty, dangerous, and destructive; if bitcoins eventually become "a better gold", then there will be less pressure to dig up virgin wilderness.

Right now, bitcoin mining is inefficient, but natural economic forces will make it become increasingly efficient.  We've already seen that, with more efficient GPU mining replacing CPU mining because you get more hashing for less electricity.

Eventually, I'm confident you'll see big commercial-scale bitcoin mining operations in places where either electricity is clean and cheap to produce, or where the waste heat from bitcoin production is put to productive use (maybe we'll all have network-connected bitcoin-mining space heaters to warm our offices in 10 years).

Before then, we probably will see bitcoin production using cheap, dirty electricity in poorer countries.  If history is any guide, as that helps to make those countries richer their citizens will demand better environmental standards.  Even if we all decided that is unacceptable, I don't see any way to prevent it-- there's no way to tell if a bitcoin was generated using solar panels in the Sahara or dirty coal in Pennsylvania.

Thanks for the positive feedback!

Markus did a great job putting together an outline for what we'd talk about ahead of time, so I had time to plan how to explain complicated concepts like public key cryptography in just a couple of minutes.

In jgarzik's original implementation, an attacker can pre-generate a rainbow table with 2^32 entries, and that lets them take a shortcut so they only have to try 2^32 bits for any particular scratch card (algorithm is, essentially, "foreach value in 2^32: do some complicated math, then see if the result matches a value in the 2^32-size rainbow table; if it does, you've found the unknown 2^64 bits").

The average user will want to use a brand name they're familiar with; if we can continue to convince early adopters that bitcoin is a good idea, eventually PayPal or one of its competitors will start supporting it.  I hope.

I didn't-- the first "community build" took long enough as it was, and I didn't want to add one more 'different from the way it was done before' variable.

Next release I want to automate some of the manual steps, and maybe use the gitian process, assuming it will work inside an Amazon VM (DO nested virtual machines work?).  Unless anybody feels motivated to step in and do it first; with a verifiable build, anybody can take on the role of build-meister.

I don't want to hijack the design discussion...

... but I would like to open up discussion of content.  I'd like to see the bitcoin.org home page to be less about bitcoin-the-software and more about bitcoin-the-currency.

You don't have to download and run any software to run bitcoin, and I think most non-technies are better off using an online wallet service rather than running bitcoin.exe.  So I'd like to see the DOWNLOAD/HOWTO sections moved to a separate page, and have the home page have links to there and to a Wiki page that lists the online wallet services (and starts with a little discussion of the tradeoffs of using an online wallet provider instead of running bitcoin yourself).

I'd be perfectly happy if the design and content was improved (as already discussed) and then the content was changed later, if there's general agreement that de-emphasizing the download is a good idea.