Bitcoin Forum
March 28, 2017, 02:11:27 PM *
News: Latest stable version of Bitcoin Core: 0.14.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 6 »  All
  Print  
Author Topic: PULL request #748 : Pay-to-script-hash (OP_EVAL replacement)  (Read 11931 times)
chrisrico
Hero Member
*****
Offline Offline

Activity: 496


View Profile
January 14, 2012, 07:20:43 AM
 #41

Could this be tested on testnet before it becomes mandatory in prodnet? Isn't that a good place to test potentially forking changes?
1490710287
Hero Member
*
Offline Offline

Posts: 1490710287

View Profile Personal Message (Offline)

Ignore
1490710287
Reply with quote  #2

1490710287
Report to moderator
1490710287
Hero Member
*
Offline Offline

Posts: 1490710287

View Profile Personal Message (Offline)

Ignore
1490710287
Reply with quote  #2

1490710287
Report to moderator
1490710287
Hero Member
*
Offline Offline

Posts: 1490710287

View Profile Personal Message (Offline)

Ignore
1490710287
Reply with quote  #2

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

Posts: 1490710287

View Profile Personal Message (Offline)

Ignore
1490710287
Reply with quote  #2

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

Activity: 714


View Profile
January 14, 2012, 02:52:22 PM
 #42

Could this be tested on testnet before it becomes mandatory in prodnet? Isn't that a good place to test potentially forking changes?
It has.

Stefan Thomas
Full Member
***
Offline Offline

Activity: 235


AKA: Justmoon


View Profile WWW
January 14, 2012, 04:06:09 PM
 #43

It basically makes a special-case out of a specific template. This is like saying "if you see a program that does X, instead of executing it, execute something else instead".

True! But this is a valid way to get backwards compatibility when extending a syntax. For example, C preprocessor directives like "#ifdef" are actually comments, but when a compliant preprocessor is present, they are executed before the actual code is compiled. Now, Alan Snyder, when he pushed for the addition of the preprocessor could have instead opted to add "eval" to C or he could have added special operators or keywords. But arguably, using a preprocessor with a backwards compatible syntax for this situation was a better choice.

I don't follow the argument that it's somehow best to solve the issue of moving the script from scriptPubKey to scriptSig on the scripting language level.

The reason we get these awkward domain-specific proposals (OP_DOSOMETHINGVERYSPECIFIC) or ultra-powerful proposals (OP_EVAL) is precisely because it's not generally the job of a programming language to move its own code from one place to another.

For example, to implement OP_CODEHASHCHECK we would need to change EvalScript to know about where scriptSig ends and scriptPubKey begins. The scripting language is not meant to be aware of the block chain, it is meant to be a simple, stack-based language.

P2SH does not require any change to EvalScript. That's because P2SH is not a change to the scripting language at all. It is a backwards compatible change to the block chain, allowing for a hash to reside in the transaction output and for the script to be executed to reside in the corresponding input. That strikes me as much cleaner than meta-opcodes which hack into the interpreter to move code around.

To clarify: I'm not arguing that implementation concerns should guide our protocol-level decisions, but what I am saying is that in this case the implementation hacks hint at a design-level problem. Namely that we are trying to make a scripting language do a preprocessor's job.

Finally, this provides a very pragmatic reason for P2SH. Because it doesn't change EvalScript, it doesn't require nearly as much testing as the other proposals. I'm ok with Luke's idea (in fact I suggested to roconnor that he drop backward compatibility from his OP_CODEHASH proposal and that would have been CHC/CHV), but I prefer P2SH and I would request a much longer testing period if CHC/CHV was accepted.

Twitter: @justmoon
PGP: D16E 7B04 42B9 F02E 0660  C094 C947 3700 A4B0 8BF3
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
January 14, 2012, 04:16:24 PM
 #44

Gavin,

I just wanted to double check that it has been considered what would happen if the serialised script itself matches the P2SH template. From the wording of the BIP it's sounds like it probably has been considered:

Quote
only considered standard if the serialized script is, itself, one of the other standard transaction types.

Otherwise there might be dos potential in a script of the following format:

scriptSig: <sig> <serializedScriptA> <serializedScriptB>
scriptPubKey: OP_HASH160 <scriptBHash> OP_EQUAL

Where <serializedScriptB> deserializes to "OP_HASH160 <scriptAHash> OP_EQUAL".

