PULL request #748 : Pay-to-script-hash (OP_EVAL replacement)

[Gavin Andresen]

The consensus from Tuesday's IRC meeting is to replace OP_EVAL with "pay-to-script-hash" -- a simpler, safer-but-less-powerful alternative for creating bitcoin addresses for multisignature and future more-complex transactions.

So please read the BIP: https://en.bitcoin.it/wiki/BIP_0016
And the source: https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash

Important dates:
Feb 1 deadline to try to get 50+% of hashing power to express support.
Feb 15: "full validation" pay-to-script-hash switchover date (assuming success on Feb 1)

[1714965970]

1714965970

[1714965970]

1714965970

[genjix]

pull request: https://github.com/bitcoin/bitcoin/pull/748

[Andrew Vorobyov]

So "King is dead, long live the King"?

[pc]

I've read the BIP, but not the source yet.

The thing that strikes me about this, as well as OP_EVAL before it, is that while it's not a bad solution, it seems to be to be solving the wrong problem. The problem we're trying to solve is that it's the recipient of a payment who really wants control over where the funds ultimately end up. I see this as very similar to problems like that it's often the recipient who wants to determine the amount of the transaction fee to get it in a block. It would be better if there were an easy way for senders to create a transaction, and then instead of broadcasting to miners, sent it directly to the recipient. The recipient would then add their own transaction, to send it to their multisignature vault or to send it to their physical bitcoin bar or to have some go to a transaction fee or whatever, and then the bundle of two transactions would be what gets broadcast out for mining. And miners would be somewhat aware of this transaction bundling such that they would include the transaction with the fee as well as the original transaction based on their rules, since even if the original transaction by itself doesn't have a fee, the bundle does and so they'd get their cut.

