[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 ..