If only <serializedScriptB> was checked as being standard then a potentially malicious script could be hidden in <serializedScriptA>i.e. <serializedScriptA> could contain hundreds of OP_CHECKSIG's
 

Stefan Thomas
Full Member
***
Offline Offline

Activity: 235


AKA: Justmoon


View Profile WWW
January 14, 2012, 04:24:14 PM
 #45

If only <serializedScriptB> was checked as being standard then a potentially malicious script could be hidden in <serializedScriptA>i.e. you could <serializedScriptA> could contain hundreds of OP_CHECKSIG's

serializedScriptA would never be executed, so it can contain whatever it wants. To the script interpreter it would be just a piece of data. P2SH only transposes the last stack item.

Twitter: @justmoon
PGP: D16E 7B04 42B9 F02E 0660  C094 C947 3700 A4B0 8BF3
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
January 14, 2012, 04:35:37 PM
 #46

P2SH only transposes the last stack item.

Agreed but in my understanding the initial scriptPubKey would transpose <serializedScriptB> into another scriptPubKey that if allowed would transpose <serializedScriptA>. If it isn't already an exception needs to be made so that the scriptPubKey resulting from deserializing <serializedScriptB> it can no longer be interpreted as a P2SH scriptPubKey.

Stefan Thomas
Full Member
***
Offline Offline

Activity: 235


AKA: Justmoon


View Profile WWW
January 14, 2012, 04:47:39 PM
 #47

Agreed but in my understanding the initial scriptPubKey would transpose <serializedScriptA> into another scriptPubKey that if allowed would transpose <serializedScriptB>. If it isn't already an exception needs to be made so that when the scriptPubKey is deserialized from<serializedScriptA> it can no longer be interpreted as a P2SH scriptPubKey.

No, the preprocessor only runs once, so there is no recursion.

Twitter: @justmoon
PGP: D16E 7B04 42B9 F02E 0660  C094 C947 3700 A4B0 8BF3
Brunic
Hero Member
*****
Offline Offline

Activity: 633



View Profile
January 14, 2012, 08:21:52 PM
 #48

Hey guys,

Your work is really crucial, and this modification seems really important. But saying that I understood at least half of it is a lie. At the moment, understanding girls seems easier than what you're talking about.  Grin If you want to have at least 55% of the miners to understand this, explain it clearly and simply.

I was asking an explanation as I were your grandmother.

My grandmother also want to understand. Please, explain to us the big picture if you want the modification to happen. And if you're against, what do you suggest instead (again, in a simple way)?

Thanks!
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
January 14, 2012, 08:30:08 PM
 #49

Please, explain to us the big picture if you want the modification to happen.

At this stage in the proceedings, with the resources out there to educate yourself, if you don't understand what's being discussed, your opinion is not relevant.

ByteCoin
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
January 14, 2012, 09:13:42 PM
 #50

Never mind, i'm an idiot. Proposal withdrawn.

Brunic
Hero Member
*****
Offline Offline

Activity: 633



View Profile
January 14, 2012, 10:03:34 PM
 #51

Please, explain to us the big picture if you want the modification to happen.

At this stage in the proceedings, with the resources out there to educate yourself, if you don't understand what's being discussed, your opinion is not relevant.

ByteCoin

I know my opinion is not relevant on that case, you learn me nothing new. My job is to mine, not to code and discuss Bitcoin scripts about OP_WHOCARES. But my GHash are relevant in that situation, and that's the same for all the miners out there.

I just came here to know about the situation, and help you to inform other miners about this if it worth it. I taught that having a simple message about the modification, so you can convince around 6 THash to adopt this could be a good idea.

But hey, if you don't give a **** about it, that's fine. I'm going to make the extra step in February to be sure that my workers don't support that modification. Seems Luke don't support it, so I'll ask him for any advice if I need them.

Thanks!
notme
Legendary
*
Offline Offline

Activity: 1638


View Profile
January 14, 2012, 10:15:28 PM
 #52

Your opinion matters, but like he said, all the information is out there.  A clear explanation will be given when a new client is released with one of these features if you can't bother to get up to speed to contribute to the decision of which route to take.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
notme
Legendary
*
Offline Offline

Activity: 1638


View Profile
January 15, 2012, 12:26:35 AM
 #53

