See BIP 12, the Backwards Compatibility section, for gotchas-- block chain forks are possible if you're not careful. They won't happen by accident, but if you assume there is an attacker that just wants to cause inconvenience by forking the chain then you have to roll-out the change carefully.

To test on testnet:

Apply the patch. Then use the extended 'validateaddress' RPC command that is part of the patch to get public keys for several of your bitcoin addresses (use getnewaddress to generate new ones if you need to).

Combine those public keys into multi-signature addresses using the new addmultisig RPC command:
   addmultisigaddress <nrequired> <'["key","key"]'> [account]

So for a 2-of-3 escrow you'd call:
   addmultisigaddress 2 '["...pkey1...","...pkey2...","...pkey3..."]'

It returns a multisignature bitcoin address.

You'd do that on all the machines involved in the escrow transaction.

To fund that multisignature address, you just use the normal sendtoaddress (or sendmany or sendfrom) RPC commands, using the address returned from addmultisigaddress.

To spend those funds... more patches are needed.  You CAN actually spend them if you have ALL the private keys in your wallet; if you do, then the multisignature transaction is treated just like any other transaction you've received, and will show up as part of your wallet's balance, in listtransactions output, etc.

Modifying the patch so that you can spend them if you have <nrequired> keys is probably the right thing to do, although the security implications of that for shared-wallet providers needs to be carefully thought through. And in almost all of the real multisignature use cases, a RPC calls to create and sign partially-signed transactions is the right thing to do, NOT importing private keys from the other people involved in the transaction. See: https://gist.github.com/1321518   and  https://bitcointalk.org/index.php?topic=39471.msg597785#msg597785  for a proposal on how to do that.

0.5.0 is next; just working out the last build/deploy issues now...

A day or two after a release is final I always bump the third version number, so somebody running "git head" (the latest source code) has a newer version number.  So there was a 0.4.1 that was never released; the switch to Qt for the graphical UI was a big enough change to justify a jump to version 0.5

I'd like to see one or more of the alt chains take:
  https://github.com/gavinandresen/bitcoin-git/tree/op_eval

... and start supporting OP_EVAL, multisignature transactions, and the new bitcoin address type.

(and thanks to coblee- he (she?) did help flesh out the ideas)

Great!


Unless Mike messed up his implementation of the OP_NOP1 and made it do something other than be a no-op, there should be no problem  (OP_EVAL re-defines OP_NOP1 to do stuff instead of doing nothing, but all OP_EVAL transactions are valid if the OP_EVAL is interpreted as a no-op).


