Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the Nonce field in MsgWirePayForMessage #33

Closed
evan-forbes opened this issue Feb 19, 2021 · 7 comments
Closed

Remove the Nonce field in MsgWirePayForMessage #33

evan-forbes opened this issue Feb 19, 2021 · 7 comments
Labels
good first issue Good for newcomers

Comments

@evan-forbes
Copy link
Member

evan-forbes commented Feb 19, 2021

Currently, the nonce in MsgWirePayForMessage is not being used. Instead, the sdk handles the AccountNumber SequenceNumber for the app. The app should be modified so that it follows the spec and handles the nonce inside of MsgWirePayForMessage, instead of relying on the sdk to handle the AccountNumber SequenceNumber.

@evan-forbes evan-forbes changed the title Use the nonce in the transaction, or remove it. Replace AccountNumber with the nonce in MsgWirePayForMessage Feb 19, 2021
@liamsi
Copy link
Member

liamsi commented Mar 16, 2021

is this critical to do before mainnet @adlerjohn? Or in other words: what is wrong with the AccountNumber SequenceNumber?

@adlerjohn
Copy link
Member

Wait the linked issue doesn't help at all! 😂

What does AccountNumber do? How does it affect replay protection, etc?

@evan-forbes
Copy link
Member Author

evan-forbes commented Mar 19, 2021

Whoops, apparently the issue linked confused me as well 😅 . The sdk uses a SequeceNumber instead of a nonce. AccountNumber has something to do with reducing state bloat. Both are handled implicitly by the default sdk.Tx building tools, found here. We are currently using those tools for convenience, but I think we should look into what needs to be done in order to use the most important pieces of those tools, the key handling/signing, while also organizing transactions the way the spec does. This would give us the best of both worlds, the explicitness of the spec, with the safety of battle tested key signing tools.

@evan-forbes evan-forbes changed the title Replace AccountNumber with the nonce in MsgWirePayForMessage Replace SequenceNumber with the nonce in MsgWirePayForMessage Mar 19, 2021
@evan-forbes
Copy link
Member Author

The sdk wraps all the transactions to get around protobuf being nondeterministic, so I think the plan is to now remove the Nonce field from WirePayForMessage and use the AccountNumber already implemented in the auth module/default sdk.Tx

@evan-forbes evan-forbes changed the title Replace SequenceNumber with the nonce in MsgWirePayForMessage Remove the Nonce field in MsgWirePayForMessage Jun 30, 2021
@evan-forbes evan-forbes added the good first issue Good for newcomers label Jul 12, 2021
@github-actions github-actions bot added the Stale label Aug 27, 2021
@github-actions github-actions bot closed this as completed Sep 3, 2021
@evan-forbes evan-forbes reopened this Sep 3, 2021
@evan-forbes evan-forbes removed the Stale label Sep 3, 2021
@liamsi
Copy link
Member

liamsi commented Sep 23, 2021

Looking at MsgWirePayForMessage I think it should not even have any fields other than those that commit to a blob (or multiple blobs for different square sizes). Fee payment could be handled by the auth module I think.

So instead of:
https://github.com/celestiaorg/lazyledger-app/blob/edaba2924a595141d5aa2d23ff12daacf9bfb134/x/payment/types/tx.pb.go#L34-L42

this can probably be just reduced to these fields only:

MessageNameSpaceId     []byte                    `protobuf:"bytes,3,opt,name=message_name_space_id,json=messageNameSpaceId,proto3" json:"message_name_space_id,omitempty"`
MessageSize            uint64                    `protobuf:"varint,4,opt,name=message_size,json=messageSize,proto3" json:"message_size,omitempty"`
Message                []byte                    `protobuf:"bytes,5,opt,name=message,proto3" json:"message,omitempty"`
MessageShareCommitment []ShareCommitAndSignature `protobuf:"bytes,6,rep,name=message_share_commitment,json=messageShareCommitment,proto3" json:"message_share_commitment"`

The PublicKey would already part of the wrapping Tx, specifically in the AuthInfo:
https://github.com/cosmos/cosmos-sdk/blob/94377f1cb3df94ad79e8a741b237be03c9716426/types/tx/tx.pb.go#L38

We can mybe even remove the signatures and use the ones included in Tx?
https://github.com/cosmos/cosmos-sdk/blob/94377f1cb3df94ad79e8a741b237be03c9716426/types/tx/tx.pb.go#L42

The last point might require a modified AnteDecorator if the signatures are for committing to blobs 🤔
https://github.com/cosmos/cosmos-sdk/blob/78c3c4e92d38c00b07fd888e231a91372189fa67/x/auth/ante/sigverify.go#L231

@liamsi
Copy link
Member

liamsi commented Sep 24, 2021

related to above comment: #59, #48 (and has implications on #49)

@evan-forbes
Copy link
Member Author

This issue should have been closed with the merge of #129

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants