problematic scenario with SIGHASH_ANYONECANPAY

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: Carlton Banks on September 04, 2019, 10:14:39 AM

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.

Quote from: darosior on September 04, 2019, 11:06:08 AM

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.

darosior

sr. member

Activity: 279

Merit: 435

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 :

Quote

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]

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: BrewMaster on September 04, 2019, 03:37:10 AM

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

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

(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?

Topic: problematic scenario with SIGHASH_ANYONECANPAY (Read 209 times)