Typos / Minor Possible Confusions about bitcoin-spec HOT 4 CLOSED

Hey Dave,

let me explain your comments in detail.

Likely typo

The point is that the parameters can be balanced out since the only constraint is the total script size. In this particular example, you must use 4-of-5 P2SH Multisig with compressed keys instead of uncompressed ones, otherwise it wouldn't fit anymore. Therefore it is correct. Maybe it could be put in a different way to make this point a bit clearer?

op_return is unspendable

You're absolutely right. I shouldn't conflate transaction types with output-input types. Yet this is done everywhere. When referring to standard transaction types what is actually meant are only the transaction output-input pairs, or in this case only the output. We should mention that point.

Furthermore, indeed the value of a Nulldata is gone forever, as it was just confirmed by @sipa. I'll correct it asap.

Finally, I'll not mention the part about non-standard transactions. This would require to open up a new section and discuss the complete topic, for which I unfortunately don't have time right now.

P2PKH from compressed and uncompressed pubkeys

Indeed, P2PKH adresses can be created from both, compressed as well as uncompressed public keys. I'll correct that in the graphic.

Thanks for your contribution!

from bitcoin-spec.

Typo

That makes sense; sorry for my misreport. I'm sure any confusion will be cleared up when you update the text to cover 0.9.3's increased scriptSig size, as that simplifies the rules.

Note: I thought 0.9.2 matched the redeemScript against the standard transaction scriptPubKey templates, which would mean that 3-of-3 was the limit for both bare multisig and P2SH multisig. However, I couldn't find any code that did that in a quick search of the 0.9.2 codebase. Again, it's probably not worth spending much time on.

Other stuff

Sounds great. Thanks!

from bitcoin-spec.

Indeed when Multisig is used in conjunction with P2SH, then the standard m-of-n rules with m in {1,...,3} and n in {1,...,3} do not hold anymore. Then you only have the restriction of m <= n and n in {1,...,20} afaik as well as the redemption script size restriction of 520 bytes and the total script size restriction of 500 bytes. You can see it in this transaction:

d5e02512d5bb3c44267030fc556695ef4802ab9fa825d6a50be6ddb2083a64f9

If you parse the redemption script, you'll see that it contains 12 compressed public keys.

from bitcoin-spec.

Fixed

from bitcoin-spec.