Removing usage of sequence in SignatureV2

[sahith-narahari]

Summary

The current implementation of signatureV2 requires having the correct sequence value set, which can be relaxed to promote a more friendly ux

Problem Definition

Using sequence to set the signature needs us to query the node for sequence value even after we have the signature and sign bytes.
This is also causing us issues in rosetta where the construction combine endpoint has sign bytes and signature but still needs to query the node to fetch the sequence value. This prevents from using current rosetta workflow from working in a complete offline mode.

Is it possible to eliminate use of sequence here, would like to discuss the consequences this change has.

cc\ @alessio @aaronc

Proposal

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alessio]

@clevinson @jgimeno @amaurymartiny @robert-zaremba

[amaury1093]

SignatureV2 is an application logic type, which is easier to manipulate than the raw proto SignerInfo and bytes signatures.

Are you proposing:

1. To remove sequence in SignerInfo and SignatureV2?
2. Only remove sequence in SignatureV2?

If you're proposing 1, then it's a huge client-breaking change. I would advocate against. Initially sequence was not in SignatureV2 (or equivalently, in proto-language, in SignerInfo), then it was decided to be added in #6966

If you're proposing 2, then it seems to me that the conversion SignerInfo->SignatureV2 would lead to loss of information (the sequence field), and I have difficulties seeing how it would work. That being said, I do agree signing types are a bit confusing, and raised #6896 a while ago, so maybe there could be some work done there.

[amaury1093]

Using sequence to set the signature needs us to query the node for sequence value even after we have the signature and sign bytes.

Why? The sequence is already included in the sign_bytes (in SIGN_MODE_DIRECT), you can always extract it from those bytes if needed.

[sahith-narahari]

SignatureV2 is an application logic type, which is easier to manipulate than the raw proto SignerInfo and bytes signatures.

Are you proposing:

1. To remove `sequence` in SignerInfo and SignatureV2?

2. Only remove `sequence` in SignatureV2?

If you're proposing 1, then it's a huge client-breaking change. I would advocate against. Initially sequence was not in SignatureV2 (or equivalently, in proto-language, in SignerInfo), then it was decided to be added in #6966

If you're proposing 2, then it seems to me that the conversion SignerInfo->SignatureV2 would lead to loss of information (the sequence field), and I have difficulties seeing how it would work. That being said, I do agree signing types are a bit confusing, and raised #6896 a while ago, so maybe there could be some work done there.

I agree 1 is something we can't afford at this point of time and my proposal was about 2. Looks like we have come a full circle.

With respect to fetching the sequence from sign_bytes, I don't think it's straight forward(as sequence is part of authinfo) but will take a look to see if we can do this.

[robert-zaremba]

Could you point to a related code for the following issue:

Using sequence to set the signature needs us to query the node for sequence value even after we have the signature and sign bytes.

Removing Sequence from SignatureV2 is rather a bad idea and would lead to a new construction of SignatureV3

[robert-zaremba]

Maybe SignatureV3 could be an interface ;)

[tac0turtle]

we introduced a unordered tx type that would allow this to work from my understanding