problematic scenario with SIGHASH_ANYONECANPAY

[BrewMaster]

(lets call SIGHASH_ANYONECANPAY ACP for short)

ACP allows you to only sign your own input and ignore the rest.

Code:

[input_ACP] [output_1, output_2]

so if others can add their inputs to this transaction like so:

Code:

[input_ACP, input_1, input_2] [output_1, output_2]

or

Code:

[input_1, input_2, input_ACP, input_3] [output_1, output_2]

now this works fine with ALL and NONE since the index of the input_ACP doesn't matter at all.

but the problem is if it was signed with SINGLE:

Code:

[input_ACP] [output_1, output_2]

in this transaction you only sign output_1 from outputs since input_ACP index is 0.
and if someone added their input like this:

Code:

[input_ACP, input_1] [output_1, output_2]

it works fine.

but if someone added their input like this:

Code:

[input_1, input_ACP] [output_1, output_2]

then input_ACP signature would become invalid since now the index of it is 1 and should have signed output_2 instead!

so the question is, am i understanding the way SINGLE | ACP signhash works and is this a problem or am i mistaken?

[1714129137]

1714129137

[1714129137]

1714129137

[Carlton Banks]

so the question is, am i understanding the way SINGLE | ACP signhash works and is this a problem or am i mistaken?

there must be some reason the input script cannot be written in a way that it can be interpreted as ACP as part of the spending script itself, instead of using an input index to reference ACP instead (the scripting language cannot express ACP? if there is an opcode, why not?). there must (of course) be some way of defining which input to a tx is ACP, otherwise using ACP wouldn't be safe to use at all.

maybe ACP is an old part of Bitcoin script that is bound by the consensus rules? I'm not sure

[darosior]

SIGHASH_SINGLE only signs one input and one ouput, bound  by there index, so moving them invalidates the signature. SIGHASH_NONE and SIGHASH_ALL obviously don't need indexes (since they don't need to pick either one of the input or one of the outputs), that's why it works to move them.

EDIT: You might find the libbitcoin doc about SIGHASHES of interest :-)

EDIT 2: This is also stated on the OP_CHECKSIG wiki :

Note: The transaction that uses SIGHASH_SINGLE type of signature should not have more inputs than outputs. However if it does (because of the pre-existing implementation), it shall not be rejected, but instead for every "illegal" input (meaning: an input that has an index bigger than the maximum output index) the node should still verify it, though assuming the hash of 0000000000000000000000000000000000000000000000000000000000000001 [1]

[BrewMaster]

<snip>

i guess since the usage of different sighash types is in special cases which could be called "contracts", then those that are in that "contract" have to come up with agreements like the (SINGLE | ACP) hashtype has to be at index "I" beforehand to avoid problems. but they have to know the problems first.

EDIT: You might find the libbitcoin doc about SIGHASHES of interest :-)

thanks, the pictures in this link were excellent for visualization of what really happens.