"Bitcoin" Redemption script

What are the benefits of using P2SH, based on the Bitcoin improvement proposal Proposition 16th?

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

the benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20 -byte Hash that's short enough to scan from a QR code or easily copied and pasted. You can make the standard scriptpubkey shorter and let the redeemed person construct a complex signature to sovle the redeem script that was created before fund.

Scriptsig = sig + Redeemscript

solved = Eval (scriptsig + sriptpubkey)

Sriptpubkey can be defined very simply when fund:

Scriptpubkey = op_hash160 <SCRIPTID> op_equal

Abstract

This BIP describes a new ' standard ' transaction type for the Bitcoin scripting system, and defines additional validation r Ules that apply only to the new transactions. Motivation

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

The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byt e Hash that's short enough to scan from a QR code or easily copied and pasted. Specification

A new standard transaction type, relayed and included in mined blocks are defined:

    op_hash160 [20-byte-hash-value] Op_equal

[20-byte-hash-value] shall is the Push-20-bytes-onto-the-stack opcode (0x14) followed by exactly bytes.

This new transaction type was redeemed by a, standard scriptsig:

    ..... signatures ... {Serialized Script}

Transactions that redeem these pay-to-script outpoints is only considered standard if the serialized script-also Referr Ed to as the Redeemscript-is, itself, one of the other standard transaction types.

The rules for validating these outpoints if relaying transactions or considering them for inclusion in a new block is a S follows:

Validation fails if there is any operations and other than "push data" operations in the Scriptsig. "Scriptsig only the instructions to press the stack data, such as Other instructions, illegal operation. Normal validation is Done:an initial stack was created from the signatures and {serialized script}, and the hash of the SC Ript is computed and validation fails immediately if it does does match the hash in the outpoint. Create an initial stack (scripts that contain signatures and serialization), validate the order Whether the ID of the serialized script matches the hash specified in the PubKey of the previous trade's output point. If it does not match, discard. {Serialized script} is popped off of the initial stack, and the transaction is validated again using the popped stack and the Deserialized script as the Scriptpubkey. "Pop-up serialized scripts and deserialize into script objects (CScript), That is, with the remnants of the stack signuatures (scriptsig) and bounce out scriptpubkey to verify again. These new rules should only being applied when validating transactions in blocks with timestamps >= 1333238400 (APR 1 2012 )   [1]. There is transaction earlier than 13333238400 in the block chain that fail these new validation rules.  [2]. Older transactions must is validated under the old rules. (See the BACKWArds compatibility section for details).

For example, the Scriptpubkey and corresponding scriptsig for a one-signature-required transaction are:

    Scriptsig: [Signature] {[PubKey] op_checksig}
    scriptpubkey:op_hash160 [20-byte-hash of {[PubKey] Op_checksig}] OP_ EQUAL

Signature operations in the {serialized script} shall contribute to the maximum number allowed per block (20,000) as Follo Ws:

Op_checksig and Op_checksigverify count as 1 signature operation, whether or not they is evaluated. Op_checkmultisig and Op_checkmultisigverify immediately preceded by op_1 through Op_16 is counted as 1 to signature OP Eration, whether or not they is evaluated. All other Op_checkmultisig and op_checkmultisigverify is counted as signature operations. Examples:

+3 Signature Operations:

    {2 [pubkey1] [Pubkey2] [Pubkey3] 3 Op_checkmultisig}

+22 Signature Operations

    {op_checksig op_if op_checksigverify op_else op_checkmultisigverify Op_endif}

rationale

This BIP replaces Bip, which proposed a new Script opcode ("op_eval") to accomplish everything in this bip and more.

The motivation for this bip (and BIP, the Pay-to-script-hash address type) is somewhat controversial; Several people feel that it's unnecessary, and complex/multisignature transaction types should be supported by simply GIV ing the sender The complete {serialized script}. The author believes that this BIP would minimize the changes needed to all of the supporting infrastructure that have alread Y been created to send funds to a base58-encoded-20-byte Bitcoin addresses, allowing merchants and exchanges and other SOF Tware to start supporting multisignature transactions sooner.

"Some people think that it is not necessary to construct pay2scripthash such a transaction, especially some complex, such as multi-signature transactions, rather than directly put the full redeem script into the PubKey inside. But now there are a lot of infrastructure is built on paytoaddress such a transaction type (strange script trading is certainly not wrong, but the platform is not good standard processing), so put the redemption logic into the script scripts, and then the ID of the script to make a 3-beginning address, This also classic payment to the public key, the payment to the public key ID type "Standard" transaction is similar, also can let the platform support multi-signature transaction faster.

Recognizing one ' special ' form of Scriptpubkey and performing extra validation when it was detected is ugly. However, the consensus is and the alternatives is either uglier, was more complex to implement, and/or expand the power Of the expression language in dangerous ways.

The signature operation counting rules is intended to being easy and quick to implement by statically scanning the {Serializ Ed script}. Bitcoin imposes a maximum-number-of-signature-operations per block to prevent denial-of-service attacks on miners. If There is no limit, a rogue miner might broadcast a block that required hundreds of thousands of ECDSA signature Operat Ions to validate, and it might is able to get a head start computing the next block while the rest of the network worked T o Validate the current one.

There is a 1-confirmation attack on old implementations, but it's expensive and difficult in practice. The attack is:

Attacker creates a Pay-to-script-hash transaction that's valid as seen by old software, but invalid for new implementatio N, and sends themselves some coins using it. Attacker also creates a standard transaction that spends the Pay-to-script transaction, and pays the victim Old software. Attacker mines a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions would be invalidated whe n the rest of the network overwrites the attacker ' s invalid block.

The attack is expensive because it requires the attacker create a block that they know would be invalidated by the rest of The network. It is difficult because creating blocks are difficult and users should not accept 1-confirmation transactions for Higher-va Lue transactions. backwards compatibility

These transactions is non-standard to old implementations, which would (typically) not relay them or include them in block S.

Old implementations would validate that the {serialize script} ' s hash value matches then they validate blocks created by so Ftware that fully the support this BIP, but would do and no other validation.

Avoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case:

A Pay-to-script-hash transaction that's invalid for new clients/miners and valid for old clients/miners. To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full valid Ation of the new transaction type and must switch from the old validation rules to the new rules at the same time.

To judge whether or not more than 50% of hashing power supports this BIP, miners is asked to upgrade their software and P UT the string "/p2sh/" in the input of the Coinbase transaction for blocks that they create.

On February 1, the Block-chain is examined to determine the number of blocks supporting Pay-to-script-hash for The previous 7 days. IF 550 or more contain "/p2sh/" in their coinbase, then all blocks with timestamps after the 00:00:00 GMT shall h Ave their Pay-to-script-hash transactions fully validated. Approximately blocks is created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.

If a majority of hashing power does not support the new validation rules and then rollout'll be postponed (or rejected if I T becomes clear that a majority would never be achieved). 520-byte Limitation on serialized script size

As a consequence of the requirement for backwards compatiblity the serialized script was itself subject to the same rules a s any and pushdata operation, including the rule that no data greater than 520 bytes could be pushed to the stack. Thus is it isn't possible to spend a p2sh output if the redemption script it refers to be >520 bytes in length. For instance while the Op_checkmultisig opcode can itself accept-to-pubkeys, with 33-byte compressed Pubkeys it's O Nly possible to spend a p2sh output requiring a maximum of all Pubkeys to redeem:3 bytes + Pubkeys * Bytes/pubkey = 513 bytes. Reference Implementation

https://gist.github.com/gavinandresen/3966071