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

Example of using Signed Extension #67

Open
JoshOrndorff opened this issue Oct 21, 2019 · 2 comments
Open

Example of using Signed Extension #67

JoshOrndorff opened this issue Oct 21, 2019 · 2 comments
Labels
new recipe 🍳 Request to add a new recipe

Comments

@JoshOrndorff
Copy link
Owner

This topic came up during SCL today.

Some possible example scenarios.

A transaction should only be valid:

  • after a certain block height
  • before a block height
  • after/before a timestamp
  • in blocks with an even height
  • in blocks with an even hash
@JoshOrndorff
Copy link
Owner Author

Basti on riot:

Do you know how to verify a signature?
Basically you a bunch of data of the transaction is used to build the signature
Like the call
Sender and whatever
Now you can also have SignedExtensions
Like the CheckGenesis
This is special, as it does not adds data to the overall transaction (so that the size would grow), it justs provides data for the signature building
That is what additional_signed is for, providing data that should be added to the signature
But we don't need to add it to the transaction as data, as the blockchain itself should know its genesis hash
Now let's fast forward to dispatching a transaction in the runtime
Before we dispatch a transaction, we need to make sure that the signature matches, as otherwise everybody could have send the transaction
So we rebuild the transaction data that should be used for building the signature
In this process we CheckGenesis::additional_signed will be called and will return the genesis hash
If the genesis hash returned in the runtime is a different than the genesis hash used to build the transaction outside of the runtime, it will lead to a different signature
And thus, your transaction will not be dispatched and tagged as invalid

@shawntabrizi on riot

It feels like it was built for one of these two scenarios:

* Additional Signed Data: When you can derive some information from the chain, and validate + encode it within the signature without needing to waste extra transaction length
* Normal Signed Extension: Which supports litterally adding extra bytes to the end of a transaction, which can be used for validation
The first being an optimization of sorts. is this accurate?
I guess you would want any additional data to be part of the signature no matter what so people can't replay your transaction with different data. In this case, additional_signed is not used

@kianenigma kianenigma self-assigned this Oct 31, 2019
@JoshOrndorff JoshOrndorff added the new recipe 🍳 Request to add a new recipe label Feb 16, 2020
@kianenigma
Copy link
Contributor

I will un assign for now. But still something that I am keen on.

@kianenigma kianenigma removed their assignment Mar 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new recipe 🍳 Request to add a new recipe
Projects
None yet
Development

No branches or pull requests

2 participants