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

Rethink replay protection #151

Closed
ethanfrey opened this issue Jun 30, 2017 · 3 comments
Closed

Rethink replay protection #151

ethanfrey opened this issue Jun 30, 2017 · 3 comments

Comments

@ethanfrey
Copy link
Contributor

Replay protection is super important in a blockchain.

Right now, Basecoin uses sequence to work as a nonce. However this requires all TX to have a Basecoin input.

Can we think of a form of Replay protection that works when not all TX have a Basecoin input.

@ethanfrey
Copy link
Contributor Author

One idea is to make it a generic layer after the sig checking, and use the tx hash of the signed data as a nonce (so you can't just add an extra sig to change it). If it is successfully DeliverTxd, then store that hash in a lookup table, and reject any tx that is in that table.

This would work without each app having to maintain it's own counts (like coin sequence) and the client to remember them all. Also if you have a few outstanding multisig tx, then the sequence number can be rather limiting (okay, i can't send the multisig with you until the other multisig is completed). However, it would also require ~20 bytes per tx, which may grow quite large if we have 10tx/s sustained (-> 860K/day, 300M/year = 6-7GB/year)

Not sure where to find the balance between usability and performance.

@ethanfrey
Copy link
Contributor Author

ethanfrey commented Jul 6, 2017

I think those numbers 6-7GB/year in a very active chain are not actually that bad - we will probably have much more state than that. Let's go for it. We can optimize later by adding a bloom filter.

The changes would be:

  1. Add Nonce int32 to ChainTx, which is filled with a random int on NewChain. This allows the same tx to be intentionally sent twice (Ethan sends Rigel 5 axi every week).

  2. Add the Replay middleware that checks on the hash of the tx bytes, and test it. Also add some benchmarks. (Add some helper function for tx.Bytes() and tx.Hash() that we can also later add to the codegen).

  3. Add the replay middleware in the default stack, right after the Signature middleware

  4. Remove the use of sequence from coins and all the cli as well, as they are no longer needed.

Anything else? Looking forward to a PR, rige :)

@ethanfrey
Copy link
Contributor Author

Okay, this is the same as #160, which is a more clear explanation. Keeping this for history... maybe there were some good ideas here...

alexanderbez added a commit that referenced this issue Apr 5, 2022
* fix logs related to store keys and app hash

* Update log in store/rootmulti/store.go

Co-authored-by: Aleksandr Bezobchuk <[email protected]>

* Update log in baseapp/abci.go

Co-authored-by: Aleksandr Bezobchuk <[email protected]>

Co-authored-by: Aleksandr Bezobchuk <[email protected]>
roysc pushed a commit to vulcanize/cosmos-sdk that referenced this issue Jul 16, 2022
* fix logs related to store keys and app hash

* Update log in store/rootmulti/store.go

Co-authored-by: Aleksandr Bezobchuk <[email protected]>

* Update log in baseapp/abci.go

Co-authored-by: Aleksandr Bezobchuk <[email protected]>

Co-authored-by: Aleksandr Bezobchuk <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant