The P2SH subscript provided in the redemption TxIn must be standard
I don't see what justification there is to enforce standard templates when redeeming P2SH outputs, because no matter how what is in the input script it's all prunable. 
Topic: Standard P2SH encoding for standard transactions (Read 841 times)
The P2SH subscript provided in the redemption TxIn must be standard, though for multisig it's slightly different rules. It's by script size, not (M,N). As such it seems you could do M-of-15 compressed keys, or M-of-7 uncompressed keys, as an upper limit on mainnet.
All P2SH scripts are limited to 500 bytes. If P2SH was to be made mandatory, that would have to be dropped.
Quote
Any scripts that would be non-standard to put into a TxOut should be non-standard when you put them in a TxIn to redeem them. This was actually one of the motiviations for P2SH: I am giving you a script and declaring that money sent to that script absolves you of whatever debt you are trying to cover. It should be my problem, not yours if I want you to send to some crazy script. So it the standardness rules still apply, it just shifts the burden on getting the non-standard script mined to the person who actually controls the money.
I think weaker rules would be better here, since you aren't spamming the blockchain until you prove that you can spend the output. The tx-out -> script map is kept compact.
GMaxwell proposed a system for namecoin to prevent info from being added to the blockchain (like the OP_RETURN system bitcoin has).
You use Hash(x | Hash(script)). The x value is only stored for a while. Once a block is buried 100 blocks into the blockchain, it counts as valid, even if x is missing.
This means you have to tell miners what x you used. It is 'attached' to the transaction, but not part of it. Once a block is buried more than 100 blocks deep, x can be discarded.
It's not a totally unreasonable softfork. The type is already standard & valid, and there's benefits to having 100% of transactions using the same template, moves the bulk of the data to prunable TxIns, and makes TxIn scripts self-identifying.
It would help with the "ultimate blockchain compression" kind of thing.
At the moment, the UTXO set has to be stored as a map tx-out -> script.
With mandatory P2SH, you could save a hash for each output and done (20 bytes). In fact, you could just save part of the hash (8-10 bytes).
Quote
Though probably not worth the effort, and would be much more worth if we were creating a new blockchain with that rule enforced from the beginning. There's still 20 GB of blockchain that don't have that change, so the more-complex rules have to stay in the code to handle arbitrary, non-self-identifying TxIns for the first 20 GB.
It is a fixed cost. You can get around it for legacy transactions anyway.
Define a new "expanded" block and "expanded" transaction.
For an expanded transaction, you append all the non-P2SH input scripts.
An expanded block contains expanded transactions to cover non-P2SH transactions. If it is all P2SH transactions, then the block is the same as now.
For maximum security, the appended info would also need to include the paths to the merkle root.
However, since the client would already be tracking the UTXO set (as hashes) that isn't required.
The switch-over could be
After block N, all transaction outputs must be either OP_RETURN <40 bytes>, P2SH or P2SH-v2 (without the 500 byte limit)
Legacy outputs from blocks <= N still operate as per normal.
After block N + 25000 (6 months), spending them requires that the spender provide the extended transaction format.
moves the bulk of the data to prunable TxIns
Speaking of that, is every redemption of a P2SH output considered standard?The P2SH subscript provided in the redemption TxIn must be standard, though for multisig it's slightly different rules. It's by script size, not (M,N). As such it seems you could do M-of-15 compressed keys, or M-of-7 uncompressed keys, as an upper limit on mainnet.
Any scripts that would be non-standard to put into a TxOut should be non-standard when you put them in a TxIn to redeem them. This was actually one of the motiviations for P2SH: I am giving you a script and declaring that money sent to that script absolves you of whatever debt you are trying to cover. It should be my problem, not yours if I want you to send to some crazy script. So it the standardness rules still apply, it just shifts the burden on getting the non-standard script mined to the person who actually controls the money.
moves the bulk of the data to prunable TxIns
Speaking of that, is every redemption of a P2SH output considered standard?
It's not a totally unreasonable softfork. The type is already standard & valid, and there's benefits to having 100% of transactions using the same template, moves the bulk of the data to prunable TxIns, and makes TxIn scripts self-identifying.
Though probably not worth the effort, and would be much more worth if we were creating a new blockchain with that rule enforced from the beginning. There's still 20 GB of blockchain that don't have that change, so the more-complex rules have to stay in the code to handle arbitrary, non-self-identifying TxIns for the first 20 GB.
Though probably not worth the effort, and would be much more worth if we were creating a new blockchain with that rule enforced from the beginning. There's still 20 GB of blockchain that don't have that change, so the more-complex rules have to stay in the code to handle arbitrary, non-self-identifying TxIns for the first 20 GB.
I think all transactions should use P2SH for encoding transaction outputs.
The network doesn't need to exactly how an output will be redeemed at the time it's created, so exposing this information early accomplishes nothing good.
The network doesn't need to exactly how an output will be redeemed at the time it's created, so exposing this information early accomplishes nothing good.
In addition, it allows static checking of a block. You can verify a block without seeing any other blocks. You just have to make sure the output actually exists though.
I think all transactions should use P2SH for encoding transaction outputs.
The network doesn't need to exactly how an output will be redeemed at the time it's created, so exposing this information early accomplishes nothing good.
The network doesn't need to exactly how an output will be redeemed at the time it's created, so exposing this information early accomplishes nothing good.
It is already a standard type, just no one uses it.
I mean that the reference client could send to P2SH of that form.
it wastes block space.
just Hash160 ( OP_CHECKSIG) is enough
just Hash160 (
Right (ahem).
I assume the general principle has been thought of though? You get all the benefits of a standard transaction, but with P2SH.
It is already a standard type, just no one uses it.
it wastes block space.
just Hash160 ( OP_CHECKSIG) is enough
just Hash160 (
Right (ahem).
I assume the general principle has been thought of though? You get all the benefits of a standard transaction, but with P2SH.
Has something like this been considered?
A standard receive scriptPubKey is of the form
To scan for transactions, you need to compute the hash of the public key and scan for that.
With P2SH, there is no reason that you can't do that too
You scan for a P2SH transaction which pays to
Hash160(OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG)
For each public key, the software would need to scan for 4 encodings, P2SH and normal and compressed/decompressed keys.
This would allow payments to P2SH to be supported much more effectively.
P2SH addresses have a big advantage that they can be verified while only looking at the sigScript. Each element in the UTXO set just needs to be a hash160 value.
A standard receive scriptPubKey is of the form
To scan for transactions, you need to compute the hash of the public key and scan for that.
With P2SH, there is no reason that you can't do that too
You scan for a P2SH transaction which pays to
Hash160(OP_DUP OP_HASH160
For each public key, the software would need to scan for 4 encodings, P2SH and normal and compressed/decompressed keys.
This would allow payments to P2SH to be supported much more effectively.
P2SH addresses have a big advantage that they can be verified while only looking at the sigScript. Each element in the UTXO set just needs to be a hash160 value.
it wastes block space.
just Hash160 (
Has something like this been considered?
A standard receive scriptPubKey is of the form
To scan for transactions, you need to compute the hash of the public key and scan for that.
With P2SH, there is no reason that you can't do that too
You scan for a P2SH transaction which pays to
Hash160(OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG)
For each public key, the software would need to scan for 4 encodings, P2SH and normal and compressed/decompressed keys.
This would allow payments to P2SH to be supported much more effectively.
P2SH addresses have a big advantage that they can be verified while only looking at the sigScript. Each element in the UTXO set just needs to be a hash160 value.
A standard receive scriptPubKey is of the form
To scan for transactions, you need to compute the hash of the public key and scan for that.
With P2SH, there is no reason that you can't do that too
You scan for a P2SH transaction which pays to
Hash160(OP_DUP OP_HASH160
For each public key, the software would need to scan for 4 encodings, P2SH and normal and compressed/decompressed keys.
This would allow payments to P2SH to be supported much more effectively.
P2SH addresses have a big advantage that they can be verified while only looking at the sigScript. Each element in the UTXO set just needs to be a hash160 value.
Jump to: