Why not digest the type as part of the hash? This avoids the problem in the article and keeps the transmission size small.

▲

maxtaco 10 hours ago | parent | next [-]

It should be possible to change the name of the type, and this happens often in practice. But type renames shouldn't break preexisting signatures. In this scheme you are free change the type name, and preexisting signatures still verify with new code -- of course as long as you never change the domain separator, which you never should do. Also you'd need to worry about two different projects reusing the same type name. Lastly, the transmission size in this scheme remains unaffected since the domain separators do not appear in the serialized data. Rather, both sides agree on it via the protocol specification.

	▲	actionfromafar 9 hours ago \| parent [-]
		That’s easily addressed. We just need a global immutable registry of types, their names, an alias list and revocation list. ;-) We can let one be managed by ICANN and the others various competing offerings on ETH.

▲

tennysont 9 hours ago | parent | prev [-]

They use a magic number, rather than a digest derived from the schema[1], but otherwise they do as you suggest. The magic number is given to the signing function (sender side) and the validation function (receiver side) but does not increase the size of the transmitted message.

[1]

I think that's what you mean by digest, but maybe you just mean `type` = `magic number`

	▲	patrakov 2 hours ago \| parent [-]
		The problem here is that a digest derived from the schema would just reintroduce the possibility of confusion of identically encoded but semantically distinct types.