Update new_from_preimage to use hash for hint

[brianebert]

Core matches the hash of the preimage in order to validate a HashX signature.

Note: this was in 0.6.0 as well. BTW, thank you for this library. I like it a lot.

[bjorn]

Core matches the hash of the preimage in order to validate a HashX signature.

That looks reasonable. Can you help me verify this by linking to some relevant code or documentation?

Note: this was in 0.6.0 as well.

Right, it seems to have been broken since the introduction in 0.3. Also there is no autotest for this (bonus points if you manage to add one! :-)).

BTW, thank you for this library. I like it a lot.

You're welcome! I somehow ended up maintaining this library since the main developer got busy with other things while I needed this to be up-to-date to use it in my project. However, after almost going crazy while working on #17 I wonder a little what the value of this crate actually is now that we have a well-maintained stellar-xdr crate. I'm wondering if it could be slimmed down further, so any feedback regarding what you get out of this library is appreciated!

[brianebert]

Hi! Sorry to ignore your comments. I kind of ran into the test business and ran away. I'll try to come back to this some time and think over your suggestion to create a test. I think I had one in mind but forget what it was.

If you're wondering about the utility of the crate, base doesn't have a substitute, regardless of language. I like your crate because it's pretty comprehensive and pretty specific, as in struct fields are pretty thoroughly typed. It exceeds other libraries in this regard and code that compiles it runs pretty straightaway.

The smallness of your library adds robustness. Stellar classic is also very robust. It goes hand in hand with base.

Thanks again. BE

[bjorn]

I kind of ran into the test business and ran away.

You mean the failing DCO check? That's just checking whether you've signed off your commit. You fix it by amending your commit and including the requested Signed-off-by: ... line. Then we'll see how the tests fare. :-)

It exceeds other libraries in this regard and code that compiles it runs pretty straightaway.

I'm glad to hear you think this library is worth maintaining in its current form. Indeed I think the alternative would be directly using stellar-xdr, but this would be way more error prone (even if you wouldn't be as likely to run into bugs like that one you fixed here, heh).