Trent Nelson
Trent Nelson
It's starting to feel like this needs a full fledged proposal rather than a bunch of adhoc discussions
cc/ @fragosti (sry can't add you as reviewer)
> somewhat related, but is there a good way to do this that's time based to avoid replay attack? that would fit our use case perfectly replay prevention would be...
> timestamp can be added to the message itself. An app that verifies the signature will receive the timestamp along with the signed message (that includes that timestamp) and check...
It sounds like the goal is to fail the transaction if it cannot be guaranteed that an event was emitted. The indexer being able to notice after the fact is...
updated to include * all outstanding review comments * all incompletely specified details * add application domain specifier to preamble * add signer list to preamble * add specification for...
> when a server will generate a message to sign, I imagine it will need to add some volatile data to prevent replay attacks. E.g., a timestamp or a nonce....
updated to impose non-zero requirement on `signers length` and `message length` (already required by the implementation
no complaints in two weeks. who has approval for me?
> > This will need a feature gate right? It will affect replay when we check the cost model there > > #29595 is currently blocked per [feature schedule](https://github.com/solana-labs/solana/wiki/Feature-Gate-Activation-Schedule). But...