[Design] New API proposals

[jansegre]

I'm creating this issue to discuss the addition of 2 new APIs:

• GET /v1a/validate_address/{address}: validates address an also returns the corresponding output script
  • right now this is useful for mining software to validate addresses (which are commonly used in stratum login) and to help build a block's output script, all without having to implement any Hathor specific parsing and script building
  • prior art: https://developer.bitcoin.org/reference/rpc/validateaddress.html
  • example usage:

    ❯ curl localhost:9080/v1a/validate_address/HNXsVtRUmwDCtpcCJUrH4QiHo9kUKx199A -s | jq
    {
    "valid": true,
    "script": "dqkUr6YAVWv0Ps6bjgSGuqMb1GqCw6+IrA==",
    "address": "HNXsVtRUmwDCtpcCJUrH4QiHo9kUKx199A",
    "type": "p2pkh"
    }

• POST /v1a/create_tx: creates an unsigned, unmined transaction from inputs and outputs (script or address), validating everything (including double spending) except input data and pow
  • right now this is useful for existing external tools that already implement wallet functionality and are built on top of createrawtransaction like RPC methods (came up when discussing integration of qTrade's exchange)
  • prior art: https://developer.bitcoin.org/reference/rpc/createrawtransaction.html
  • example usage:

    ❯ curl localhost:9080/v1a/create_tx -d '{"inputs":[{"tx_id":"000005551d7740fd7d3c0acc50b5677fdd844f1225985aa431e1712af2a2fd89","index":1}],"outputs":[{"address":"HNXsVtRUmwDCtpcCJUrH4QiHo9kUKx199A","value":5600}]}' -s | jq
    {
    "success": true,
    "hex_data": "0001000101000005551d7740fd7d3c0acc50b5677fdd844f1225985aa431e1712af2a2fd89010000000015e000001976a914afa600556bf43ece9b8e0486baa31bd46a82c3af88ac40310c373eed982e5f63d94d0200000000b0e8be665f308f1d48d2201060846203280062b1cccc4e3d657486e90000000071c0d2cafa192b421bb5727c84174c999f9400d3be74331e7feba08a00000000",
    "data": {
    "timestamp": 1600379213,
    "version": 1,
    "weight": 17.047717984205683,
    "parents": [
      "00000000b0e8be665f308f1d48d2201060846203280062b1cccc4e3d657486e9",
      "0000000071c0d2cafa192b421bb5727c84174c999f9400d3be74331e7feba08a"
    ],
    "inputs": [
      {
        "tx_id": "000005551d7740fd7d3c0acc50b5677fdd844f1225985aa431e1712af2a2fd89",
        "index": 1,
        "data": ""
      }
    ],
    "outputs": [
      {
        "value": 5600,
        "token_data": 0,
        "script": "dqkUr6YAVWv0Ps6bjgSGuqMb1GqCw6+IrA=="
      }
    ],
    "tokens": []
    }
    }

[obiyankenobi]

Both look ok to me.

Do you think it's worth making them public (on our nodes)? Or maybe just for people running their own full node? Doesn't seem to be much of a problem. I mean, the APIs don't seem costly to run.

[jansegre]

I think it's fine for them to be public. But honestly I hope we can eventually shut down the public fullnode APIs.

[pedroferreira1]

If the idea of the create token endpoint is to facilitate HTR integration I think it's good but if we feel that any custom token integration would need this API I think it's not so difficult to add support for that. I couldn't think any reasons why a custom token integration would use that (only if some exchange decide to list a custom token, which does not seem reasonable to happen anytime soon).

Anyway, both APIs look good to me.

[msbrogli]

In GET /v1a/validate_address/{address}'s response, we should rename script to p2pkh_script.

Besides that, all good to me.

[jansegre]

In GET /v1a/validate_address/{address}'s response, we should rename script to p2pkh_script.

I prefer script because we may have other address types in the future (actually is multisig address different?) and it doesn't really matter for the user of the script field, which would be to just have the script to use for sending to that address.

But maybe we could have a "type": "p2pkh" field in addition to script. What do you think? @msbrogli

[jansegre]

If the idea of the create token endpoint is to facilitate HTR integration I think it's good but if we feel that any custom token integration would need this API I think it's not so difficult to add support for that. I couldn't think any reasons why a custom token integration would use that (only if some exchange decide to list a custom token, which does not seem reasonable to happen anytime soon).

I don't see any particular use for custom token integrations besides what would already be useful in particular to HTR. Maybe if we introduce custom token specific addresses in the future, than it would be super useful for not having to reimplement that logic. But yeah, facilitating these integrations is not a goal of this API.

[msbrogli]

In GET /v1a/validate_address/{address}'s response, we should rename script to p2pkh_script.

I prefer script because we may have other address types in the future (actually is multisig address different?) and it doesn't really matter for the user of the script field, which would be to just have the script to use for sending to that address.

But maybe we could have a "type": "p2pkh" field in addition to script. What do you think? @msbrogli

A type field seems good to me.

[jansegre]

A type field seems good to me.

I'll add that and I think this is done.