Hi Johan, Philip,
this issue, which more or less everyone seem to agree is, well, marginal and
has simple solutions
This issue has roughly two solutions, neither of which are simple, and
everyone seems to disagree on which one to choose. There seem to be two
camps:
camp A) keytag-conflicts are to be obsoleted and outlawed sooner or
later, which eases the life for validators, which would be able to
immediately tell that matching keytag with unmatching crypto is a bogus
and save some computation
camp B) keytag-conflicts won't be obsoleted as that would be a
backward-incompatible change to the protocol, and it would not only
impose more implementation complexity on solo signers, but require
significant design complexity from multi-signers, including extra
communication channel for only this marginal thing; whereas for the
validators, some reasonable tolerance for keytag-conflicts is very easy
to implement
I would prefer disallowing key tag collisions in the future), but that’s beside
the point.
You are in camp A, which is your main point.
Philip Homburg wrote:
In my opinion this is a quality of implementation issue. We should
not design a multi-signer protocol that has collision even if there is
no document that requires it.
What I see as a "quality of implementation" is something that can be
implemented inside the software and is an invisible piece of complexity
for the user. This is IMHO not the case -- synchronizing keytags across
multi-signers also introduces operational complexity, which can be
somehow helped by automation provided by the software, but is still not
beautiful.
Libor
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
