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

So how do people using master vote against /P2SH/?

I just pulled p2sh into master, replacing the OP_EVAL code that I pulled last month before the controversy erupted.

If you think it is a bad idea, then don't use it.  Hopefully it will inspire you to prove that I'm an idiot and completely wrong about people continuing to use 30-something-character "bitcoin addresses" for the next year or three.

Whilst it's fun to think about these things, could we get agreement on the following things please:

• Redefining the block validation rules is difficult and expensive. If you look how much time has been spent on this rabbit hole already, the last thing we should be seeing are yet more proposals for even more complex changes.
• The whole OP_EVAL/P2SH thing is not required for secure wallets. It is an optimization. You can have a scriptPubKey using CHECKMULTISIGs encoded into an address just fine. It'd be long, but we're talking about a binary data structure encoded as text anyway.

I stress the last part because it's not at all clear to me that addresses containing a script hash are easier for people to add support for than an address containing a full script itself. They're both different types of addresses, and you'll have to do coding work to support either. Ultimately a decoded address just contains bytes. Whether you copy those bytes into a magic scriptPubKey template, or use the bytes as the full contents of a scriptPubKey, doesn't seem to make much difference, except that the latter can be done without any controversial changes to Bitcoins design and the former doesn't.

You can't tell if a txn involves you in the checkmultisig case, either, fwiw.   If clients start tracking and showing users every transaction that mentions an address they have people will just start spamming the network with 2-of-3's where one of the users is a random person.

But more significantly, thats not the case where this P2SH matters most— P2SH style transactions have two most important qualities— they move the storage from output scripts, which are more expensive to store, to input scripts which are less expensive because they are always prunable,  and they allow a recipient of funds to specify their own payment rules in a compact address (and take the fee burden related to complicated payout rules themselves).   This means I can have a multi-agent trust for my organization or a multi-device escrow for my own wallet without having to burden everyone that sends me funds.

Or ideally those 5-6 individuals will vote AGAINST it in this case...

Even if I don't understand deeper all the things of the discussion, this is my opinion:

The Bitcoin project was born to bring evolution the the actual monetary system.
I think that was the main idea: evolution against the old. ( I think also that many are here because of this, and not to simply become rich )
It couldn't born without this main idea, so I think that you should not abandon this line.

You have to push this project always to the best future evolution, and don't protect too much the actual system, even if we can name the actual system "v0.5.1".

If an implementation/idea is going to close many open doors on the evolution of Bitcoin, just to protect the some parts of the actual system ... I think that it's wrong.

Bitcoin project is really young, you can't limit it just now.

I propose OP_NOP1 become OP_CODEHASHCHECK (therefore this proposal is called "CHC"). When this instruction is encountered, it:
1. Extracts all the code in scriptSig from the last OP_CODESEPARATOR (per static analysis) onward
2. Performs a HASH160(code) - call this the "codehash"
3. Compares this codehash to the top item of the stack
4. If this comparison fails, aborts the transaction as a failure

This should be safe, staticly analyzable, and sanely compatible with the existing scripting system.

One downside: there is zero protection enforced by old clients (/P2SH/ at least verifies the spender knows the correct script). I consider this a non-issue since an attacker can find out the correct script as soon as the legitimate spending transaction gets relayed, and so long as the CHC miners have well over 50%, it should be fairly safe by the standard 6 confirmations.

Why is it necessary to rely on a third party escrow service when most transactions could be made without?

For example #bitcoin-otc could provide a list of trusted representatives along with their bitcoin addresses which people can use as arbitrators. An (A + B) or (c) transaction where C is the arbitrator. Using CHECKMULTISIG I could imagine a form in the client with the destination address, a checkbox saying "Require authorisation from self" and an additional field "Add arbitrator" - relatively straight forward and the majority of transaction would not need to involve #bitcoin-otc or the arbitrator. However with P2SH hash #bitcoin-otc needs to have a web service to construct the transaction, users need to copy their public keys into the web service and once the script hash is constructed add it to their bitcoin client.


I started trying to think of different ways split key wallets could maintain compatibility with the existing widespread use of pay to address. The easiest way would be for wallet services to mange the private keys of a number of User's public addresses and automatically forward payments received using a user defined CHECKMULTISIG template.

The other method I came up with started getting a bit complex, but i'll post it anyway:

Redefine OP_NOP1 as a new opcode OP_ATTACH_SCRIPT. Conceptually it would allow the owner of an address to pre register a script which must be run before funds can be redeemed allowing them to change authentication method at their own free without needing to move funds.

After an OP_ATTACH_SCRIPT any successful call to OP_CHECKSIG will cause the top stack item to be inserted into an index using the pubKey as the primary key.
All calls to OP_CHECKSIG in a scriptSig that reference a public key which has an attached script cause the script to be retrieved and executed using the current stack. If the scriptSig contains a OP_ATTACH_SCRIPT it is executed after.

You first need to attach a script to an address by using a transaction with a scriptSig in the following format (example two signature transaction (A + B)).


Execution:

OP_PUSHDATA1 33 {[pubkey2] OP_CHECKSIG} OP_ATTACH_SCRIPT OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG