You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 8, 2022. It is now read-only.
And given that we may use a different signature algorithm in the future, it may be wise to use a serialization mechanism that can detect the signature algorithm. A simple way of doing this is: Instead of using Vec as type for the witness, we use an enum that has SR25519 as one arm with Vec as underlying type, and we just support adding more in the future. Scalecodec can take care of the serialization.
PS: Whether we're gonna remove the witness from inputs is a different discussion.
The text was updated successfully, but these errors were encountered:
Either this or spare ourselves an extra byte by allocating a new Destination enum arm to new signature schemes. E.g. rename Destination::Pubkey to Destination::PubkeySchnorr, eventually add Destination::PubkeyBLS, etc. Signatures inside scripts already have sig type tags as proposed here (at expense of a 1-byte overhead).
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Looking at this code from
utxo/lib.src
:And given that we may use a different signature algorithm in the future, it may be wise to use a serialization mechanism that can detect the signature algorithm. A simple way of doing this is: Instead of using Vec as type for the witness, we use an enum that has SR25519 as one arm with Vec as underlying type, and we just support adding more in the future. Scalecodec can take care of the serialization.
PS: Whether we're gonna remove the witness from inputs is a different discussion.
The text was updated successfully, but these errors were encountered: