[Nxt] API of Nxt

[Come-from-Beyond]

API method request: a way to get a list of transactions pending inclusion in blocks (a la bitcoind getmemorypool).

http://localhost:7874/nxt?requestType=getUnconfirmedTransactionIds (in 0.3.18)

[GCInc.]

getting

Code:

{"errorCode":6,"errorDescription":"Not enough funds"}

for small amounts of NXT

while

Code:

{"balance":112049900,"effectiveBalance":112049900,"unconfirmedBalance":-90021000}

What's with that?

[Come-from-Beyond]

getting

Code:

{"errorCode":6,"errorDescription":"Not enough funds"}

for small amounts of NXT

while

Code:

{"balance":112049900,"effectiveBalance":112049900,"unconfirmedBalance":-90021000}

What's with that?

Corrupted blockchain file.

Just restart and check again before redownloading the blockchain.

[GCInc.]

We have many times received a txid for submitted sendMoney transactions that have an invalid receiver account number and eventually do not go thru. Is that right?

[Come-from-Beyond]

We have many times received a txid for submitted sendMoney transactions that have an invalid receiver account number and eventually do not go thru. Is that right?

Could u post an example of such incorrect recipient account number?

[GCInc.]

Could u post an example of such incorrect recipient account number?

Will post one when it comes along again. I may have been mistaken, by coincidence some payments that had a space in the account number, or decimals in the amount are not going through even through the wrong format is parsed.

I suppose the system still gives a txid instantly even when the transaction does not eventually necessarily go through.? For instance we have a transfer of 10337 NXT with txid 7304505050048365739 returned by the API, yet this payment has not materialized in the blockchain explorer.

[Come-from-Beyond]

Could u post an example of such incorrect recipient account number?

Will post one when it comes along again. I may have been mistaken, by coincidence some payments that had a space in the account number, or decimals in the amount are not going through even through the wrong format is parsed.

I suppose the system still gives a txid instantly even when the transaction does not eventually necessarily go through.? For instance we have a transfer of 10337 NXT with txid 7304505050048365739 returned by the API, yet this payment has not materialized in the blockchain explorer.

Just like in Bitcoin if u send a transaction it's not guaranteed that it will be included into a block.

[GCInc.]

Just like in Bitcoin if u send a transaction it's not guaranteed that it will be included into a block.

Ok, but NXT blocks are not nearly full. What would constitute the reasons for not including a payment in the numerous empty blocks that appear before the deadline?

[Come-from-Beyond]

Just like in Bitcoin if u send a transaction it's not guaranteed that it will be included into a block.

Ok, but NXT blocks are not nearly full. What would constitute the reasons for not including a payment in the numerous empty blocks that appear before the deadline?

Network fragmentation. Make sure u use recent version and ur node is marked, this greatly increases chance to push a transaction.

[GCInc.]

Network fragmentation. Make sure u use recent version and ur node is marked, this greatly increases chance to push a transaction.

I think I have marked my node. How to verify this pls?

[Come-from-Beyond]

Network fragmentation. Make sure u use recent version and ur node is marked, this greatly increases chance to push a transaction.

I think I have marked my node. How to verify this pls?

Launch client from other node and check ur node in Active peers. It should have a non-zero weight set.

[GCInc.]

Launch client from other node and check ur node in Active peers. It should have a non-zero weight set.

Right. Not in activepeers, had set up ip and hallmark. But just noticed http://localhost:7874/nxt?requestType=getMyInfo gives

Code:

{"host":"127.0.0.1","address":"127.0.0.1"}

How can I change the host to my static IP address? Thanks

Despite having set the IP, for some reason the node is not showing up in active peers.

More important: About the bogus txid received for sendMoney requests that are not included in blockchain; if we do getTransaction immediately after receiving the bogus txid, can we trust that the tx is not included in the blockchain at all (regardless of the deadline) if we get "Unknown transaction" as a reply?

[Come-from-Beyond]

More important: About the bogus txid received for sendMoney requests that are not included in blockchain; if we do getTransaction immediately after receiving the bogus txid, can we trust that the tx is not included in the blockchain at all (regardless of the deadline) if we get "Unknown transaction" as a reply?

NO.

[Come-from-Beyond]

Despite having set the IP, for some reason the node is not showing up in active peers.

PM me with ur hallmark plz.

[GCInc.]

More important: About the bogus txid received for sendMoney requests that are not included in blockchain; if we do getTransaction immediately after receiving the bogus txid, can we trust that the tx is not included in the blockchain at all (regardless of the deadline) if we get "Unknown transaction" as a reply?

NO.

Ok. So is there a simple way to see quickly what sendMoney requests have gone, or are going through? Do we need to wait until the deadline and then check all the txid in question for at least 1 confirmation?

[Come-from-Beyond]

More important: About the bogus txid received for sendMoney requests that are not included in blockchain; if we do getTransaction immediately after receiving the bogus txid, can we trust that the tx is not included in the blockchain at all (regardless of the deadline) if we get "Unknown transaction" as a reply?

NO.

Ok. So is there a simple way to see quickly what sendMoney requests have gone, or are going through? Do we need to wait until the deadline and then check all the txid in question for at least 1 confirmation?

After sendMoney do getTransaction.

1 confirmation is exactly the same as 0 confirmations.

[GCInc.]

After sendMoney do getTransaction.

Yes that's what I asked a few messages back, but you answered NO  . So we can only trust the tx that give valid output from getTransaction (at least 10 confirmations).

The other half or the problem remains:
What should we do with those tx for which we get valid-looking txid from sendMoney but they are not included in blockchain? They remain pending on our system until we can verify they are not included in blockchain. For how long should we wait before we can issue getTransaction and be sure the response given will be final?

[Come-from-Beyond]

Yes that's what I asked a few messages back, but you answered NO  . So we can only trust the tx that give valid output from getTransaction (at least 10 confirmations).

Oh, perhaps I didn't get one of ur questions...

The other half or the problem remains:
What should we do with those tx for which we get valid-looking txid from sendMoney but they are not included in blockchain? They remain pending on our system until we can verify they are not included in blockchain. For how long should we wait before we can issue getTransaction and be sure the response given will be final?

There is no "final" in cryptocurrencies. In Nxt a transaction must have 720 confirmations, this is the largest possible chain reorg depth.

[GCInc.]

There is no "final" in cryptocurrencies. In Nxt a transaction must have 720 confirmations, this is the largest possible chain reorg depth.

Yes. But For All Practical Purposes there must be a workaround to the serious problem we are facing with rejected transactions;

- we get txid for every sendMoney call we submit (not considering blockchain not up to date etc.)
- about 25% of these valid-looking txid are not valid, ie. the money sent does not reach the blockchain and not the recipient
- when you say we cannot trust getTransaction, we have no way of programmatically knowing which tx is validly forwarded which are not
- the only way to get a hint of the rejects, we have concluded, is to visually observe the NXT client to see which tx are getting through
- the visual method is very cumbersome, AND it is not certain as some tx will be validly forwarded later even if they are not immediately

The above procedure is not feasible for any business mass handling payments. Additionally, just a single payment of, say 1M NXT, erroneously twice to the same recipient because of not receiving coherent transaction acknowledgement, and the business would be in serious trouble 

[Come-from-Beyond]

There is no "final" in cryptocurrencies. In Nxt a transaction must have 720 confirmations, this is the largest possible chain reorg depth.

Yes. But For All Practical Purposes there must be a workaround to the serious problem we are facing with rejected transactions;

- we get txid for every sendMoney call we submit (not considering blockchain not up to date etc.)
- about 25% of these valid-looking txid are not valid, ie. the money sent does not reach the blockchain and not the recipient
- when you say we cannot trust getTransaction, we have no way of programmatically knowing which tx is validly forwarded which are not
- the only way to get a hint of the rejects, we have concluded, is to visually observe the NXT client to see which tx are getting through
- the visual method is very cumbersome, AND it is not certain as some tx will be validly forwarded later even if they are not immediately

The above procedure is not feasible for any business mass handling payments. Additionally, just a single payment of, say 1M NXT, erroneously twice to the same recipient because of not receiving coherent transaction acknowledgement, and the business would be in serious trouble  

U should use deadline. If u don't see a transaction after it expired then wait for 10+ (up to 720) more blocks and resend again. I'll enabled broadcastTransaction in next version, so u will be able to set 24h deadline and keep pushing the same transaction until it's confirmed.

- the only way to get a hint of the rejects, we have concluded, is to visually observe the NXT client to see which tx are getting through

getTransaction returns even unconfirmed transactions. No need to monitor interface.