|
Title: problematic scenario with SIGHASH_ANYONECANPAY Post by: BrewMaster on September 04, 2019, 08:37:10 AM (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] Code: [input_ACP, input_1, input_2] [output_1, output_2] Code: [input_1, input_2, input_ACP, input_3] [output_1, output_2] but the problem is if it was signed with SINGLE: Code: [input_ACP] [output_1, output_2] and if someone added their input like this: Code: [input_ACP, input_1] [output_1, output_2] but if someone added their input like this: Code: [input_1, input_ACP] [output_1, output_2] so the question is, am i understanding the way SINGLE | ACP signhash works and is this a problem or am i mistaken? Title: Re: problematic scenario with SIGHASH_ANYONECANPAY Post by: Carlton Banks on September 04, 2019, 03:14:39 PM 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 Title: Re: problematic scenario with SIGHASH_ANYONECANPAY Post by: darosior on September 04, 2019, 04:06:08 PM 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 (https://github.com/libbitcoin/libbitcoin-system/wiki/Sighash-and-TX-Signing) of interest :-) EDIT 2: This is also stated on the OP_CHECKSIG wiki (https://en.bitcoin.it/wiki/OP_CHECKSIG#Procedure_for_Hashtype_SIGHASH_SINGLE) : 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] Title: Re: problematic scenario with SIGHASH_ANYONECANPAY Post by: BrewMaster on September 05, 2019, 04:54:49 AM <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 (https://github.com/libbitcoin/libbitcoin-system/wiki/Sighash-and-TX-Signing) of interest :-) thanks, the pictures in this link were excellent for visualization of what really happens. :) |