Author Topic: [API] Transaction IDs/unconfirmed transactions?  (Read 6312 times)

0 Members and 1 Guest are viewing this topic.

Offline monsterer

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

Fantastic! Nice one :)
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline theoretical

get_block will now give you the ID's of all transactions included in the block.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline 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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline monsterer

@bytemaster - can you add issue_asset2,reserve_asset2 as well?
« Last Edit: October 23, 2015, 03:51:39 pm by monsterer »
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline monsterer

Quote
[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.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Quote
[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 ;)

Offline richiela

  • Newbie
  • *
  • Posts: 14
    • View Profile
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?

Offline 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 )
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline 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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline 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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline 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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline richiela

  • Newbie
  • *
  • Posts: 14
    • View Profile
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

Offline monsterer

Any advice? This is kind of critical to metaexchange (and probably a bunch of other transaction processors)...
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline 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?
« Last Edit: October 21, 2015, 08:13:44 am by monsterer »
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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 ..