Bitcoin Forum
December 05, 2016, 04:41:11 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: BIPs 11, 12 and 13: multisig txns, OP_EVAL, and OP_EVAL addresses  (Read 1559 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
October 25, 2011, 01:30:00 AM
 #1

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


How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480912871
Hero Member
*
Offline Offline

Posts: 1480912871

View Profile Personal Message (Offline)

Ignore
1480912871
Reply with quote  #2

1480912871
Report to moderator
1480912871
Hero Member
*
Offline Offline

Posts: 1480912871

View Profile Personal Message (Offline)

Ignore
1480912871
Reply with quote  #2

1480912871
Report to moderator
1480912871
Hero Member
*
Offline Offline

Posts: 1480912871

View Profile Personal Message (Offline)

Ignore
1480912871
Reply with quote  #2

1480912871
Report to moderator
finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
October 25, 2011, 02:38:22 AM
 #2

M-of-N
OP_EVAL

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


Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 565



View Profile
October 25, 2011, 06:55:16 AM
 #3

According to my logic it must say..

Quote
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

Quote
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
Hero Member
*****
Offline Offline

Activity: 714


View Profile
October 25, 2011, 07:01:23 AM
 #4

According to my logic it must say..

Quote
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

Quote
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
Hero Member
*****
Offline Offline

Activity: 565



View Profile
October 25, 2011, 07:17:19 AM
 #5

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
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
November 02, 2011, 11:22:24 PM
 #6

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
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
November 02, 2011, 11:29:35 PM
 #7

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 03, 2011, 02:36:52 PM
 #8

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.

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

Same time.

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

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

How often do you get the chance to work on a potentially world-changing project?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 03, 2011, 02:46:11 PM
 #9

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

How often do you get the chance to work on a potentially world-changing project?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!