Now, I can understand that it seems that the serialized scripts proposal is a bit simpler, and might get people able to actually use multisignature transactions quicker, but I'm not sure that's actually the case (though it very well might be). My proposal (which I don't think was original to me, but I'm not sure where on the boards I've seen these ideas before) would only need to be implemented by recipients that wanted the functionality (by upgrading to clients that could be set with what they wanted to have happen to incoming payments), and miners that wanted to look for transaction fees more smartly could upgrade to get them. To start with, the transmission of the initial payment transaction could use the existing P2P transaction relay system, as I don't think it's a huge problem for most of these scenarios if others in the world are aware of the transaction before the second half by the recipient to put it where they want it, or even if the initial payment ends up in a block first. There's already been talk that we need to at some point have a better transaction transmittal system, regardless of how we get recipients to put funds where they want them, but we can worry about that later if we need it later.

[dbitcoin]

Btw, patches for older versions of the client is ready and tested?

[Mike Hearn]

Payer-provided transactions is something I've been discussing for quite some months now. The intention is that senders can avoid fees, and so can recipients if their risk analysis indicates double spending is unlikely (payment comes from a trusted payer). It needs some changes to Bitcoin to resolve fees recursively across dependencies in the memory pool, and then of course a series of protocols around it to make passing transactions around easy.

I'm heading in this direction with BitCoinJ. It's one reason I think addresses, qrcodes etc will one day disappear and be seen as a legacy of Bitcoins early days, kind of like how "CGI-BIN" is a legacy of the early days of the web which is hardly seen anymore. Instead making a payment will mean uploading one or more transactions to the recipient who will then decide whether to broadcast, keep, or submit directly to a pool.

Gavins motivation with this change is to try and avoid building up new protocols around Bitcoin and let peopl continue to use addresses. I don't agree that this is worth changing the block validation rules (which is an extreme measure in any event), but that's a minority viewpoint and the decision was made already.

[pc]

I'm happy to see that there are people working on the sender-providing-transaction-for-recipient model, and I'm happy that Gavin's working on the fancier scripts model. This is very early in Bitcoin's life, and I think that it's good for the various models to get some work to see what does and doesn't work. As Mike Hearn alluded to, and I know that I've seen this sentiment elsewhere on the boards as well, this is very similar to the early days of the Internet, where there's a lot of potential, the mainstream has no clue that it exists, and it's hard to know exactly how this will all take shape. (Actually, the more I think about it, even the Internet is still really young.) Thank you all for all your work, and I wish that I had the time to contribute more to Bitcoin myself. I look forward to seeing how these various models of how transactions will be created, transmitted, and mined all turn out eventually.

[vess]

Gavin,

Thanks for this work.

Is the intent with BIP 16 to maintain the irrevocability of sending, that is, to ensure that once 'sent' coins will always leave an address, whether or not the script hash is ever proffered?

[notme]

Regarding the transition plans, wouldn't it be preferable to require more than 55% of currently running mining hardware.  Recent graphs show there has been much hardware sitting on the sidelines ready to be restarted.  If 55% support the new validation rules, and immediately after the rules are switched, 10% extra hardware is brought online using old validation rules, that chain could outpace the new validation chain.

[blueadept]

Regarding the transition plans, wouldn't it be preferable to require more than 55% of currently running mining hardware.  Recent graphs show there has been much hardware sitting on the sidelines ready to be restarted.  If 55% support the new validation rules, and immediately after the rules are switched, 10% extra hardware is brought online using old validation rules, that chain could outpace the new validation chain.

Most of the mining hardware will mine in cooperation with existing pools (DeepBit, Slush's pool, Eligius, BTCGuild, etc.).  The pools set the policy for transaction validation and block generation.  The mining hardware only performs partial hash collision attempts.  If enough of the big pools support P2SH to make up 55%, that's unlikely to decrease much if extra mining hardware comes on because most of the hash power will go to those pools.

[notme]

Most of the mining hardware will mine in cooperation with existing pools (DeepBit, Slush's pool, Eligius, BTCGuild, etc.).  The pools set the policy for transaction validation and block generation.  The mining hardware only performs partial hash collision attempts.  If enough of the big pools support P2SH to make up 55%, that's unlikely to decrease much if extra mining hardware comes on because most of the hash power will go to those pools.

You have to think like you want to attack it.  If I'm bringing 10% more power onto the network at that moment, it's for a reason.  If it's only 55%, it doesn't matter who controls that 55%, it's the other 45% plus the 10% additional that matters because you need to get enough of them to join you to outrun the attacker.  But, with how much mining takes place in pools, it shouldn't be too hard to get 75-85% consensus.  That would require at least 25-35% additional force brought on line and would make me more comfortable.

[Gavin Andresen]

If we manage to get 55% or better on Feb 1, then for the next two week's I'll be sending out the message "Upgrade or you might be on the short end of a blockchain split come Feb 15" -- and I expect the result to be a large majority of miners supporting P2SH by the Feb 15'th switchover date. If we're still at 55% on Feb 7'th then I'll be worried, too, and might advise miners to push the hard switchover date a couple of weeks (if they're using the patches I'm creating then it is a command-line argument to bitcoind).

The real danger is for the 45% -- after Feb 15 (assuming the switchover happens) all it takes is for one old miner who is including non-standard transactions in their blocks to create a block containing a transaction that is invalid under the new rules.  They announce the block, and any miners who haven't upgraded would happily build on it, only to waste some hashing power because the 55% majority will sooner or later reject their chain.

However, I don't think anybody will accidentally mine a block spending an 'invalid under the new rules transaction' in it (the number of people mining non-standard transactions seems to be very small), and it seems unlikely an attacker would waste time solving one or more blocks that they knew were going to be rejected by a majority of the network.

[doublec]

However, I don't think anybody will accidentally mine a block spending an 'invalid under the new rules transaction' in it (the number of people mining non-standard transactions seems to be very small), and it seems unlikely an attacker would waste time solving one or more blocks that they knew were going to be rejected by a majority of the network.

You're right, it's unlikely anyone will accidentally do it. But I can guarantee there are malicious people around just itching to cause a bit of havoc in bitcoin. It would be best to plan for the case of "it will happen that someone will mine a block" rather than "I don't think anyone would waste time to".

[Gavin Andresen]

You're right, it's unlikely anyone will accidentally do it. But I can guarantee there are malicious people around just itching to cause a bit of havoc in bitcoin. It would be best to plan for the case of "it will happen that someone will mine a block" rather than "I don't think anyone would waste time to".

Right........

If we're still at 55% on Feb 7'th then I'll be worried, too, and might advise miners to push the hard switchover date a couple of weeks (if they're using the patches I'm creating then it is a command-line argument to bitcoind).

Also, the worst case scenario isn't very scary-- worst case is the less-than-50%-of-miners who did the switch find themselves on the short end of a blockchain split, so they lose revenue (and transactions take longer to confirm because the network is working on two different chains).

That would motivate them to either quickly recruit more hashing power or quickly switch back to the old rules.

[finway]

Scary.

[Luke-Jr]

/P2SH/ should be Rejected as-is. It's at the very least worse than OP_EVAL, and broken by design.

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

The only excuse for this kind of design would be if scriptPubKey were to be deprecated (recommended against all future use, but still supported during a [long] transition period), and this special-casing is a strict backward compatibility mechanism. The current BIP 16 does not (explicitly) say this is the case.

Either BIP 16 should be revised to explicitly deprecate scriptPubKey, or Rejected and replaced with a revised OP_EVAL or some other sane solution.

[Gavin Andresen]

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

No, not "something else", it is "if you see this very-specific sequence of bytes in the scriptPubKey then do this ADDITIONAL validation."

As for saying something in BIP 16 about obsoleting scriptPubKey :  no.  Although I think in the future we'll move towards all transactions being pay-to-script-hash, I think it is dumb to put anything like "we think this is what is going to happen in the future" into standards documents.

Can we keep the big picture in mind?  The reason I'm pushing so hard for "send bitcoins to a multisignature-protected-address" functionality is so users stop losing their bitcoins to malware infecting their computers and smartphones and to scammers.

We can spend more months arguing over trivia, but I would much rather we spent the time thinking hard about, and building, great wallet and escrow solutions that solve Bitcoin's biggest technical problems.

[Luke-Jr]

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

No, not "something else", it is "if you see this very-specific sequence of bytes in the scriptPubKey then do this ADDITIONAL validation."

Ok, so "if you see a program that does X, after executing it, execute something else or you risk losing money"...

As for saying something in BIP 16 about obsoleting scriptPubKey :  no.  Although I think in the future we'll move towards all transactions being pay-to-script-hash, I think it is dumb to put anything like "we think this is what is going to happen in the future" into standards documents.

Deprecation is a common thing in standards documents - just look at all of it in the HTML specifications if you want an example. In any case, this isn't merely "we think this is what is going to happen in the future", it's "what it happening now: scriptPubKey is no longer considered standard, just tolerated/accepted for compatibility". This is implied by abusing it for backward compatibility, but should be explicit.

Can we keep the big picture in mind?  The reason I'm pushing so hard for "send bitcoins to a multisignature-protected-address" functionality is so users stop losing their bitcoins to malware infecting their computers and smartphones and to scammers.

OP_EVAL did that just fine.

We can spend more months arguing over trivia, but I would much rather we spent the time thinking hard about, and building, great wallet and escrow solutions that solve Bitcoin's biggest technical problems.

Breaking the protocol is not trivia.

[Maged]

I hate to bring up the Satoshi argument, but Luke is right. If Satoshi thought that it was better to save a few bytes than to use a standard design, he would have used <pubKeyHash> OP_ADDR1 instead of OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG for the scriptPubKey of a standard address transaction. Worse than that, this is like suggesting that he should have just made it so <pubKeyHash> infers that.

[ByteCoin]

If Satoshi thought that it was better to save a few bytes than to use a standard design, he would have used...

Let's not hold Satoshi's inferred design decisions sacrosanct. There's lots he did well but also lots that's bad.

I sympathise with Luke's misgivings about P2SH. As a solution it seems to fall between the two stools of having a clean scripting language and dispensing with the script language altogether.

Gavin said something like "It's a hack but I like it." - a sentiment typically followed by years of regret.

I suggest that we redefine OP_NOP1 as OP_DO_EVERYTHING and the scriptPubKey should be [20-byte-hash-value] OP_DO_EVERYTHING. This saves an byte which should please Gavin and is clearly not pretending to be anything it's not.

I also propose we take the opportunity to remove miner support for all disabled opcodes and OP_CODESEPARATOR pending the reuse of their values.

ByteCoin