Json serialization and Proof of Work

It is more of an Issue than a Bug

I am trying to port Aether to Java, the most relevant stumbling block is the serialization to Json
Yes, it can be done, easly, with Gson BUT the result is not bit for bit the same as Aether serialization.

Being EXACTLY the same is required for the Proof of work to actually be possible.

This is an issue not only for Java but also for any possible change of go serialization to Json.

Any thought ? Something like doing POW to a well defined set of values, instead of the whole message ?

Thanks

Yes, unfortunately we do right now have an implicit dependency on how Go serialises JSON. When I was building this I looked around to find a JSON library that produces a bit-by-bit exact render across many platforms, but there isn’t one. Since we don’t have any capacity to build our own wire format, this is unfortunately an issue for now.

You might be able to create a simple Go program whose only job is to do that translation for you, fed through a CLI, and call that program through a shell within your Java program, and that would give you the serialisation you need. It wouldn’t be super fast, but I don’t think it’d be slow enough to be an issue either.

Eventually, we need to come up with a canonical JSON format syntax for Aether PoW and signaturing to solve exactly this issue.

Why rely on Json, it creates unneeded implementation dependency

Just “sum” the values of some required fields and do POW, signature of the “summed” value.

The whole algo can be shared between the different classes using an abstract parent.

It can be done in Java, I assume go can also do it

Being currently battling the Pow algorithm and thinking how this can be made future proof I would suggest to have a field that declares the variables to be used in the pow calculation

something like:
pow_fields:“nonce,address.location,node_public_key”
Clearly, some more fields, as required

the same can be said for the signature
signature_fields:“pow_fields,…”
Note that the signature fields may/should be different than pow fields

All fields content must be a String, or decimal numbers

Or there may be more “portable” solutions