Topic: PULL request #748 : Pay-to-script-hash (OP_EVAL replacement) - page 3. (Read 12687 times)

Either ignore it and leave the flag set, or reject the transaction as invalid.  Ignoring it should be safe enough, but setting a limit (like 1) will prevent people from spamming up the chain with tons of pointless repeated NOPs.


Bounce the transaction, at least for now.  Maybe some day in the future we will be able to safely handle a full blown OP_EVAL, but we don't have to treat it like one right now.


You could either allow it to be set conditionally when encountered inside the script, or ignore placement and set the flag either way based on finding the opcode during static analysis.  Conditionally setting the flag might actually be useful.  I need to study up on the conditionals, but it could end up being a pretty short path to (N of M) or K, with transactions that could be triggered by either the P2SH script, or by the ordinary key.

We could even require that it be the first opcode for now, with the desire that the restriction be relaxed in the future, if safe to do so.


Well, not really.  There wouldn't be any magic scriptPubKey.  Any valid scriptPubKey could become magic by including the NOP.  In practice, this means that most P2SH scripts would be identical to NOP + the current magic script, but down the road when scripting is better developed, people would be able to trigger P2SH from an arbitrary script, maybe.

It could possibly turn out that there are no useful cases for combining ordinary scripts with P2SH, in which case it would turn out that all we've done is made the magic codes one byte longer.  Even then, having an explicit marker for "hey, I'm a special transaction" could turn out to be worth the ~5% bloat.

So what happens if I put two OP_P2SH's in a scriptPubKey?  What happens if I put one in a scriptSig? What if I put it inside an OP_IF ... OP_ENDIF ?

I think you're really just suggesting that the "magic" scriptPubKey be 24 bytes big instead of 23, and start with one of the NOP opcodes-- yes? In which case there is going to be a special case code path anyway.

Yes, of course. I did most of my testing on 'testnet-in-a-box' nodes, but spent a day producing P2SH blocks and transactions on testnet; see, for example this transaction that spends a P2SH transaction:
  http://blockexplorer.com/testnet/tx/cff697a07fa21780b2553c6e86bf956cb42838b0e9b226da2c6b3cd7754da736

Today I created a smart 'transaction fuzzer', and tomorrow I'll be creating and running stress-tests for the new p2sh and multisignature code to try to catch anything code review and unit tests might have missed.

Yep, I agree but figured I'd ask the question anyway.  Has this been tested on testnet yet?

What you describe is an ugly hack, in my opinion.  But you are right that it is an entirely doable ugly hack.

First, that scheme requires that the recipient have an active node running at all times, or at least often enough to sweep receipts occasionally.  Second, it requires more transactions, up to twice as many, but less if the system gathers multiple transactions before sweeping.  Third, it requires that the extra transactions embed the all of the key hashes, making them rather large, and combined with the second point, it means a lot of needless bloat.  Also, it means a lot of hard to predict fees, since all of the extra transactions will be working from new, fresh transaction outputs.

In P2SH, there are no extra transactions, all transactions can be small regardless of the complexity of the redemption scheme, fees will be low since the ordinary oldest coins first policy can be kept, and it can all be done offline.

Also, I just realized that the sweeping scheme can reduce privacy and anonymity, since a sender will be able to watch for their payment to get swept and try to deduce extra information from the protection scheme.  In P2SH, all details of the protection stay hidden until the coins are redeemed.

I just read the BIP and a few of the messages in this thread (not all).  The BIP states:

"The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer."

Could someone tell me why this is a transaction/protocol level problem and not just limitation of current clients?  Why is it not sufficient to simply solve this problem by having the sender send to a normal address that the recipient then turns around and sends to another address that imposes whatever rules they would like?  This has already been discussed as the approach to enable the recipient to set the transaction fees (sender creates a fee-less transaction and the recipient then sends back to themselves with a fee attached).

