Bitcoin Forum
December 05, 2016, 08:42:36 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: BIP 16 big picture  (Read 2570 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 26, 2012, 05:21:41 PM
 #1

I just had a great discussion with a developer who urged me to write a "big picture" technical post about BIP 16.  So:

First, I think a good design approach is to be clear about what you are trying to accomplish and think about what the ideal solution, if there were no constraints like backwards compatibility, would look like.

The big picture goal has always been:  short, multisignature bitcoin addresses (BIP 13).

The ideal solution would be to split scriptSig/scriptPubKey into three parts:

signatures, redemption script, and redemption script hash.

The sender would just provide the script hash, the receiver would provide the script and signatures to sign them over to somebody else.

Ideally, the redemption script hash would be include a version or 'hash type' byte, so in the future if RIPEMD160(SHA256()) was ever considered insecure a smooth upgrade could happen.

That's the ideal solution. I think all bitcoin transactions should have been done that way from the start, but it is what it is. Now we have to compromise, because one of the design constraints is backwards compatibility-- we are not going to replace scriptSig/scriptPubKey with something else and require everybody to upgrade all at once.

OP_EVAL tried to do too much, in my opinion.  It enabled all sorts of nifty things, but we made the mistake of losing sight of what we were trying to accomplish.

BIP 16, in my view, meets the goal and (importantly!) does nothing more.  I think of it as implementing the ideal three-way split in as simple and safe way as possible:

signatures:   all the items except the last pushed onto the stack by the scriptSig
redemption script:  the last item pushed onto the stack by the scriptSig
redemption script hash:  the scriptPubKey

It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !



That's all why I like BIP16 better than OP_EVAL.  I've written quite a lot here on the details of why I prefer BIP 16 to BIP 17, but, fundamentally, I believe that BIP 16 is a more conservative solution that is less likely to have an "darn, I didn't see that coming" bug.

How often do you get the chance to work on a potentially world-changing project?
1480927356
Hero Member
*
Offline Offline

Posts: 1480927356

View Profile Personal Message (Offline)

Ignore
1480927356
Reply with quote  #2

1480927356
Report to moderator
1480927356
Hero Member
*
Offline Offline

Posts: 1480927356

View Profile Personal Message (Offline)

Ignore
1480927356
Reply with quote  #2

1480927356
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480927356
Hero Member
*
Offline Offline

Posts: 1480927356

View Profile Personal Message (Offline)

Ignore
1480927356
Reply with quote  #2

1480927356
Report to moderator
1480927356
Hero Member
*
Offline Offline

Posts: 1480927356

View Profile Personal Message (Offline)

Ignore
1480927356
Reply with quote  #2

1480927356
Report to moderator
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
January 26, 2012, 11:09:13 PM
 #2

Hi Gavin,

Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?

Is it possible to address this in the future if not within BIP16?

Thanks
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 26, 2012, 11:17:33 PM
 #3

Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?

Is it possible to address this in the future if not within BIP16?
This can be fixed with or without P2SH of any kind.

interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
January 27, 2012, 12:00:49 AM
 #4

Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?

Is it possible to address this in the future if not within BIP16?
This can be fixed with or without P2SH of any kind.

Yes that's what I thought as well, but since we are doing a major upgrade to the protocol it might be a good chance to take that into account as well.
Or are you saying that the fix is very simple and won't require another heated debate and a fear of a chain fork?

EDIT: if my question seemed like off-topic, I would rephrase it like this:
How is this problem supposed to be fixed in the big picture (ideal situation in Gavin's OP)?
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 27, 2012, 06:49:56 PM
 #5

If i do:
   scriptSig: [signature] {[pubkey] OP_CHECKSIG} OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP
   scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL
It going to execute the check(multi)sig 8 times?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
January 27, 2012, 06:56:00 PM
 #6

If i do:
   scriptSig: [signature] {[pubkey] OP_CHECKSIG} OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP
   scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL
It going to execute the check(multi)sig 8 times?

No. P2SH transactions can only have data in the scriptSig -- the OP_DUPs wouldn't be allowed.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 27, 2012, 07:00:16 PM
 #7

i thought there was an OP_PUSHDATA there..

scriptSig: [signature] {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG}
scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

will execute multiple times?
i think there was a ddos attack based on executing too many check sigs (wasting CPU time on all clients)
what did the patch do to prevent this?

edit:
i think there was some talk here about a multi sig counting to some 200 instructions limit, and that bip16's checksig didnt count for that limit
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
January 27, 2012, 07:03:38 PM
 #8

i thought there was an OP_PUSHDATA there..

scriptSig: [signature] {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG}
scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

will execute multiple times?
i think there was a ddos attack based on executing too many check sigs (wasting CPU time on all clients)
what did the patch do to prevent this?

Only the top item in the scriptSig is taken to be a serialized script. The others there would not be executed.

That DoS attack is still prevented because serialized scripts still have their sigops counted and limited.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 27, 2012, 09:16:54 PM
 #9

Sooo…it seems like the consensus is BIP-16.  What are the next steps?  Getting miners to officially register their intent to support it?

P.S.  This weekend if I can find a little spare time, I want to play around with p2pool.  How does one go about making the software put a vote in the coinbase transaction?

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 27, 2012, 09:17:57 PM
 #10

Sooo…it seems like the consensus is BIP-16.
Don't know where you got that idea.

Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 27, 2012, 09:20:08 PM
 #11

Sooo…it seems like the consensus is BIP-16.
Don't know where you got that idea.
The forum threads on the topic.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
wachtwoord
Legendary
*
Offline Offline

Activity: 1484



View Profile WWW
January 27, 2012, 09:22:27 PM
 #12

By reading the topics on this forum.

Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
January 27, 2012, 09:47:24 PM
 #13

I have to put my support behind BIP 16.  Though BIP 17 is cleaner in some aspects, the serialization of a script to be placed on the scriptSig doesnt bother me and the additional restrictions on what BIP 16 scripts can do seems safer to me.  Adding restrictions without preventing any additional realistic use-cases is, to me, a no-brainer. 

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
RaggedMonk
Sr. Member
****
Offline Offline

Activity: 308



View Profile
January 27, 2012, 11:57:50 PM
 #14

Sooo…it seems like the consensus is BIP-16.
Don't know where you got that idea.

From almost everyone except you  Cheesy
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
January 28, 2012, 09:17:30 PM
 #15

It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !
Except of course that you can't change the hash type - not even to the other hash type that Bitcoin scripts already support, plain SHA-256 - without getting everyone to upgrade and going through the whole process again. As soon as you change the opcode for the hash type the transaction stops being a P2SH transaction and there's no way to make it one anymore.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
January 28, 2012, 11:29:25 PM
 #16

Sooo…it seems like the consensus is BIP-16.
Don't know where you got that idea.

From almost everyone except you  Cheesy

and few others if you read the threads on this issue

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
DiThi
Full Member
***
Offline Offline

Activity: 157

Firstbits: 1dithi


View Profile
January 29, 2012, 12:56:39 AM
 #17

It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !
Except of course that you can't change the hash type - not even to the other hash type that Bitcoin scripts already support, plain SHA-256 - without getting everyone to upgrade and going through the whole process again. As soon as you change the opcode for the hash type the transaction stops being a P2SH transaction and there's no way to make it one anymore.
It wouldn't face the same issues. If there's need for change, it would be just adding a hash function in the validation code. It would be either considered a security problem (so everyone would update as soon as posible) or a non important thing (so everyone updates at its own pace and then people start using it when there's enough support).

1DiThiTXZpNmmoGF2dTfSku3EWGsWHCjwt
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!