Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Several ergonomic improvements #27

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

thomaseizinger
Copy link

@thomaseizinger thomaseizinger commented May 18, 2021

Draft until dalek-cryptography/curve25519-dalek#353 is accepted.

Additionally, the changes to private/publickey are controversal and should probably go somewhere else and/or be delayed.

@thomaseizinger thomaseizinger force-pushed the remove-private-public-key-indirection branch 5 times, most recently from 6ca74bf to 691b9c4 Compare May 19, 2021 04:31
Not sure why we would need this and it causes problems ...
Functions that allocate should start with `to_`. `as_` is used for
cheap conversions.
To minimise breaking changes, we introduce extension traits that
provide most of the old functionality that was defined on the
wrapper types.

Fixes #13.
@thomaseizinger thomaseizinger marked this pull request as ready for review May 19, 2021 04:36
@thomaseizinger thomaseizinger force-pushed the remove-private-public-key-indirection branch from 9868b59 to fee1f70 Compare May 19, 2021 04:36
Copy link

@luckysori luckysori left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice solution with the extension trait! I never consider that one.

@@ -191,8 +192,8 @@ impl Address {
Address {
network,
addr_type: AddressType::Integrated(payment_id),
public_spend,
public_view,
public_spend: public_spend.compress(),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ As a general question, why should we store compressed points? I would assume that one could wait until serialisation.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, EdwardsPoints don't implement Hash so we would have to find a solution around that. Compressing is not cheap but I guess doing it inside Hash might be fine?

Copy link

@luckysori luckysori May 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, you have to compress before you hash.

On principle, I would delay compressing until it's strictly necessary. The thing about CompressedEdwardsY is that it's no different to 32 bytes, so it can hold data that doesn't actually map to an EdwardsPoint (see decompress).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think moving the compressing to a manual implementation of Hash is probably the better idea.

@thomaseizinger
Copy link
Author

Nice solution with the extension trait! I never consider that one.

Thank you. It is good if you want to keep the type hierarchy flat. In our case, both Scalar and EdwardsPoint provide enough guarantees already so we don't need to do any additional data hiding, just more functionality on top of it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants