[Nxt] API of Nxt - page 17. | Bitcointalksearch.org

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 15, 2013, 08:39:23 AM

Quote from: Come-from-Beyond on December 15, 2013, 08:33:40 AM

It's safe to resend an expired payment only if (A) ur local time is correct and (B) u see the longest branch. It's easy to make sure about (A) but not (B). So u'd better stick to broadcastTransaction approach.

Damn, we have risked quite a bit.

Could you add broadcastTransaction specs to the OP of this thread please?

No. I can't edit OP.

Read https://bitcointalksearch.org/topic/m.3753193

GCInc.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 15, 2013, 08:33:40 AM

It's safe to resend an expired payment only if (A) ur local time is correct and (B) u see the longest branch. It's easy to make sure about (A) but not (B). So u'd better stick to broadcastTransaction approach.

Damn, we have risked quite a bit.

Could you add broadcastTransaction specs to the OP of this thread please?

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 15, 2013, 07:53:10 AM

Quote from: Come-from-Beyond on December 15, 2013, 07:48:40 AM

This leads to ur situation when even after transaction expiration the unconfirmed balance is not adjusted back.

Ok, so after expiration it is safe for us to resend expired non-peer recognized transaction?

Let's just ignore the unconfirmed balance then. Out of interest, when will the unconfirmed balance be adjusted back?

It's safe to resend an expired payment only if (A) ur local time is correct and (B) u see the longest branch. It's easy to make sure about (A) but not (B). So u'd better stick to broadcastTransaction approach.

Unconfirmed balance is adjusted back when a transaction expires and it's in unconfirmed transactions list.

GCInc.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 15, 2013, 07:48:40 AM

This leads to ur situation when even after transaction expiration the unconfirmed balance is not adjusted back.

Ok, so after expiration it is safe for us to resend expired non-peer recognized transaction?

Let's just ignore the unconfirmed balance then. Out of interest, when will the unconfirmed balance be adjusted back?

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 15, 2013, 07:44:23 AM

Quote from: Come-from-Beyond on December 15, 2013, 07:28:19 AM

There is possibility that ur balance will become == unconfirmedBalance. Transactions in limbo can be confirmed at any moment before expiration.

That's a problem. Transactions were sent long ago with a deadline of 60 minutes. Yet they seem to be reflected in the unconfirmedbalance.

In addition, those transactions in limbo cannot be seen ANYWHERE? Very problematic when trying to process payments and ensure what will need to be repeat submitted and when.

1. Transaction is sent
2. Unconfirmed balance is adjusted
3. Transaction is not received from peers, so it doesn't appear in unconfirmed transactions

This leads to ur situation when even after transaction expiration the unconfirmed balance is not adjusted back.

There is an easy way to make sure that u'll never send one payment twice - https://bitcointalksearch.org/topic/m.3950516

GCInc.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 15, 2013, 07:28:19 AM

There is possibility that ur balance will become == unconfirmedBalance. Transactions in limbo can be confirmed at any moment before expiration.

That's a problem. Transactions were sent long ago with a deadline of 60 minutes. Yet they seem to be reflected in the unconfirmedbalance.

In addition, those transactions in limbo cannot be seen ANYWHERE? Very problematic when trying to process payments and ensure what will need to be repeat submitted and when.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 15, 2013, 07:12:40 AM

Quote from: Come-from-Beyond on December 15, 2013, 07:03:43 AM

This can happen if u send a transaction but don't get it back from peers. Unconfirmed balance is for web interface only. API shouldn't work with it.

Does it have any significance? Is there a possibility our balance can without further transactions become that which the unconfirmed amount shows? What happens with the transactions in limbo, can they go through or when are they purged?

There is possibility that ur balance will become == unconfirmedBalance. Transactions in limbo can be confirmed at any moment before expiration.

GCInc.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 15, 2013, 07:03:43 AM

This can happen if u send a transaction but don't get it back from peers. Unconfirmed balance is for web interface only. API shouldn't work with it.

Does it have any significance? Is there a possibility our balance can without further transactions become that which the unconfirmed amount shows? What happens with the transactions in limbo, can they go through or when are they purged?

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 15, 2013, 06:09:48 AM

Could you clarify when unconfirmedBalance is cleared? Deadline set to 60 mins which passed, no unconfirmed transactions, yet getBalance gives:

Code:

{"balance":1104325300,"effectiveBalance":1104325300,"unconfirmedBalance":892757800}

This can happen if u send a transaction but don't get it back from peers. Unconfirmed balance is for web interface only. API shouldn't work with it.

GCInc.

hero member

Activity: 566

Merit: 500

Could you clarify when unconfirmedBalance is cleared? Deadline set to 60 mins which passed, no unconfirmed transactions, yet getBalance gives:

Code:

{"balance":1104325300,"effectiveBalance":1104325300,"unconfirmedBalance":892757800}

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: newcn on December 14, 2013, 04:51:30 AM

in the web interface, there a line which says "You can generate the next block in x day xx hour...."
is there a request can get that info?

Not in API, only in interface HTTP requests.

newcn

full member

Activity: 143

Merit: 100

in the web interface, there a line which says "You can generate the next block in x day xx hour...."
is there a request can get that info?

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 13, 2013, 12:43:16 PM

Thanks - would you think the following more practical logic is sufficient to get reasonable payout success rate and protect us from accidentally paying customers twice;

1. sendMoney with 1-hour deadline
2. getTransaction immediately
3. If txid is known, mark transaction processed
4. after deadline is over, or at any point inbetween, go to part 2

We could run the above as often as necessary, to poll the network for arrived transactions and mark them processed. In the rare case of blockchain reorg, we trust the customer will complain

Looks fine.

GCInc.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 13, 2013, 10:58:28 AM

I would go such a way:
1. sendMoney with 22-day deadline (deadline = 32767 mins)
2. getTransaction in 1 min
3. broadcastTransaction if no transaction found and go to step 2
4. After the transaction is confirmed, check again in 720 blocks and do broadcastTransaction if it disappeared

Thanks - would you think the following more practical logic is sufficient to get reasonable payout success rate and protect us from accidentally paying customers twice;

1. sendMoney with 1-hour deadline
2. getTransaction immediately
3. If txid is known, mark transaction processed
4. after deadline is over, or at any point inbetween, go to part 2

We could run the above as often as necessary, to poll the network for arrived transactions and mark them processed. In the rare case of blockchain reorg, we trust the customer will complain

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 13, 2013, 10:47:41 AM

Quote from: Come-from-Beyond on December 13, 2013, 10:15:12 AM

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

Does "Unknown transaction" response then mean anything, if the same unknown transaction can become known after any arbitrary length of time within the deadline?

The problem is we receive txid from sendMoney, and when submitting this txid to getTransaction, we get Unknown transaction. This would fine and dandy if it had any usefulness - but this data has no relevance. We would get the same response with a txid pulled from thin air.

So getTransaction can be used to just verify what transactions were positively valid. Those tx which his majesty getTransaction won't acknowledge immediately we need to wait until deadline, then wait for 10 further blocks, then check to verify some of them have gone through, then resubmit the remaining poor rejected ones. Doable yes, not easily.

Well, this is a decentralized system, Bitcoin has similar issue, Bitcoin network is just larger/more stable.

I would go such a way:
1. sendMoney with 22-day deadline (deadline = 32767 mins)
2. getTransaction in 1 min
3. broadcastTransaction if no transaction found and go to step 2
4. After the transaction is confirmed, check again in 720 blocks and do broadcastTransaction if it disappeared

Large deadline protects ur customer from blockchain reorgs.

GCInc.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 13, 2013, 10:15:12 AM

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

Does "Unknown transaction" response then mean anything, if the same unknown transaction can become known after any arbitrary length of time within the deadline?

The problem is we receive txid from sendMoney, and when submitting this txid to getTransaction, we get Unknown transaction. This would fine and dandy if it had any usefulness - but this data has no relevance. We would get the same response with a txid pulled from thin air.

So getTransaction can be used to just verify what transactions were positively valid. Those tx which his majesty getTransaction won't acknowledge immediately we need to wait until deadline, then wait for 10 further blocks, then check to verify some of them have gone through, then resubmit the remaining poor rejected ones. Doable yes, not easily.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 13, 2013, 10:09:38 AM

Quote from: Come-from-Beyond on December 13, 2013, 09:49:45 AM

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 Huh

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.

Quote

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

GCInc.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 13, 2013, 09:49:45 AM

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 Huh

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: GCInc. on December 13, 2013, 09:30:13 AM

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

Quote from: GCInc. on December 13, 2013, 09:30:13 AM

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.

hero member

Activity: 566

Merit: 500

Quote from: Come-from-Beyond on December 13, 2013, 09:17:54 AM

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?

Topic: [Nxt] API of Nxt - page 17. (Read 37320 times)