Allow users to pre-validate their contract hash and json data before submitting

[allenpiscitello]

Users who create an asset should be able to validate that what they are going to create will work, prior to actually creating the asset.

This will allow them to find problems before creating and potentially abandoning an asset.

[stevenroose]

Quoting from the assets decimals document:

Feature Request for the asset registry:

• have an endpoint /validatecontract or something that
  • checks if all fields that we require are present
  • sanity checks values of the contract
  • returns the "canonically formatted" version of the contract or even the contract hash directly to avoid users wrongly hashing the contract

[shesek]

Maybe as a client-side utility instead of as a server-side endpoint? This could perhaps be added to the registration page I created awhile back (but iiuc isn't being used).

We could also add a validate-only server-side endpoint that checks the asset contract is valid, but you probably don't want a remote server to hash the contract for you...

(BTW, canonical formatting and contract hashing is already available in the cli utility. But this isn't open-sourced yet, and I guess people would probably find it easier to use a webpage and/or a server-side endpoint than a CLI.)

[allenpiscitello]

CLI doesn't help here, there are arbitrary rules in the registry that change over time and someone with an outdated version of the CLI will get an incrorrect result.

The proposal is to have an additional server side endpoint.

[shesek]

If it would be a client-side webpage available from the asset registry server, it'll avoid the issue of not being up-to-date while also not trusting the server to do remote hashing for you (which is quite sensitive, the server could change fields or inject additional ones). If we're talking just about validation and not contract hashing, a server-side endpoint could be alright.

[allenpiscitello]

Having the server provide the hash or even validate that the hash is correct would be useful for full verification. Verification of correctness of the user-submitted hash would be sufficient to not require trust (other than trusting it will accept the entry, which is inevitable).

[shesek]

Implemented in 70b40d3, including validation for the json fields and for the contract hash. It also returns the expected contract hash when the provided one is incorrect.

It can be used like so:

$ curl https://assets.blockstream.info/contract/validate -H 'Content-Type: application/json' \
   -d '{"contract_hash":"3909cccd05c852082457c2f5db2bb0a358d81c09f999fc982ad8e87ed714c983", "contract": {"entity":{"domain":"explorer.lightnite.io"},"issuer_pubkey":"02e3ffdac8108831415f8b005480323af57874f1d182598142b09a5b555781c35e","name":"Alisha","precision":0,"ticker":"CAlis","version":0}}'

[allenpiscitello]

This looks good, thanks!

[stevenroose]

Maybe as a client-side utility instead of as a server-side endpoint? This could perhaps be added to the registration page I created awhile back (but iiuc isn't being used).

Another function this could have is to "warn" you or at least notice you when your ticker is already in use or something like that. It's not illegal to create a duplicate ticker, but it could be useful information for the issuer.

Just to give an example of some validation that only the server can do. Even though a client can do similar checks by querying the server for the ticker, of course.