Old P2SH debate thread

[theymos]

Certainly, twice. gmaxwell's post was well put together; I was hoping to get another perspective on it. He mentions 2 main needs: The 1st (needing receiver controlled disposition of funds) is something I don't the understand the purpose/intent of. Perhaps someone could explain why this is needed.

As jimrandomh mentioned, M-of-N would allow for some important features. The protocol already supports this kind of transaction (so you could theoretically do two-factor authentication now), but there are major drawbacks. In order to do two-factor authentication with the current system, you would need to do one of these things:
- Have everyone sending you BTC use a recent Bitcoin client version and potentially pay higher fees for sending you BTC. Also, your Bitcoin addresses may be double the normal size or larger.
- Every time you receive BTC, the client will automatically need to send the received BTC back to yourself in a new transaction. Received transactions will temporarily not be protected by your two-factor authentication scheme, and you'll pay tons of extra fees.

OP_EVAL, P2SH, and CHC are some proposals for changing the protocol in a backward-compatible way so that these drawbacks are eliminated for two-factor authentication and many other possible future features that require "fancy transactions" (escrow, password-based authentication, etc.). OP_EVAL is broken and will probably not be used. P2SH is probably OK, but the specific way it is implemented is hack-like and inelegant. I like CHC.

[1713502219]

1713502219

[1713502219]

1713502219

[1713502219]

1713502219

[1713502219]

1713502219

[1713502219]

1713502219

[gmaxwell]

Certainly, twice. gmaxwell's post was well put together; I was hoping to get another perspective on it. He mentions 2 main needs: The 1st (needing receiver controlled disposition of funds) is something I don't the understand the purpose/intent of. Perhaps someone could volunteer to briefly explain the key points of why this is needed.

People have different motivations behind this general functionality.

Gavin wants it so that the bitcoin software can offer wallets that require two party signoff (or two of three, or whatever).  When you spend from such a wallet you'd ask one of your second parties for a signature and they might follow up with you via SMS or a phone call.  Perhaps you are the second party yourself, with software on your mobile phone.   In any case the effect is that a hacker or trojan on your system can not steal your bitcoins.

This solves a fundamental weakness bitcoin has right now:  The security of typical desktop computers is terrible and hard to fix.  You might get 0wned up with respect to a classical banking site but they can and _will_ reverse the transactions resulting from your machine being compromised, but we can't do that with bitcoin.  If we want bitcoin to grow we have to solve this problem— bitcoin is not going to grow if it's only safely usable by Linux using security experts.

Personally, (as a Linux using security expert wannabe) I'm more excited about the prospects of using the same functionality to do escrow transactions without requiring any new functionality in the bitcoin code.   I want to sell you a car,  you  don't want me to be able to run off with your funds if the car is a lemon.  We agree to form an address (using a separate tool or potentially a JS webpage) that can only be redeemed if both of us sign off on it.  You pay to the address, putting the funds into escrow— I give you the car— if it doesn't blow up you unlock the txn and I can spend it.

You can use the same functionality to implement trusts and other kinds of fancy payment rules, — and do this all without additional changes to the bitcoin software within the same framework (though you'd need small little external programs to create the special addresses).

These things can be done without P2SH but then they'd require direct support for them in the senders software or  scary (and unwieldy) serialized script addresses, and result in lots of output side chain bloat.

Also, for the wallet-protection use case, without P2SH the _sender_ has to pay the fees related to large transaction data due to complicated rules which are required by you.
 

The second (keeping blockchain bloat in check) is perfectly understandable but seems to be a a secondary concern at best; it this ever becomes a critical issue, I suspect there alternate potential solutions for reducing/controlling the blockchain size that may even be better than what is being proposed.

If you don't think the blockchain size is an issue, I invite you to delete your copy of the chain and restart your client. In 20 hours, most likely, you can tell me if you still agree with that position.    

"alternate potential solutions" are additive with this, not exclusive.  P2SH makes a fundamental improvement to the storage requirements, by moving most of the storage to the input script side it makes the size of a pruned chain much smaller. This is especially important for the large scripts that complicated escrow/trust/wallet-security addresses will require.   It's basically not possible to make the output scripts smaller than BIP 16 (P2SH): they consist of only two bytes more than the payee-hash itself.  (and those two bytes are essential for compatibility with existing nodes).

Other improvements, like public key recovery can be combined with P2SH to make the inputs sides smaller. But thats independent— and applies equally if you're using P2SH or not.

Part of the reason why this isn't a secondary concern is that the use cases that we hope to enable with P2SH would result in transactions which are 2-3x (or more) larger than standard single party transactions with all that data in the script outputs (which are potentially never prunable), so its important that the feature that enables that functionality also contain the solution to the chain bloat it potentially enables.

[Gavin Andresen]

Here's my motivation for /P2SH/ or something like it:

I want to stop playing whack-a-mole with wallet stealing viruses and trojans, and I think requiring more than one private key to sign away your bitcoins is the critical feature needed to do that. Keep one set of keys on your computer, another set of keys on your cell phone, teach each to talk to the other before sending out bitcoins and you're safe (as long as a virus or trojan doesn't infect BOTH your cell phone and your computer at the same time).