i dont understand how this thing works, i wont support this because is way to geek for me, since we vote with hashing power i will point my workers to eligius 

What exactly are you opposing?  Nothing has been released yet.  Perhaps instead of picking sides we should focus the discussion on reaching consensus about the advantages and disadvantages of each proposal.  Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
teflone
Hero Member
*****
Offline Offline

Activity: 770


You're fat, because you dont have any pics on FB


View Profile
January 15, 2012, 12:29:44 AM
 #54

i dont understand how this thing works, i wont support this because is way to geek for me, since we vote with hashing power i will point my workers to eligius  

What exactly are you opposing?  Nothing has been released yet.  Perhaps instead of picking sides we should focus the discussion on reaching consensus about the advantages and disadvantages of each proposal.  Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

From what little I gather

p2sh requires a change that is incompatible with the current chain and way of doing things..It ultimatly requires everyone to upgrade..
Which is fine for me, because progress is being made..

Other people are suggesting other ways to allow multiple signatures using the current chain, and not needing an upgrade.

Please please correct me if Im wrong..

I have faith in Gavin.. plain and simple.




For Canadians by Canadians: Canada's Bitcoin Community - https://www.coinforum.ca/
notme
Legendary
*
Offline Offline

Activity: 1638


View Profile
January 15, 2012, 12:37:49 AM
 #55

i dont understand how this thing works, i wont support this because is way to geek for me, since we vote with hashing power i will point my workers to eligius  

What exactly are you opposing?  Nothing has been released yet.  Perhaps instead of picking sides we should focus the discussion on reaching consensus about the advantages and disadvantages of each proposal.  Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

From what little I gather

p2sh requires a change that is incompatible with the current chain and way of doing things..It ultimatly requires everyone to upgrade..
Which is fine for me, because progress is being made..

Other people are suggesting other ways to allow multiple signatures using the current chain, and not needing an upgrade.

Please please correct me if Im wrong..

I have faith in Gavin.. plain and simple.


Every proposal will require upgrade.  That's not the issue.  The question I asked gets at it I believe, hopefully someone more knowledgeable will answer me.  It boils down to adding an OP code vs tainting the scripting system with a special case template.  Gavin just wants to be done with this functionality as this is the second attempt at implementation.  Luke-Jr isn't convinced it's the correct solution and has provided a simpler alternative that extends the protocol with an OP code instead of changing block validation rules.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
January 15, 2012, 12:45:24 AM
 #56

Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

Adding an op code is not a problem, satoshi designed this as the intended upgrade path.

Quote
scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly.

As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack.

notme
Legendary
*
Offline Offline

Activity: 1638


View Profile
January 15, 2012, 12:58:09 AM
 #57

Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

Adding an op code is not a problem, satoshi designed this as the intended upgrade path.

Quote
scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly.

As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack. I hope they will both take a look at https://en.bitcoin.it/wiki/BIP_0017_DRAFT - It could be a good compromise.

Thanks for the clarification... I was thinking of OP_NO_SKIP, but I got it confused with the proposal in Luke-Jr's thread.  Would it be possible to create a pull request to make it easy to see just the OP_NO_SKIP changes from github.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
January 15, 2012, 02:06:24 AM
 #58

I commented on OP_NO_SKIP here: https://en.bitcoin.it/wiki/Talk:BIP_0017_DRAFT

Quote
This will not work. You demand from the txin (the one claiming the output) to do his own verification, by requiring the OP_NO_SKIP to be in the input. Verification should be enforced by the output. What your standard transaction output does is only check that a particular script was pushed on the stack. It does not require its execution.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
January 15, 2012, 03:12:22 AM
 #59

Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

Adding an op code is not a problem, satoshi designed this as the intended upgrade path.

Quote
scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly.

As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack.

OP_P2SH doesn't have to be OP_EVAL.  See here.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
January 15, 2012, 02:51:29 PM
 #60

This will not work. You demand from the txin (the one claiming the output) to do his own verification, by requiring the OP_NO_SKIP to be in the input. Verification should be enforced by the output. What your standard transaction output does is only check that a particular script was pushed on the stack. It does not require its execution.

Yes I caught this mistake after I posted it. Thanks for taking a look anyway.

One more attempt before I give up https://en.bitcoin.it/wiki/BIP_UNOFFICIAL_DRAFT

Pages: « 1 2 [3] 4 5 6 »  All
  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!