search

discreetlogcontracts / dlcspecs

Specification for Discreet Log Contracts
Creative Commons Attribution 4.0 International
239 stars 36 forks source link

Use no hash oracle attestation #153

Closed Tibo-lg closed 3 years ago

Tibo-lg commented 3 years ago

Update the signature scheme to use @llfourn proposal

Also removed the requirement for NFC standardization of UTF8 as it does not seem strictly necessary since we are not hashing strings anymore. If anybody can think of a reason that we should keep it please comment.

benthecarman commented 3 years ago

Also removed the requirement for NFC standardization of UTF8 as it does not seem strictly necessary since we are not hashing strings anymore. If anybody can think of a reason that we should keep it please comment.

This still is needed for things like the eventid and for enum outcomes. We hash the entire event_tlv when signing the announcement so these need to be standardized.

Tibo-lg commented 3 years ago

This still is needed for things like the eventid and for enum outcomes. We hash the entire event_tlv when signing the announcement so these need to be standardized.

Good point. Though thinking about it a bit more, I'm actually not sure why we are using canonical encoding in the first place. Looking at it more closely, it seems that it is useful when trying to compare or search strings, which is not what we are doing. The only reason we would need it is if the codes would somehow be automatically changed based on implementations if they were not canonical, but AFAICT it is not the case.

So can someone give a good reason for using it in the first place? Then at least I could add it as a rational to the document.

benthecarman commented 3 years ago

So can someone give a good reason for using it in the first place? Then at least I could add it as a rational to the document.

Imo there should at least be one standard so people know how to correctly interpret these bytes to display to the user.

Tibo-lg commented 3 years ago

Imo there should at least be one standard so people know how to correctly interpret these bytes to display to the user.

So that's the job of utf8. From my understanding, what NFC or NFD provide is a guarantee that two strings that "display" the same will have the same encoding, and it seems to be mainly useful for comparing or searching strings. But for our context I can't really figure out what is the benefit.

LLFourn commented 3 years ago

Also removed the requirement for NFC standardization of UTF8 as it does not seem strictly necessary since we are not hashing strings anymore. If anybody can think of a reason that we should keep it please comment.

This still is needed for things like the eventid and for enum outcomes. We hash the entire event_tlv when signing the announcement so these need to be standardized.

Why does this mean it needs to be standardized in the case of event ids and enum outcomes?

Imo there should at least be one standard so people know how to correctly interpret these bytes to display to the user.

They are just strings so why can't they be displayed to the user normalized or not?

benthecarman commented 3 years ago

From my understanding, what NFC or NFD provide is a guarantee that two strings that "display" the same will have the same encoding, and it seems to be mainly useful for comparing or searching strings. But for our context I can't really figure out what is the benefit.

I misunderstood what normalization meant, if it doesn't change the actual serialization then it would be fine to exclude and leave it up to the implementation