The bitcoin protocol already supports that, but the bitcoin network, the bitcoin software, and the bitcoin addresses that we're all using now don't support multisignature transactions.

OP_EVAL and /P2SH/ and Luke's OP_CODEHASHCHECK are all slightly different ways of implementing multisignature transactions that are as short as the bitcoin addresses we're using today.


RE: the timeframe:

I'm pushing this hard because I'm tired of hearing that users lost their bitcoins to trojans and viruses, and getting there is a multi-step process that will take a lot longer than I'd like:

1. First a majority of miners have to validate, accept and mine the new transaction types. (that's the Feb 15 date)
2. Second we have to convince enough people to upgrade so that they are relayed around the network and not dropped
3. Finally, we can release software with wallets that use the new feature.

I'm losing patience because this process started in October, over three months ago, and certain people seem determined to do whatever they can to derail it-- if I was more conspiracy-theory-minded I would think somebody was purposely trying to keep bitcoin less secure than it can be. roconnor brought up legitimate complaints with OP_EVAL that were discussed and addressed with /P2SH/, but I can't respond to every half-baked scheme that is supposedly "better" or I will spend all of my time explaining why something like CODEHASHCHECK is a bad idea and have no time left over to making Bitcoin better.

[DeathAndTaxes]

<snip>

1. First a majority of miners have to validate, accept and mine the new transaction types. (that's the Feb 15 date)
2. Second we have to convince enough people to upgrade so that they are relayed around the network and not dropped

<snip>

I'm losing patience because this process started in October, over three months ago, and certain people seem determined to do whatever they can to derail it-- if I was more conspiracy-theory-minded I would think somebody was purposely trying to keep bitcoin less secure than it can be. roconnor brought up legitimate complaints with OP_EVAL that were discussed and addressed with /P2SH/, but I can't respond to every half-baked scheme that is supposedly "better" or I will spend all of my time explaining why something like CODEHASHCHECK is a bad idea and have no time left over to making Bitcoin better.

I get the frustration of feeling lack you are being pushed back to step 1 four months after the fact.  It sucks in any project and honestly I don't know how core open source developers like you do it.  In my world (corporate closed source software) when an issue like this happens someone up the chain makes a call and we move forward (for better or worse).

Still I don't think you have a choice on the highlighted part. If you want the reason just look at the #1 & #2 you explained above. 

[Luke-Jr]

I'm losing patience because this process started in October, over three months ago, and certain people seem determined to do whatever they can to derail it--

(Just a side note, this is exactly how I feel with Coinbaser, which has been tested and in production for almost a whole year now...)
I don't have any objection to push-to-script-hash in principle, and would prefer it be in soon too - I just don't want to see it done in a way we'll regret for years.

I can't respond to every half-baked scheme that is supposedly "better" or I will spend all of my time explaining why something like CODEHASHCHECK is a bad idea and have no time left over to making Bitcoin better.

OP_CODEHASHCHECK is in some ways even a bugfix (OP_CHECKSIG almost does it), and seems like it could be done with much less modifications than the other two schemes, in addition to being both (much easierly!) staticly analyzable and in form with the original script design. If there are real problems with this solution, please do share them, as part of making Bitcoin better.

[piuk]

Just to explain for those that don't know. You can already receive payments to a split key wallet using OP_CHECKMULTISIG which is already implemented and requires no change to block validation rules. However you would need to use a double length bitcoin address. e.g.

1CCPUpxshNH5EPetALLDhz56dg3soyrHEELKLdDRCkwH1MPN1q8fcpzBA3tiRJfSY9S

you can of course can use tools like firstbits to shorten this to just a few characters. Its not ideal, but if split key wallet services can already use it I don't think there is any need to rush in something which would make irreversible changes to the concept of a bitcoin script .

[DeathAndTaxes]

Just to explain for those that don't know. You can already receive payments to a split key wallet using OP_CHECKMULTISIG which is already implemented and requires no change to block validation rules. However you would need to use a double length bitcoin address. e.g.

1CCPUpxshNH5EPetALLDhz56dg3soyrHEELKLdDRCkwH1MPN1q8fcpzBA3tiRJfSY9S

you can of course can use tools like firstbits to shorten this to just a few characters. Its not ideal, but if split key wallet services can already use it I don't think there is any need to rush in something which would make irreversible changes to the concept of a bitcoin script .

Except the sender will pay the extra fees (due to larger transactions) for your security.  Obviously that relationship is backwards. 

Sender - pays more
Receiver - is safer

If you asked me for payment at that address I would ask you for another address on principle alone.

[Luke-Jr]

Here is an example CHC (herein called OP_CHECKHASHVERFIY or CHV) implementation. Can it get any simpler?

[finway]

Shame on you.

[finway]

This would've been a lot better received if it was brought up while the technical discussions were still ongoing. I originally proposed something like OP_EVAL in https://bitcointalk.org/index.php?topic=46429, and I think P2SH achieves everything I wanted out of that. CODEHASHCHECK is arguably better, but only slightly - certainly not by enough to justify delaying deployment. Getting some sort of multisig transactions working is rather urgent, and P2SH is the implementation we have, and it carefully avoids opening any cans of worms.

What this really seems to be about is politics - LukeJr is uncomfortable with Gavin having the power to alter the Bitcoin protocol. I think that this power should be phased out eventually--but not yet. We'll mark that transition with a "1.0" version number. We still need protocol improvements. Gavin's shown no indication that he'd ever abuse his position, and he's the only one who's actually putting in the work required. And this is a really bad time to start a power struggle, because LukeJr isn't really going against Gavin - he's going against the output of a community discussion which he didn't take part in.

(As for the technical side - the issue seems to be that P2SH introduces a new interaction between the concept of "standard transactions" and the scripting system. Before, a transaction would be accepted if it was standard and the script returned success; now there's an additional requirement, which is that one of the standard transaction types now calls for you to rerun the script in a different way. This means that the "standard transactions" concept is now actually part of the scripting system, rather than a secondary sanity check, so it can't be fully dropped in the future. However, the special case is on the sender-script side, and I don't think allowing nonstandard scripts there was ever plausibly a good idea. I do still want to see the standard-transaction types broadened to include fancy tricks with time locking, but that's considerably less urgent.)

^this.
It's urgent, and what luke-jr doing is stalling.

[finway]

And again,
Gavin write OP_EVAL, you oppose.
Gavin write P2SH, you oppose.
You propose CHC, where's the code?

With no code, you propose a vote?
 

[piuk]

I still haven't figured out how OP_CODEHASHCHECK is intended to work, so I wouldn't say that I'm a convert exactly.

Here is my explanation of luke's proposal as I understand it. Standard script template for a single key would be:

scriptPubKey: <scriptHash> OP_CHECKHASHVERIFY
scriptSig: <sig> OP_CODESEPARATOR <pubKey> OP_CHECKSIG

1) Combine ScriptSig & ScriptPubKey

   <sig> OP_CODESEPARATOR <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

2) <sig> is pushed onto the stack
   
   OP_CODESEPARATOR <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

3) OP_CODESEPARATOR marks the beginning of the data to be hashed

   <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

4) <pubKey> is pushed onto the stack

   OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

5) OP_CHECKSIG validates <sig> and <pubkey> as normal

   <scriptHash> OP_CHECKHASHVERIFY

6) <scriptHash> is pushed onto the stack

   OP_CHECKHASHVERIFY

7) Everything from the marker that was set at OP_CODESEPARATOR up to stack -1 is hashed and compared with the top stack item e.g. <scriptHash>. If equal the script is valid.

Advantages
- Like P2SH hash enables "pay to script" functionality - transfers multiSig fees from sender to receiver & reduces muliSig blockchain bloat.
- The script interprets as a script, no magic code path based on template matching.
- Static analysis without deserializing anything.
- Fairly simple, should be just as fast to get it in use as P2SH. Luke has coded it already.

Disadvantages
- Old clients validate almost nothing, with P2SH they at least check the <scriptHash> matches the <script>
- Requires redefinition of an op code

[finway]

And piuk, implement your idea, and make a pull request.

[finway]

While I disagree strongly with the monarchial powers being given to Gavin, that is not the basis for my objection to BIP 16 specifically.

Well, luke, if you implement your CHC idea before 1st Feb, maybe you'll get that monarchial powers . 

[Luke-Jr]

Gavin write OP_EVAL, you oppose.

Hmm, what? I didn't/don't oppose OP_EVAL.

You propose CHC, where's the code?

A few posts above yours.

Well, luke, if you implement your CHC idea before 1st Feb, maybe you'll get that monarchial powers .  

I don't want monarchial powers. If people wanted a monarchial currency, they'd be using USD. I just don't want Bitcoin broken in a rush to get a new feature.

[rjk]

finway, spam much? Lay off the crack, dude. That was like 5 posts in as many minutes.

[markm]

SInce Gavin apparently does not have time to explain why Luke's solution is bad, can someone else maybe do so?

Or is everyone still flailing around trying to find something bad about it and maybe not having much success in doing so?

-MarkM-

[finway]

...

[notme]

SHUT UP!

Do that please.

Code is here:

Here is an example CHC (herein called OP_CHECKHASHVERFIY or CHV) implementation. Can it get any simpler?

Posted 10 hours ago...

[finway]

With code that make sense, does it work? 
Dose is solve the "Special Case" problem?  does it cause a split?