Topic: Q about signature verification (Read 850 times)

--K

Sorry for inconvenience IF I am in the wrong POST;

I am going to PRINT a QR into a TANGIBLE coin. Witch DRIVE community/foundation recommends ?

Electrum vs Armory?

Thanks ALL THE BEST for us.

K--

I'm not 100% sure what you are saying here.  Let me back up and use more accurate terms.

A transaction has one or more inputs.

Most transaction inputs have exactly one scriptSig.*

A normal transaction scriptSig has one signature.  A P2SH multisig transaction can have several.

A signature (normal or P2SH multisig) has exactly one associated public key, which has exactly one associated address.**

If you have a P2SH multisig address that requires X-of-Y signatures, and it has received N transactions, and you want to spend them all, that transaction will have between N*X and N*Y signatures.  (In your example, this would be a minimum of 2N and a maximum of 3N.)

As a side note, I just now realized that you were talking about transaction signatures in your first post, not message signatures.  When signing a transaction with P2SH multisig, the pubkeys, their order, and the parameters (how many signatures out of how many possible) are all revealed.  I suppose those could be stripped out if someone wanted to pass around just the bare signature.  For small numbers of signatures (like in 2-of-3), they could be reconstructed.  Note that D would have a valid transaction that he could broadcast if 2 of them are valid.  I'm not positive about the previous two sentences, and I'm not wholly awake yet, so don't rely on them being right

* P2SH is included in "most", we aren't going to worry about nonstandard multisig here.
** Signature verification is done with the public key as a number, not with the pubkey packed representation of that number, while the address is derived from the packed form.  This means that there are actually two possible addresses that could have signed the message, but we'll ignore the compressed one for now.

Appreciated.
Yes, this is pretty much what I expected must be true. I just wasn't sure how. I am not using the reference client, but pybitcointools (and pinging bci and electrum).

Before I go any further, I realise there is something very basic I don't understand. Is it the case that each input has a separate signature? It seems that way from looking at the wiki. So does that mean I will be looking at 3N actual signatures, for N inputs? Previously I had only tried ultra-simple cases with 1 input.

I appreciate there might also be an approach where you just throw the sigs at the transaction and see if it works, but as you say this could require several tries and feels very ugly. Still, if it works, I'm not complaining.

A P2SH multisig address is the hash of a structure containing multiple pubkeys.  A P2SH address can't be used directly for signing, but the pubkeys involved can be.

In the reference client, you must provide an address when checking the signature.  The call returns only true or false.  There is a trivial patch to allow the function to return the address used in signing.  Another trivial patch could return the pubkey directly.

In the OP scenario, the pubkeys are known, so the attacker can tell which of the signatures is invalid.

In general:

If D is using the reference client, and has only the multisig address and the three signatures, he can tell nothing at all.

With the same information, but different software, D can tell that at "least one signature is invalid or the multisig is not 2-of-3".  He does this by pulling the pubkey from each signature, then trying all 6 possible orderings to see if any of them match the multisig address he has.  (This is true of more than just 2-of-3, but the permutations get obnoxious.)

If D has the three signatures, the multisig address, and the three addresses (or pubkeys) that match the address, he can tell which one of them is invalid, and he can tell if the multisig address matches the pubkeys or not.

I'm not sure how the program reacts to invalid signatures. In a 2 of 3 transaction if you had 2 signatures, each of which were valid it would evaluate to true.

OK, but seeing if the transaction evaluates to true wouldn't tell me which signature was invalid if it was false, would it?

You could do it manually in the way you described, or you could just use see if the transaction evaluates to true using your client.

Suppose A,B and C, with known btc addresses and pubkeys, are setting up a multisig 2 of 3 transaction. Suppose a fourth party D asks each of the 3 to deliver a signature for a transaction sending from the msig address.
Suppose that 1 or 2 of A,B,C don't want the tx to go through and deliver invalid signatures.

How easy is it for D to check which of the three signatures delivered are valid? Is it that you can deduce the pubkey from the signature, and then check whether that pubkey corresponds correctly to that for A,B,C?