Publish how? I already made a couple of testnet transactions using OP_EVAL; I will make a few on main net (assuming Luke doesn't change Eligius to reject OP_NOP1 transactions). And I wrote thorough unit tests that create valid/invalid OP_EVAL transactions.

What do you mean by "everytime there's a block change" ?

"OP_EVAL" can be anywhere in the coinbase, I'll probably write a little tool using bitcointools to look at OP_EVAL adoption over time will make sure it doesn't care where the string appears.

The beauty of OP_EVAL is it is backwards-compatible with old merchants/users/vendors/miners; there is no reason to require that they all switch over at the same time, they can continue to operate with their old software for as long as they like (assuming all this happens, there will be increasing pressure over time for them to upgrade so they can pay to newfangled BIP 13 bitcoin addresses).

Good question. The timeline for clients is less critical, as long as a majority of hashing power will properly interpret OP_EVAL clients that relay/generate those transactions can be rolled out anytime after Feb 1.

So I'd suggest releasing a 0.5.something or 0.6 after the Jan 15 "are the big miners on board" evaluation that turns on OP_EVAL support Feb 1.


Same time.


Another very good question. The timestamp in the block will be used to determine whether OP_NOP1s in the block are interpreted as no-ops or OP_EVAL when checking block validitity (wall-clock GMT time will be used to figure out if the node should relay/mine OP_EVAL transactions). I'll double-check my code, I think I did NOT code it that way.


That seems exceedingly unlikely; once the big mining pools switch, there is a very strong incentive for the smaller pools to switch, too.

OP_1 through OP_16 push single bytes (0x01 through 0x10) onto the stack.

RE: updating the wiki:  good idea, I'll go do that...

OP_0 pushes an empty array of bytes onto the stack, so you should RIPEMD160(SHA256([])).

(thanks go genjix for setting me straight, I'd been thinking OP_0 pushed a 0x00 onto the stack, and that isn't right.  The scripting engine knows that an empty array is 'False', and FIPS standards make sure hashing empty strings/arrays is well-defined...)

I just sent this email to several of the top mining pools; I'm also putting it here to get wider feedback from "the mining community":

---

I'm writing to the top mining pools to see if you will support Bitcoin Improvement Proposals 11, 12, and 13:
 https://en.bitcoin.it/wiki/BIP_0011
 https://en.bitcoin.it/wiki/BIP_0012
 https://en.bitcoin.it/wiki/BIP_0013

I think they are critical to making Bitcoin more secure for people who have never heard of GPG or AES. They don't solve the wallet security problem, but they put in place low-level mechanisms that will allow higher-level services that DO solve the "computer virus stole my bitcoins" problem. Once multi-signature transactions are supported by the network, Bitcoin wallets can be coded to contact "Wallet Protection Services" to get a second signature/authorization before coins can be spent (details of exactly how the Wallet Protection Service and the client communicate will be in future BIPs). They will also make it possible to create escrow services that cannot spend the bitcoins in escrow among other interesting use cases.

This same feature might be used to keep your pool's bitcoin balances more secure, also-- you could run your own Wallet Protection Code on a separate machine that (perhaps) required manual intervention before providing a second signature on pool payouts if some unusual payout activity was occurring because somebody managed to break your security and get access to the pool's wallet.

I'm proposing extreme caution rolling out support for multi-signature transactions, and, especially, supporting the OP_EVAL feature that allows more secure bitcoin addresses-- and that is why I'm asking you whether or not you're willing to patch your mining pool software sometime in the next two months to support the new 'standard'
transaction types.

I've already written an implementation for Bitcoin 0.5 that will soon become a PULL request.

The new features are backwards-compatible with existing miners and clients, but we do have to be careful when rolling out OP_EVAL because an attacker could create non-standard transactions and try to split the block-chain.

Here is the timeline I've proposed in BIP 0012 :

Now until Jan 15, 2012 : miners update their software, start including CHECKMULTISIG and OP_EVAL transactions in blocks they mine, and indicate support by including the string "OP_EVAL" in the blocks they produce.

Jan 15, 2012: we assess support for the new feature by looking at the percentage of blocks that contain "OP_EVAL". If a majority of miners are not supporting it, then deployment will be delayed or cancelled (a setting in bitcoin.conf controls the switchover date, with the default being Feb 1, 2012).

Feb 1, 2012: assuming there was majority support on Jan 15, OP_EVAL is fully supported/validated.

--------------
Questions I have for you:

Is there anything I can do to make it easier for you to support these new features?  For example, would patches against an earlier version of bitcoind be useful?  (if so, what version?)

Is the timeline reasonable?

Questions you might have:

What happens if you don't support these new transaction types but a majority of other miners do?

If you do not put non-standard transactions in your blocks, then nothing will happen.

If you DO put non-standard transactions in your blocks, then you would be vulnerable to an "invalidate blocks under the new rules" attack, where somebody sends you a transaction that is valid under the old interpretation of the OP_EVAL opcode (which is a no-op) but not valid under the new rules.  Your miner would put that transaction in blocks that you mine, and all of your blocks would be rejected by the majority of miners.

What happens if you DO support these new transaction types but a majority of other miners do not?

All transactions that you put into blocks will be valid under both the old rules and the new rules, so there is no danger that blocks you create will be rejected by the network. There IS a danger that the rest of the network will accept a block under the old rules that you consider invalid under the new rules; that is why I am proposing that we evaluate acceptance of the new rules on January 15.

Can you support one of the BIPs but not all of them?

Yes-- supporting CHECKMULTISIG as a standard transaction type (BIP 11) can safely be deployed right now, there is no danger of a block-chain-split, etc.

BIPs 12 and 13 will let users (or mining pools) use short bitcoin payment addresses to have bitcoins go directly into secure, multi-authentication-required-to-spend wallets.

Anybody know why it says I found a block? I am not mining...

See src/test/script_test.cpp in git HEAD.
Or for more examples of testing script operations, the unit tests I wrote here:
  https://github.com/gavinandresen/bitcoin-git/blob/op_eval/src/test/script_op_eval_tests.cpp
  https://github.com/gavinandresen/bitcoin-git/blob/op_eval/src/test/multisig_tests.cpp

What were you testing that you needed to dedicate about a month of multi-GH mining effort?

1. TxOut scripts are not evaluated until they are spent-- those are probably unspendable TxOuts.

2. The inputs must be valid (you're looking at coinbase txns with no inputs though). Again, TxOuts aren't evaluated until they are used as inputs in another transaction; as long as they deserialize properly they'll be accepted.

3. I don't know of any other bugs in the scripts ops, but I don't know that anybody has written thorough unit tests for them (anybody looking for a good get-your-feet-wet project that could be a good one to tackle; there are already unit tests for CHECKMULTISIG in the repostitory....).

Another quick update:

Wladimir figured out what was breaking the Win32 cross-compiled builds (one of the 'hardening' gcc flags is apparently busted for mingw32 cross-compiles), so Linux and Win32 binaries of a rc2 should be available soon.

Yet another hurdle was thrown in my way by Mother Nature Saturday night; we got over a foot of snow, and my house and home office still have no power. Mac builds won't be available until my main machine has power...

One million percent is a 10,000 times rise in price.
The first trades on bitcoinmarket.com were at a price of something like 0.001 US dollars; 10,000 times that would be $10, and lots of bitcoins traded over $10 earlier this year.

So I think the Fool got it right.

Auto-reset once a month...  very interesting idea.

It'd make a mess of peoples' testnet wallets-- they'd be full of orphaned 0-confirmation transactions.  But deleting your testnet wallet once a month wouldn't be that big a burden, and that should prevent people from trading testnet coins as if they were worth something.

Somebody who wanted to be annoying could still drive up difficulty after every reset and make life miserable for anybody testing their new exchange or merchant software, though.

The problem with just doing more frequent difficulty adjustments is somebody with lots of hashing power can still over-write huge parts of the chain whenever they like. I suppose you could argue that bitcoin services should be written so that they can handle suddenly getting a 600-block-long chain-reorg... but that just does NOT happen on the real bitcoin network.

More hare-brained thoughts: could automatic block-chain lock-ins for the testnet be implemented somehow?  Fetch a block depth/hash pair from a website somebody volunteers to create (auto-updated once a day...) ?

I'm starting this thread to brainstorm rule changes for -testnet and talk about a possible testnet reset for the next release.

The testnet isn't currently usable, because hashing power on it is unpredictable.  Difficulty shoots up because somebody decides to throw lots of machines at it, then they leave and it takes MONTHS for difficulty to drift back down.

Here's a shot at hair-brained rules for the testnet:

+ Fix the difficulty at 1.0, no matter how many people are mining.

+ Clients reject new blocks with timestamps more than 1 minute different from their time (implies:  you have to have an accurate system clock to play with the other nodes on the testnet, otherwise you'll be on your own fork).

+ Clients reject new blocks if their timestamp is less than 2 minutes after the previous best-block's timestamp.

+ Clients prefer to build on blocks that include more memory-pool transactions, instead of taking first-block-they-receive.

Goals behind those rules:
  Always easy to mine
  Limit block-chain growth (max 1 new block every 2 minutes)

So: could a griefer make life miserable for the rest of us under those rules?  What would happen if there were five or six people with a fair bit of hashing power all trying to mine as fast as possible on testnet?  (lots of block chain splits, I think, but that's probably just fine on testnet)

I was just thinking today about resetting the -testnet with new rules to make it more stable/useful...

RE: BIP 0010 :  Cool!

Suggestion:  if we're going to borrow PGP's file format, then we should be as compatible as possible, and reference their standards document:  http://tools.ietf.org/html/rfc2440

In particular, they use Radix64 encoding, not hex...
 

Quick update on why there is no final 0.5 release out yet:

Short answer: because I'm really paranoid about bitcoin binary builds, and the switch to Qt means a change in the way the builds are done.

Long answer:

Linux builds should be all set; the 'gitian' trusted build process works nicely.

Windows builds are being difficult; we need a gcc expert to help debug the 'gitian' cross-compile (see https://github.com/bitcoin/bitcoin/pull/587 ).

Unless somebody steps forward and says "I'll support compiling bitcoin-qt/bitcoind with Visual Studio) I'm going to remove src/makefile.vc and make sure the readmes say that only the mingw toolchain is supported.

Mac builds were slightly broken for the 0.4 release (they don't run on OSX 10.5-- you need 10.6 or greater). I'm "recompiling the world" to hopefully fix that, and hope to have mac binaries available soon (let me know if you can help test, especially if you have a 32-bit Intel mac running 10.5).

On my wish list for builds (anybody want to volunteer?):

I think it'd be spiffy to have a .pro file to compile bitcoind; maintaining N different makefiles is annoying and error-prone.