How is param `ttl` treated in different tx-types?

Protocol Features & Updates
1

Almost all transaction types require the param ttl. Is this param always treated the same way?

In the documentation of state channels the ttl has the following meaning:

  • minimum block height to include the channel_create_tx

I always thought it means the maximum block height to include a certain transaction?! I am a bit confused about that.

When putting 9782 as ttl-param I would expect the signed tx to be valid until block 9782 is reached. If it isn’t included in this or any previous block I would expect the signed tx to be invalid.

2

there is generally some documentation missing regarding all the params required in all the tx types. at least from my personal perspective.

would be nice to have them a bitter better described in a central place. this site is describing serialization formats but it is the best overview I generally found regarding this:

3

Hi @marco.chain,
It looks like the documentation is wrong yes, I will fix it.

Regarding a single point describing common transaction fields (ttl, fee, nonce…) - I agree it would be a nice thing to have indeed. I couldn’t find the fee computation and gas conversion anywhere in the docs. In order for us not forgetting it, this is tracked in Pivotal as Describe in protocol common tx fields.

1 Like
4

Fee computation and gas conversion is described here:

But yeah, it’s generally a bit tricky to put all pieces together to get a knowledge about the parameters of all Tx types.

5

I see it mentions TTL as well but doesn’t really describe it.

The PR with the fix to the min/max inconsistency:

6

Best would be to have the description in the swagger definition for every attribute of each Tx Object, not only a description for the API params.

That would make life easier for me :blush:

7

Again I am struggling with some parameters. IMO the documentation on this side really needs to be updated and provided with more information or concrete examples.

I am currently adding oracle support for the java sdk and try to find information regarding the query-format and the response-format that needs to be passed for the OracleRegisterTx.

Edit:

  • I found out that when setting ABI version to 0 there is no validation regarding the query/response spec performed. what params are allowed when setting ABI to version 1?
8

OK, now this has nothing to do with channels or ttl.

The type specification of the oracles queries and responses is used by Smart Contracts in order for them to be able to produces queries on one hand and on the other - to be able to use them in a safe manner. In order to to this, both are Sophia types. An example for a channel_register_tx registering an oracle that receives queries consisting of a single string and returning responses consisting of a single string would be:

{  
    "block_hash":"none",
    "block_height":-1,
    "hash":"th_TSiJAQPkA2MUHQ4ZGffR494TijmGZdJ9sZ7WxwRNktTeaeRcs",
    "signatures":[  
        "sg_GAtPX84RE7UPqTjzTupeFZVjBytauF7aPVwn2ybso5MzXTu9z3w4SV6QA1WYA9YGmpyWhhqQk6H3zgifw3wWSWhh3BpC2"
    ],
    "tx":{  
        "abi_version":1,
        "account_id":"ak_2XNq9oKtThxKLNFGWTaxmLBZPgP7ECEGxL3zK7dTSFh6RyRvaG",
        "fee":50000000000000,
        "nonce":1,
        "oracle_ttl":{  
            "type":"delta",
            "value":20
        },
        "query_fee":3,
        "query_format":"u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000 u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0001",
        "response_format":"u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000 u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0000u0001",
        "type":"OracleRegisterTx",
        "version":1
    }
}

Note that since you’ve noted already: both the old no-validation abi:0 and the shiny new abi:1 that applies validation can be used, thus the formats are not encoded in the JSON representation.