Is your feature request related to a problem? Please describe.
Currently, if two separate signing groups want to sign the same transaction structure, one after another. The FROST signed output must be passed in as the input for the next signing session. However, as the output contains extra information such as the networkID, legacy/zkApp identifiers and so on, it will fail to deserialize on the second instance.
Describe the solution you'd like
We add an extra line in from_str_network which will parse in a TransactionSignature structure and performs the following checks:
- the networkID of the input transaction is the same as the current signing session. Either we error or we print out a warning and continue.
- If we are signing a legacy transaction. Then we should also give a warning/error. A legacy transaction can only have one signer. There's no point signing it again
Additional context
See an example where this is used here: https://github.com/Nori-zk/mina-multi-sig-example/blob/main/CEREMONY-COORDINATOR.md#deploy-ceremony
Is your feature request related to a problem? Please describe.
Currently, if two separate signing groups want to sign the same transaction structure, one after another. The FROST signed output must be passed in as the input for the next signing session. However, as the output contains extra information such as the networkID, legacy/zkApp identifiers and so on, it will fail to deserialize on the second instance.
Describe the solution you'd like
We add an extra line in
from_str_networkwhich will parse in aTransactionSignaturestructure and performs the following checks:Additional context
See an example where this is used here: https://github.com/Nori-zk/mina-multi-sig-example/blob/main/CEREMONY-COORDINATOR.md#deploy-ceremony