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.

Satoshi has a bunch of features that he 'figured out from the start' that are not implemented yet; I'll ask him if this is one of them after I figure out exactly what feature I want and convince myself it is possible to do securely.  So I'm going to try to gather my thoughts and see if there is much point:

This is the main problem I was trying to solve:

• A merchant's website should give the customer a unique payment address during the chekcout process.  Ideally, generating that unique address would be done entirely on the web server without requiring a RPC call to a bitcoind process running somewhere.

Communicating with bitcoin or some merchant-services website during the checkout process adds another possible point of payment failure-- it is better for the merchant if their customers can continue to pay them even if their bitcoin daemon (or MyBitcoin or MtGox merchant services) is temporarily down for maintenance.

OP_OVER OP_ADD solves that problem, and, thinking about it, has some other very nice properties.  Here's how it would work in practice:

1. Merchant gets one or more public keys to use for payments.  They're stored in the web server's database.

2. Customer checks out:  web server computes HASH160(public_key+order_id), and converts the result to a bitcoin address version#2 (first byte is not base58-encoded-0, but something else).

3. That bitcoin address makes its way to bitcoin software running on the customer's machine (or at an online wallet service).  Since it is a version#2 address, bitcoin creates an OP_OVER OP_ADD.... transaction for it instead of an OP_DUP ... transaction.

4. Merchant's web server software tells a bitcoind running somewhere "if you see payments to HASH160(public_key+order_id), that's one of mine."

5. When the merchant want's to spend the bitcoins it got from the customer, it has to tell a bitcoind running somewhere the public_key,order_id pair.


If the merchant doesn't completely trust the payment processor then keeping steps (4) and (5) separate is very nice-- the payment processor can't spend the merchant's bitcoins until the merchant tells them the order_ids  (merchant would have to use truly random order_ids to be completely safe, of course).

And, as noted before, this is a little more private than standard bitcoin transactions because the public key isn't revealed until the coins are spent.

You might care if you got the dollar bill from somebody you suspect is working for the Secret Police, you think think the Secret Police might be trying to trace payments by recording bill serial numbers, and you're spending the dollar to pay a local print shop to produce some illegal Subversive Propaganda.

That's roughly similar to tracing bitcoin transactions.

How long is the split?  There's really no problem if the split is less than the block generation maturation time (20+ hours)-- a bunch of miners will be disappointed on one side of the split or the other, but that's about the extent of the damage.

Longer than 24 hours... is kind of hard to imagine for a big country.

Would transactions continue to be processed:  yes, but...  the sudden drop in network hashing rate (and the drastic slow-down in block generation) might trigger future safety checks in Bitcoin, so you might have to do something special to tell it "yes, I really do want to generate transactions even though something weird is happening with the network."

If a little country or region got split from the main network, it will probably have a lot less hashing power and it will take much longer to generate the 100 blocks needed to start to cause problems.  That's a feature, not a bug.

After communication was restored the more-difficulty block chain would "win" and transactions from the losing block chain would get retransmitted and move over to the more-difficulty chain.

If somebody had a super-secret communication channel that worked during the split they could use it to double-spend.  But if the bad guys have a super-secret channel then probably some good guys would, too, and as jgarzik points out, it only takes one little link to relay blocks and prevent a split.

Actually, I'm surprised Mark doesn't remember (or maybe he just didn't want to get bogged down in details)-- he paid for my lunch, and I paid him back in Bitcoins.

Which turned out to be a good deal for him, they went from about 40cents apiece to something like 60cents apiece in the week or so it took him to setup a bitcoin account and give me his receiving address (I paid at the 'when we had lunch' exchange rate, of course).

If you have a bitcoin business and are thinking about advertising, FTL listeners might be a receptive market-- and I bet you might be able to convince Mark and Ian to take payment in bitcoin.

... I think that's right, you don't need the OP_OVER OP_ADD.  You have to know the random number to generate a valid signature, given only its hash.

You'd have to be very careful NEVER to use the same random number anybody else has ever used or will ever use; if your 'random' number is an order number (or even common-hash-of-an-order-number) then you're sunk, anybody can generate a valid <signature> <public_key> <r> triple.

For two extra bytes per transaction it might be better to hash in the public key, just so people don't shoot themselves in the foot.