Neo: Create class for PublicKey and Signature

[igormcoelho]

Not all of us are superhumans like Erik, so I propose to create simple classes PublicKey and Signature, for the rest of us, poor human beings :joy:

Really, I still have many difficulties in understanding the usage of ECPoint, ECCurve, ECField, etc, just to handle a simple publickey. I often forget too which is the correct size of a signature for Neo secp256r1 (64 bytes, right?).
I think that, in the end, these classes are useful and necessary to represent the basic concepts of PublicKey and Signature on Neo. Signature is just a 64-bytearray today (because we are using secp256r1), but who knows tomorrow? Same for PublicKey, it's hard for me to simply handle it as a bytearray in compressed (33-bytes) or uncompressed format (which I don't know the size now...)

I think that this simplifies many things, and makes it much easier to handle this two fundamental concepts during the whole project.

[igormcoelho]

This will already help on some doubts I have now, during the implementation of Scoped Witnesses too (that's why I'm already starting to implement a PR, before further discussions, sorry for that, but I need it :joy:).
If someone else wants to do it, very quickly, feel free to open another PR and I'll close mine (or just help me there..). My intention is to use in next days, if possible.

[shargon]

In which case are you confused? I am not very fan about create one class with only one field.

[igormcoelho]

The point is that ECPoint is not a public key... and byte[] is not a signature. We are missing the semantics. There are many advantages in having specific classes in this case, such as:

• corretness of serialization. it won't be possible to exist signatures with less or more than 64 bytes. Same for ECPoint... we don't even have a standard for serializing public keys and signatures on Neo, and it's important to have one, even for SDK devpack (we are supposed to allow receiving those as parameters, on NEP3 ABI, and we are not doing that, yet)
• correctness of comparison. Comparing bytearrays can be tricky sometimes... a simple Equals between Signatures or Pubkeys will guarantee that its correct. I don't even know how to properly compare two ECPoints
• much easier to understand. If we pass Signature and PublicKey to other methods, everybody will be able to directly understand its meaning. When you pass an ECPoint, it doesn't mean it's a publickey, because it depends on which curve are you talking about. Neo strongly depends on the concept of public-key cryptography, and it is based on secp256r1, so we _deserve_ to have classes specifically for that.

When we start trying to use Schorr signatures, or anything else, all of these can be embedded in existing classes for PublicKey and Signature, and at that time, a strict serialization format will be very necessary to differentiate between existing crytography technologies on Neo.

[vncoelho]

I agree with Igor, I think that it will become more readable and flexible.
I prefer to split and create a simple class or, at least, a struct. But I do not know the best design for C#.

[lock9]

I think this is a good idea, but in any case, could you create a class diagram to try to show us how these new classes would work?

[shargon]

If is more readable, Is good to me

[lock9]

I counted 4 votes, so I'm moving this to design.

[igormcoelho]

Agree to do this, but like Erik said, this is a major refactor. I would prefer to do this when we have Schnorr sigs proposal ready.

[lock9]

@igormcoelho where did he say that this is a major refactor?
Isn't this just a cosmetic refactor?