[API] Transaction IDs/unconfirmed transactions?

[monsterer]

get_block will now give you the ID's of all transactions included in the block.

Fantastic! Nice one

[theoretical]

get_block will now give you the ID's of all transactions included in the block.

[bytemaster]

@bytemaster - can you add issue_asset2,reserve_asset2 as well?

I'll merge a pull request.  Should be able to follow the same pattern I did.

[monsterer]

@bytemaster - can you add issue_asset2,reserve_asset2 as well?

[monsterer]

[20:22:21] (bittrex) Richie Lai: "I have added a new method to the witness_api for get_recent_transaction_by_id( TRX_ID )"
[20:22:39] (bittrex) Richie Lai: witness_api means for the daemon itself.. not the wallet right?
[20:53:12] Fabi: right .. that's how I understand it too
 Freitag, 23. Oktober 2015
[02:16:59] (bittrex) Richie Lai: fwiw, if you can add starting_block_height as a param to get_account_history, it would be gold

Yes, having an equivalent to listsinceblock in bitcoin would be awesome.

[xeroc]

[20:22:21] (bittrex) Richie Lai: "I have added a new method to the witness_api for get_recent_transaction_by_id( TRX_ID )"
[20:22:39] (bittrex) Richie Lai: witness_api means for the daemon itself.. not the wallet right?
[20:53:12] Fabi: right .. that's how I understand it too
 Freitag, 23. Oktober 2015
[02:16:59] (bittrex) Richie Lai: fwiw, if you can add starting_block_height as a param to get_account_history, it would be gold

[richiela]

Thanks bytemaster! We need to be able to look up a transaction by TXID as well , is that possible?

Also, can you make sure the TXID gets serialised everywhere the transaction is serialized, i.e. inside blocks, etc?

It is not trivial to add the transaction id to every place the transaction appears.   It is data that can be calculated entirely from the JSON you already have.

We do not maintain a database that maps all transaction ids their transaction (it would get too big).   We only maintain a database of transaction_id to transaction for non-expired transactions in order to prevent them from being processed twice.

I have added a new method to the witness_api for get_recent_transaction_by_id( TRX_ID )

Is there a way to get it from the cli_wallet?  Seems like we should be able to get it all from the same endpoint?

[bytemaster]

Thanks bytemaster! We need to be able to look up a transaction by TXID as well , is that possible?

Also, can you make sure the TXID gets serialised everywhere the transaction is serialized, i.e. inside blocks, etc?

It is not trivial to add the transaction id to every place the transaction appears.   It is data that can be calculated entirely from the JSON you already have.

We do not maintain a database that maps all transaction ids their transaction (it would get too big).   We only maintain a database of transaction_id to transaction for non-expired transactions in order to prevent them from being processed twice.

I have added a new method to the witness_api for get_recent_transaction_by_id( TRX_ID )

[monsterer]

Thanks bytemaster! We need to be able to look up a transaction by TXID as well , is that possible?

Also, can you make sure the TXID gets serialised everywhere the transaction is serialized, i.e. inside blocks, etc?

[bytemaster]

I completely agree.  I am finishing up our implementation right now and if transfer does not give us a unique identifier to present to the end user, there is no way for us to reference the withdrawal.  I've already tried polling for the txid, but that has many edge cases as well.  Is there a more elegant solution here?

thanks,
richie@bittrex

I will add the transaction ID as the return value in a new call.

Latest bitshares includes two new API calls:   transfer2(..) that returns [ TRX_ID, TRX ]  and get_transaction_id( TRX ) that returns TRX_ID

Transfer2 should handle the normal case, but rather than updating all calls that return signed_transaction and breaking everyone, I added a helper call that can convert the values returned by the other calls to a trx id if necessary.

[bytemaster]

I completely agree.  I am finishing up our implementation right now and if transfer does not give us a unique identifier to present to the end user, there is no way for us to reference the withdrawal.  I've already tried polling for the txid, but that has many edge cases as well.  Is there a more elegant solution here?

thanks,
richie@bittrex

I will add the transaction ID as the return value in a new call.

[richiela]

I completely agree.  I am finishing up our implementation right now and if transfer does not give us a unique identifier to present to the end user, there is no way for us to reference the withdrawal.  I've already tried polling for the txid, but that has many edge cases as well.  Is there a more elegant solution here?

thanks,
richie@bittrex

[monsterer]

Any advice? This is kind of critical to metaexchange (and probably a bunch of other transaction processors)...

[monsterer]

Oh dear. What if the socket closes / client crashes / power cut between the time you send the transaction and the time you get your callback?

It's lost forever?

In any case, say I do get a callback at some point in the future, how can I tell that it relates to the transaction I just sent, and not some other transaction?

[xeroc]

In BitShares 2 your transactions gets and id once included into the blockchain. There actually is no "txhash".
The id is of the form 1.11.x
something like this:

Code: [Select]

locked >>> get_object 1.11.1000
get_object 1.11.1000
[{
    "id": "1.11.1000",
    "op": [
      37,{
        "fee": {
          "amount": 0,
          "asset_id": "1.3.0"
        },
        "deposit_to_account": "1.2.11268",
        "balance_to_claim": "1.15.28529",
        "balance_owner_key": "BTS8jcFd3ZNYvW11Sh2uYivWQb17Yd2zuxe7Ee4EDag9gjA9YqSJH",
        "total_claimed": {
          "amount": 1199997594,
          "asset_id": "1.3.0"
        }
      }
    ],
    "result": [
      0,{}
    ],
    "block_num": 6073,
    "trx_in_block": 0,
    "op_in_trx": 8,
    "virtual_op": 32500
  }
]
and there is no way of known the id before it has been included in a block .. thus the callback ..

[monsterer]

The transfer API returns the signed_transaction in JSON form.  Converting it to binary and hashing it will give you a transaction ID.

Any clue on how to do this through the API? When we send transactions in metaexchange, we need the TXID to be available instantly (so we can log the transaction and display to users), because that is how our coin abstraction layer works - every other crypto returns the TXID straight away when you send a transaction.

edit: what I'm after here is an ID which will also appear when we look up a transaction inside a block, or directly with a query - it has to be consistent; there is no point having a TXID hash if that never appears in the data anywhere else, because we need to look it up a bunch of times.

[bytemaster]

What are we supposed to use for a TXID for unconfirmed transaction?

Specifically, the transfer API call doesn't seem to return anything obvious?

The transfer API returns the signed_transaction in JSON form.  Converting it to binary and hashing it will give you a transaction ID.

Alternatively you can use the witness_node API to broadcast the transaction:

         /** this version of broadcast transaction registers a callback method that will be called when the transaction is
          * included into a block.  The callback method includes the transaction id, block number, and transaction number in the
          * block.
          */
         void broadcast_transaction_with_callback( confirmation_callback cb, const signed_transaction& trx);

In this case you will get a callback via websocket when the transaction has been included in a block.  The callback includes the transaction id, block number, and the trx # in the block.

[monsterer]

What are we supposed to use for a TXID for unconfirmed transaction?

Specifically, the transfer API call doesn't seem to return anything obvious?