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.

Here's my public key, or you can fetch it from the MIT pgp keyserver.  Or it is linked on the bitcoin.org homepage.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (Darwin)

mQGiBEy8srURBADlAamWM3TkgAKyVBVftUsg5aZ3zOA5UAlg+yI/6bzfTkYLtspA
LQ6typamac9re+lqnWdDMa4qVwSmaOMxLOlGhCWWfmA38QprU+ZfuesnxWrVAMG8
TDHLT2vBCa+9iC50soo/imsDqqe6ujm7a+Pd1KSNvFR5KXgEgeEHSiyEqwCg3iAa
DH3lNWzNOgJgi8PUiszqbcsD/2mfNBYJsazYabXcbNdh8VheNnyK2KLUE8Lg1WzU
ld/Sd1gu67oPSFfTiFZ5OBjdHI/XmlFAT4r4eNy1IIf0nELJWWQ6hlzm0a0/DO4b
BUoapjUjAYWDyeeeALDHK7EQboqtwWBlRONyY/+yB9usgbvAK2khRlzBhQonGJEs
FpdQA/9bQzVgpEE1q/ZSnvLp0nOFA3E51SS9uvGGnAdQMjwDp7iGBzh7gRz4ko1k
LG3Sa5fNe21VvlKFcMTaZN9Pd5fDd7gEoDkjUDlf9lRX+YT5zf+SSoeCIGuNMVzs
f8Z2H414dYDOJPBkhYWcqFhGhz11QtWgug5n8GaewC2YOiPU8LQoR2F2aW4gQW5k
cmVzZW4gPGdhdmluYW5kcmVzZW5AZ21haWwuY29tPohmBBMRAgAmBQJMvLK1AhsD
BQku/geABgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQdYgkL74406h8rwCgyMwS
bwfJ+t3B2IRbhnDIsLo4UtAAnRqMmznLBNLe97fbWYjkcgiAkr2UuQINBEy8srUQ
CADLdLYPEFwz9DEMHoQID/USG6QBP8LXVWCy+84aWsR/SMP2k7BmqtiBEOAZvq9j
Tf4/6WoYkU++vDUiq2QefmCnUSfNiD7TcVAQOm631Kg7TkCQU3TZY5rzJ8DAoh2D
vMuYhWVr0grvlJcF6x0A2/YopfR1BO7SNq87LoG/ZqdbFgijNNePBXEfDGG0T0dg
XkZAKsf6v/rgQYWjSgOx1jn/cH7opoum4xyGLVDE+sU3aKBUwaWOV1hLUHWVwgC7
FwXs+nxWPVitR4Ri6aYGlFTrql9DbrQipaybFTRsbdlCrSEpwz5sKK/FE3aRSo5+
+X6fj590uOEPHtu9RDtBcCePAAMFB/9/hCzl8OVZER2fayOTwCauYbt/21D+RvQJ
67bFMMiPxEgWcyueZmpF2Z5KXc61z8mMa831wUNdkkcr2BSr2FEIArlpoynwYHPe
Kyzy1hhhXxdy7uOObicgPMnOx94ZRuvc/xD8LMDLbQ2tpAZn+TCXvwE7fvIxOCnr
6JKUmd2GpQKVnFSbfS9to3pImnZe8OLwoFoBXQ3CBViJo5vYLUHHH+OgIs28PV+8
fcQVJTUQpkDOjNg3fPFd8/YGzaE55+MTqacr5VoSR6aUweMpRCFHNb5PEv/HsY6m
4Q5ypXJBMwWZZlDtiPJnnTaWPwCZLFoj3zEE2VgVGSuoxUMDisPRiE8EGBECAA8F
Aky8srUCGwwFCS7+B4AACgkQdYgkL74406gxCQCfa3UFF31O14UKmnyuJFUTiik+
YBsAoLiC5B6DhN25fJRKWhdvih2hQWrX
=oDeQ
-----END PGP PUBLIC KEY BLOCK-----

I've been thinking a lot about transaction IDs and how to gather signatures for multi-party transactions, too.

For the most part, I think all the details should normally be hidden from users-- I think "Select Transaction Type" is much too geeky.

Thinking out loud, and starting with what I think will be a very common use case:  buyer and seller and somebody to resolve disputes that arise (2-of-3 escrow).

Are you imagining all three are using a bitcoin client? In my head, one might be using bitcoin-qt, another a web-based wallet service, and the dispute resolution would be done by a company with a website. I don't think "we're all running bitcoin on our computers" will be the common case.

So here's how I see it working (my ClearCoin experience may be biasing me):

Buyer and Seller sign up with the escrow service. During signup, they each give the escrow service a public key.  How?
  -- Clunky way:  they poke a "Advanced.... New Public Key" button and then copy&paste a long string of hex
  -- Better way: they poke a link on the escrow status page that does some magic
     (maybe there's a bitcoin:sendnewpublickey?destination=https://www.clearcoin.com/newkey/user1234 URI type that can be made to Do the Right Thing)

Buyer or Seller then creates an escrow at the escrow service's website.
  -- Escrow service creates or assigns a keypair for their part of the 2-of-3
  -- Escrow service creates a newfangled bitcoin address using the 3 public keys.

Buyer sends bitcoins to the newfangled bitcoin address (by clicking on it at the escrow service's page-- it could be a bitcoin:... link)

Escrow service's wallet sees the payment to the newfangled bitcoin address, updates the status page.

Buyer tells seller they paid.  Seller checks the escrow status page, clicks on a "send me the money" link and ships the product to the buyer.

What does the "send me the money" link do?  It needs to get a signature from the seller for a transaction that spends from the 2-of-3 transaction and sends to the seller's wallet.  Another bitcoin: URI that does magical stuff?  (bitcoin:signtransaction?tx=...hex...&destination=https://www.clearcoin.com/... ) Or some other clunky copying-and-pasting of long hex strings?

Days later: Buyer gets the product and is happy. They visit the escrow status page and click on a "send THEM the money" link, which does more magical stuff. Or more clunky copying-and-pasting of hex strings.  In any case, the escrow service gets the second signature and sends the transaction to the bitcoin network, and the coins show up in the seller's wallet.

---

Couple of notes:

I don't see the newfangled-bitcoin-address being part of the buyer's or seller's wallet, and adding it to their wallet would be yet another step.

Need to think about what happens if the escrow service suddenly disappears... they can't steal any coins, but if neither buyer nor seller knows the public key the escrow service is using then they can't complete the transaction by themselves.  Perhaps the bitcoin: URI that the buyer uses to fund the transaction should include all the public keys and should be added to the buyer's wallet...

---

All of this would be much nicer if there was a more user-friendly, security-friendly representation of bitcoin addresses / public keys.

I hate to be a wet blanket, but if "they" wanted to stop this why couldn't "they" simply pass a law stating that it was illegal to buy or sell bitcoins?

Or "they" could impose a punitive tax on purchases or sales of bitcoins.

I suppose my point is: if "they" really want to make bitcoin illegal, then they will find a way to do it; I don't think creating bitcoin derivatives will help much on the legal front.

Depends on who "we" is and what corporate form the Foundation takes...

... but the one of the first orders of business will be more discussions with lawyers who know about those types of things.