BIPs 11, 12 and 13: multisig txns, OP_EVAL, and OP_EVAL addresses

[Gavin Andresen]

Thanks to Amir for agreeing to be the "BIP editor" and getting these up:

https://en.bitcoin.it/wiki/BIP_0011
https://en.bitcoin.it/wiki/BIP_0012
https://en.bitcoin.it/wiki/BIP_0013

[finway]

M-of-N
OP_EVAL

all wonderful ideals,
 i 've got the scenario  of bitcoin beeing used in the real business.

[Andrew Vorobyov]

According to my logic it must say..

Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).

Instead

Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the seller to sign a transaction that sends the tied-up coins to the buyer.

[finway]

According to my logic it must say..

Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).

Instead

Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the seller to sign a transaction that sends the tied-up coins to the buyer.

yeah, that's a mistake. 

[Andrew Vorobyov]

Ok then... just do it,guys... there is bounty from me for this to be done... https://bitcointalk.org/index.php?topic=48215.0

[ByteCoin]

I thought I'd transplant Gavin's post to here, rather than derail the original thread.

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.

Using your link for BIP 0012, I didn't see any reference to a timeline. Found it. It could be more prominent.
What's the timeline for enabling relaying of OP_EVAL transactions and for a client that can generate OP_EVAL transactions?
Also, when will clients be patched to start rejecting blocks with the OP_NOP1 interpretation of OP_EVAL?

I presume that, if all goes well, then on the 1st of Feb 2012, blocks containing OP_EVAL will suddenly be interpreted in the new stricter fashion than when it was OP_NOP1. We know that GetTime() seems to return widely disparate results over the bitcoin network. Are we confident that problems are not going to arise because of the pseudorandomly timed nature of the change of interpretation of the opcode?
This is why I suggested a magic transaction in a block to precipitate the changeover.

Majority hashpower support for OP_EVAL is required before changeover. It's conceivable that something might go wrong after OP_EVAL transactions are mainstream which might make miners revert to interpreting OP_EVAL as OP_NOP1. If OP_EVAL loses majority hashpower support then the bitcoin system keeps going but with considerable damage to reputation, prospects and some people's wallets.
Has there been any consideration of this possibility?
I suggest that OP_EVAL transactions be limited to "toy" amounts of bitcoins until enough of the installed base of clients would reject the OP_NOP1 interpretation of OP_EVAL.

ByteCoin

[genjix]

I propose 3 step phase plan:

step 1. Protocol specifics are definitively agreed upon. No going back after this step. Takes as long as it has too, but ideally 1 month.
step 2. Implementations are all synchronised and ready with branch/patches ready to accept the new changes. Testing needs to be done. 1 month.
step 3. A date is set for the switch-over. Packages are released and all merchants/users/vendors/miners are given a switch-over date before the change becomes live. Enough time needs to be give for everybody to change over. I propose 2 months.

After this and with enough testing, the OP_EVAL can be introduced into the GUI and such after a while. This puts the total timeframe at around under 6 months.

[Gavin Andresen]

I thought I'd transplant Gavin's post to here, rather than derail the original thread.
What's the timeline for enabling relaying of OP_EVAL transactions and for a client that can generate OP_EVAL transactions?

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.

Also, when will clients be patched to start rejecting blocks with the OP_NOP1 interpretation of OP_EVAL?

Same time.

I presume that, if all goes well, then on the 1st of Feb 2012, blocks containing OP_EVAL will suddenly be interpreted in the new stricter fashion than when it was OP_NOP1. We know that GetTime() seems to return widely disparate results over the bitcoin network. Are we confident that problems are not going to arise because of the pseudorandomly timed nature of the change of interpretation of the opcode?

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.

Majority hashpower support for OP_EVAL is required before changeover. It's conceivable that something might go wrong after OP_EVAL transactions are mainstream which might make miners revert to interpreting OP_EVAL as OP_NOP1. If OP_EVAL loses majority hashpower support then the bitcoin system keeps going but with considerable damage to reputation, prospects and some people's wallets.
Has there been any consideration of this possibility?

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

[Gavin Andresen]

I propose 3 step phase plan:

step 1. Protocol specifics are definitively agreed upon. No going back after this step. Takes as long as it has too, but ideally 1 month.
step 2. Implementations are all synchronised and ready with branch/patches ready to accept the new changes. Testing needs to be done. 1 month.
step 3. A date is set for the switch-over. Packages are released and all merchants/users/vendors/miners are given a switch-over date before the change becomes live. Enough time needs to be give for everybody to change over. I propose 2 months.

After this and with enough testing, the OP_EVAL can be introduced into the GUI and such after a while. This puts the total timeframe at around under 6 months.

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