wallet2: when checking frozen multisig tx set, don't assume order

[jeffro256]

Resolves #8949

[0xFFFC0000]

Thanks jeffro256.

This PR solves this issue mentioned. I have a suggestion. Wouldn't it be better to check the vector?

For example, pseudocode would be:

exist i in 0 < max(vin) 
    sources[src_idx].multisig_kLRki.ki == vin[i].k_image
otherwise
    assert false;

This way, we keep the assert, and do not fail when there are legitimate order mismatches.

[woodser]

@jeffro256 Can you also open a PR against the release branch? Thanks.

[jeffro256]

Thanks jeffro256.

This PR solves this issue mentioned. I have a suggestion. Wouldn't it be better to check the vector?

For example, pseudocode would be:

exist i in 0 < max(vin) 
    sources[src_idx].multisig_kLRki.ki == vin[i].k_image
otherwise
    assert false;

This way, we keep the assert, and do not fail when there are legitimate order mismatches.

This method is only checking if the key images specified in a multisig_tx_set are frozen. I added in the assertion initially because I thought the key images were ordered, and I figured "why not" keep the assertions conservative so I didn't have to insert twice. However, since insert is idempotent in this case, I cover the case that the lists are mismatched and a counterparty tries to bypass the restriction. At any rate, if mismatched key image key lists cause an actually issue with signing, that's an entire other issue that needs to be addressed in another PR.

[jeffro256]

@jeffro256 Can you also open a PR against the release branch? Thanks.

To confirm, does this PR fix the issue your tests were having? It should, but I want to know

[woodser]

To confirm, does this PR fix the issue your tests were having? It should, but I want to know

I'm getting merge conflicts rebasing on the release branch to test.

[woodser]

I applied the changes manually and they fix the problem as far as I can tell.