First: sorry for conflating the off-by-1 and the asymmetric adjustment issues.  As I said, I haven't taken the time to consider changing the bitcoin difficulty adjustment algorithm (too big a change for too little benefit, in my opinion; if we lose 90% of hashing power in a month then there that is a sign something much more serious is wrong with bitcoin than the difficulty algorithm; speculation on what will happen when the block reward drops seems pointless to me, I don't think we'll know until it happens).

Second: I've written 'discourage blocks' infrastructure:
  https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks
  (code reviews welcome)

... which should give us the ability to nudge miners to Do The Right Thing.  Discouraging blocks that appear to be gaming the off-by-one bug should be enough incentive to prevent 50+% cartels from forming, without requiring a blockchain-splitting change.

So in an escrow situation all three parties have to exchange public keys and agree on one particular way of putting them together into a Script that they all agree on (so they all agree on the Script's hash).  That seems OK-- the three parties have to exchange public keys before creating any transactions in any case.

Fine, then ponder this for a while:
  https://bitcointalk.org/index.php?topic=42417.msg517020#msg517020

Executive summary:  asymmetric difficulty adjustments and adjustments based on time are really, really hard to get correct.

I haven't thought about it hard, but I trust ArtForz when he says he thinks it is IMPOSSIBLE to get it right.

He did. He said ArtForz brought them up in the Alternative Currencies board.

See this thread for details:
  https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772

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).