It seems to me that this BIP isn't solving an actual problem or limitation and it doesn't actually provide a multi-sig capability.  Why can't multi-sig simply be handled as a two step process…sender crafts a transaction to a normal address that the recipient then sends to an address that imposes a multi-sig rule.  If such transactions are sent directly from sender to recipient, a single use address could be generated by the recipient software, given to the sender and the recipient software would automatically generate the follow-on transaction that moves everything to the multi-sig transaction.  This could all be done in a transparent way for the user (to them, they are just asking the software to create a multi-sig address to give to the sender).

Hey Gavin, what do you think about making the new P2SH transaction recognition explicit rather than implicit?


I think that this would address Luke's (somewhat valid) complaint about the magic transaction special case code path, while still being exactly P2SH.

It's not a big deal to take a few seconds to say this idea won't work or to post a link to where it has previously been discussed. No need to be arsey about it.

P.S. It was not documented that math operations are limited to 4 bytes, for example the BitcoinArmory client will not abide by this.

The code is written and committed to the master branch, backports are available for every bitcoin release since 0.3.19, and I'm as confident as I can be there are no major bugs or "gotchas" hiding in the pay-to-script-hash code. Several of the big mining pools have been testing it and will start deploying it on the main network.

"This stuff" IS programmed in a way so it is only activated on the main network after an agreed-upon time.

There are still two weeks until we look and see how much support it has, and almost a month before /P2SH/ transactions are fully validated on the main network. You want to wait 30,000 more blocks?  More than 7 months? That's a darn good way to get everybody to ignore the issue for 6 months and then restart this debate from square one with 1 month to go and a whole fresh set of people who think they're being helpful suggesting using OP_ADD to combine private keys because they don't realize we thought about and discarded that idea 4 months ago.

I really like the idea of having a full featured scripting engine; and using resource tracking to decide if the script is valid or not.  This is where the cost lies, before the fact static analysis is nice… however the real cost is in the difficulty to execute a script -  not what functions the script implements.

You know Gavin - after some thinking i understand that we need to constantly move forward, but you are perhaps going too fast about this.
Shouldn't there be a longer wait period before implementation of something that can split chains ?

I mean this is a serious change. Shouldn't this be programmed in a way so that it is activated at, for example, block 190.000 ? This way we would lower the risk of splitting chains & stuff.

Why the rush ? This may be actually dangerous for the network. Can't we have more time to adapt ?

The issue you are discussing is way too complex for me to understand, however i got an idea:

Can we perhaps invite all developers (who already wrote "some" Bitcoin code) here to vote on this before implementing in the mainline client ?
Perhaps a closed dev-only poll (done with posts) would suffice.

I read through the bitcoin-dev archive's discussion of OP_EVAL, and don't understand the extent of the concern about Turing completeness.  Guaranteeing resource limits on script execution is important, but runtime constraints like limiting numbers of recursions already go a long way toward imposing these guarantees.  Defense in depth of these guarantees is important, too, but if such a heavily-scrutinized proposal can go months without anyone noting that it affords Turing-completeness then relying on formal analysis Script-the-language to guarantee resource constraints by static analysis is infeasibly delicate and unreliable. 

A more direct and robust defense-in-depth would be for bitcoin's Script implementation to track the resource usage resulting from the execution of each opcode, and reject the script as invalid when usages exceed some thresholds.  If static analysis is currently valuable for miners assessing whether it's worth their while to process a given transaction, then OP_EVAL could be extended to include guarantees on the memory usage and counts of the opcodes and signatures executed by the script which invokes it, guarantees which could be ensured by simply rejecting the script if it violates them. 

Beyond the advantage of greatly strengthening the resource constraints, this approach would probably be much less expensive than junking all the analysis, development and testing put into OP_EVAL so far.

piuk:  please read BIP 0001, it describes the process for getting BIP numbers assigned.

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

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

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

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.

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


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.

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.