Summary of a discussion that happened in IRC chat this afternoon:

There are 10 no-op opcodes that are explicitly for expansion:
  https://github.com/bitcoin/bitcoin/blob/master/src/script.h#L150

They are currently enabled, and do nothing.

If we did the obvious thing and used one of them for OP_EVAL, then, surprisingly, OP_EVAL would not necessarily cause a block chain split.  Why?

Old clients see:
 New clients see:
 
Old clients will consider the transaction valid as long as <serialized_script> hashes to the correct value and is not OP_FALSE, because a script evaluates as valid if it leaves a non-false value on the top of the stack when it is done.

New clients will do full validation: the hash has to be right AND the <serialized script> has to be valid (has to leave a non-false value on the top of the stack).

So:  If upgraded clients and miners start producing transactions and blocks with OP_EVAL in them, they will be accepted by old clients and miners as valid.

That means OP_EVAL could be supported as soon as 50+% of the network hashing power upgraded, instead of requiring that 100% of the network (clients and miners) upgrade before a certain time or block.

Anybody want to volunteer to write a BIP that works through all the details?

Bugs can be reported via the github issues system:
  https://github.com/bitcoin/bitcoin/issues

... although the entire GUI is changing for the next release, so reporting GUI bugs like not being able to sort in the address book will be a waste of time.

I agree. Security is really high on the priority list; I'd like to see secured bitcoin addresses in people's forum signatures within a year. I'm sure one of the alternate blockchains will take this idea and run with it, so much of the hammering-out will happen there.

I split ByteCoin's OP_EVAL post and followups into it's own thread.

RE: be wary of OP_EVAL:

Agreed, we need to think hard about whether or not attackers could Do Evil Things like create an innocuous little script that pushed an infinite amount of data onto the stack or something  (lets see... Serialized(<OP_DUP OP_DUP OP_EVAL>) OP_DUP OP_EVAL would do that...).  Disallowing recursion (no OP_EVALs allowed in the OP_EVAL data) would, I think, prevent all of that mischief.

RE: OP_EVAL means no more IsStandard:  I agree with ByteCoin.  A ScriptSig would be IsStandard if it's ScriptPubKey was IsStandard, and if it's ScriptPubKey was the generic OP_EVAL form then the last value pushed by the ScriptSig would also have to pass the IsStandard test (deserialized into a Script).

RE: data should always be protected by a hash script:  I think the answer is "don't be an idiot" and "use standard transaction types that have been banged on / thought through."

RE: sender/recipient negotiating a transaction: I think that may become the most common way of creating a transaction, but I don't think it will ever be the only way.

-logtimestamps  command-line param or logtimestamps=1 in the bitcoin.conf file.
(I dont' remember when that option was added, a 'git blame util.cpp' will tell you, look for fLogTimestamps)

The new QT GUI (in git HEAD) has a nifty block-chain-download-progress indicator.

I'd like to pull together a version 0.5 release candidate and start testing it early next week.

Maybe the big feature for version 0.6 can be fast initial download (I'm thinking the best thing to do for brand-new, starting-with-an-empty-wallet installations is to download only block headers, function as a 'lightweight' client, and 'backfill' full blocks until you're caught up with the full chain-- then function as a 'full' client).

I like OP_EVAL better than BEGIN...ENDDIGEST.

I'm going to shoot myself in my foot again thinking about stuff late in the day and week when my brain is tired...

... but here are some half-baked thoughts:

The:   DUP HASH160 <hash> EQUALVERIFY   that we're currently using to hash a 65-byte public key into a 20-byte bitcoin address could be generalized into something like:

n DIGEST160 <hash> EQUALVERIFY  :   create a secure 160-bit hash from the <n> items on the stack, make sure it matches a given hash.

That would be very useful for creating multisignature transactions where <hash> is really some arbitrary combination of public keys.

But it would be really spiffy if the complicated transaction could be in the ScriptSig (specified when the coins are spent) and not the ScriptPubKey (so the sender doesn't need to know what kind of transaction they're funding).  Maybe something like:

ScriptPubKey:  END_DIGEST160 <hash> EQUAL

... and the generic ScriptSig would be:

<sig₁> <sig₂> ... <sig_n> BEGIN_DIGEST160 ... an arbitrary script with public keys and CHECKSIGs and stuff....

BEGIN...END_DIGEST160 would create a secure hash for all the opcodes and data between the begin and end.

I think I can convince myself that would always be secure.  Concrete example of the simplest, one-key transaction would be:

ScriptSig:  <signature>  BEGIN_DIGEST160 <public_key> CHECKSIGVERIFY
ScriptPubKey: END_DIGEST160 <hash> EQUAL

Nobody can put another Script in the ScriptSig, because that would change <hash>.
And the signature must be valid because it is checked in the ScriptSig.

If we're going to schedule a blockchain split to support new stuff, something like this seems like the right thing to do.

Yes, I want wallet security and backup as soon as possible, so I want transactions that support that functionality relayed and included in blocks as of the 0.5 release, if possible.

Current state:  (old news for those of you on the bitcoin-development mailing list)
I've made a PULL request for "standard"  (a and b),   (a or b),  (a and b) or c   transactions to eventually support keys split between different devices, wallet backup, and wallet-backup-with-split-keys.
  https://github.com/bitcoin/bitcoin/pull/541


Supporting lockTime or 2-of-3 escrow transactions or more generic 'standard' transaction in the future is certainly possible. Put together a solid pull request that adds support for relaying/including in blocks, with unit tests and a testing plan and, assuming there's general consensus that what you're proposing is safe and secure and is near the top of the "will make bitcoin better" priority list, it will get pulled.

Honestly, I don't think the future of bitcoin is running "heavy" nodes on our personal computers.

I think the vast majority of people will be using bitcoin through web or mobile apps in the not-too-distant future. So I'm not personally inclined to put a lot of effort into splitting the node and wallet, unless that makes creating lightweight web and mobile apps easier.

That said, the new QT gui does a much, much better job of letting you know what bitcoin is doing, both during initial startup and initial blockchain download.

Submit bugs here: https://github.com/bitcoin/bitcoin/issues
Although all of the GUI code is being replaced in the next version, so don't bother submitting UI bugs.

RE: debugging what bitcoin is doing in the 10 minutes it takes for the window to come up:
  tail -f ~/.bitcoin/debug.log
... should tell you what it is busy doing.  Probably loading the block chain and reading the wallet (do you have a very large wallet.dat?)

Very cool etotheipi.

Have you tried using mmap() to page the blockchain file into RAM instead of copying it explicitly? Operating systems are typically very well optimized for accessing mmap()'ed files.

I pulled Bitcoin QT into the master branch of https://github.com/bitcoin/bitcoin/ this morning.

See doc/readme-qt.rst for instructions on building Bitcoin QT.

And I updated doc/build-*.txt; they are now instructions for building bitcoind and don't mention wxwidgets at all.

There are still loose ends to tie up, like modifying the build scripts and the windows installer; I hope to tie those up in the next week or so, and have a release candidate for a version 0.5 available soon.

I pulled Bitcoin-QT into the main bitcoin tree this morning.

Encouraging people to expose their private keys makes me nervous. They're "private" for a reason, and it seems to me the vast majority of private keys will, a few years from now, either be stored on a secure device which is designed to never reveal them or will be split.

Why would a merchant "wish to accept typed or scanned Bitcoin private keys as payment" ? They're going to generate a transaction immediately anyway, it seems to me making a payment that way just opens up more potential ways of getting defrauded (e.g. merchant keeps the private key in case more bitcoins are ever sent to the same address, or merchant sends change to the same address and then a few days later uses the private key to take back the change).

I don't see any privacy or transaction-fee-saving advantages, either; am I missing something?

(I do see the usefulness of importing private keys into your wallet, that's a different feature that I'd like to be in the next release).

I seem to recall (but am too lazy to look up) some interesting research on the gini coefficient for subgroups in the United States; if I recall correctly (and it is very likely I don't), Scandinavian Americans as-a-group have a lower gini coefficient than Scandinavians.

That is either evidence for economic oppression of underprivileged groups in the US, or evidence that culture matters when it comes to economic success, depending on whether you're left-leaning or right-leaning.

A real crash.

In a perfect world, Bitcoin version 0.1 would have included code that looked for a "Bitcoin version X or later required to read this wallet.dat file" setting, and notify the user and exit cleanly if X is greater than the version you're running.

We don't live in a perfect world.

So the second-best solution was to have version 0.4 and later do the "Bitcoin version X or later required to read this wallet.dat file" thing.  And write a value into the wallet that causes previous versions of bitcoin to crash on startup.

If previous versions didn't crash when given an encrypted wallet, they'd just ignore the encrypted keys, generate a bunch of new, unencrypted keys, and give people heart attacks when they ran the old version of bitcoin and told them they had a 0 bitcoin balance.

There is not a donation address for the whole development team; if there was, somebody would have to be in charge of keeping track of the bitcoins, deciding what they should be spent on, etc.

I don't want to be that somebody....

If you like the wallet encryption feature, send bitcoins to:
  Matt Corallo :  1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
and Jeff Garzik : 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj

Matt (aka "BlueMatt" in IRC) did the hard work of making wallet encryption happen, and deserves a ton of credit for being persistent and reworking his Jeff's initial implementation a few times based on feedback and suggestions.

Gregory Maxwell ('gmaxwell') also deserves credit and donations, he gave a lot of feedback and did a lot of testing:
  gmaxwell : 1LjPAUKf23kDBy9sLJbiLfsvjde3ZdHcbJ

(corrected to give Jeff credit for the initial implementation-- sorry Jeff!)

More details are in the doc/README file in the tree:
  https://github.com/bitcoin/bitcoin/blob/master/doc/README#L70