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
Currently flags are a special case for allowing appending up to 8 bits directly to an objects serialized data, starting from the final bit used by the objects serialization. At the moment this is written such that the object has to append these bits itself.
Perhaps we should instead make a general method for allowing concatenating the serialization of two objects at the bit boundary.
To do this, we would add a method to CanonicalSerialize for serialized_size_bits (which could even have an auto-impl to just be 8 * serialized_size), and then add a new type that has types A,B templated, and serializes them both, appended to one another at the bit-boundary.
I think such a method could simplify the flag logic, and allow for further space savings in applications that require it. (E.g. for serializing many 257 bit field elements). It may be that the computational overhead makes this more general method never worth it, but I'd be a bit surprised if that was the case. (Since the computational overhead may be dwarfed by the cryptography operations involved)
Currently flags are a special case for allowing appending up to 8 bits directly to an objects serialized data, starting from the final bit used by the objects serialization. At the moment this is written such that the object has to append these bits itself.
Perhaps we should instead make a general method for allowing concatenating the serialization of two objects at the bit boundary.
To do this, we would add a method to
CanonicalSerialize
forserialized_size_bits
(which could even have an auto-impl to just be8 * serialized_size
), and then add a new type that has typesA,B
templated, and serializes them both, appended to one another at the bit-boundary.I think such a method could simplify the flag logic, and allow for further space savings in applications that require it. (E.g. for serializing many 257 bit field elements). It may be that the computational overhead makes this more general method never worth it, but I'd be a bit surprised if that was the case. (Since the computational overhead may be dwarfed by the cryptography operations involved)
Originally posted by @ValarDragon in #160 (comment)
The text was updated successfully, but these errors were encountered: