[Nxt] API of Nxt

[GCInc.]

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.

[1714164996]

1714164996

[1714164996]

1714164996

[Come-from-Beyond]

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

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]

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.

[newcn]

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]

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.

[GCInc.]

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]

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

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]

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

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]

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://bitcointalk.org/index.php?topic=313082.msg3950516#msg3950516

[GCInc.]

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]

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

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]

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://bitcointalk.org/index.php?topic=313082.msg3753193#msg3753193

[GCInc.]

No. I can't edit OP.

Read https://bitcointalk.org/index.php?topic=313082.msg3753193#msg3753193

Sorry, missed that one.

What's the response supposed to be, instant acknowledgement like sendMoney?

[Come-from-Beyond]

No. I can't edit OP.

Read https://bitcointalk.org/index.php?topic=313082.msg3753193#msg3753193

Sorry, missed that one.

What's the response supposed to be, instant acknowledgement like sendMoney?

Yes, with the transaction id.

[GCInc.]

The problem we face with tx's in limbo, is that getTransactionBytes does not recognize the txid we just a minute earlier got from sendMoney.

Code:

{"errorCode":5,"errorDescription":"Unknown transaction"}

Thus we can not rebroadcast. It remains in limbo god knows how long?

Another problem that is not consistent with what we have talked here, is that we can not spend more than unconfirmedbalance. You said that "balance" is the actual balance, however we can not use more than 1M NXT from the following:

Code:

{"balance":902320000,"effectiveBalance":902320000,"unconfirmedBalance":108396200}

[Come-from-Beyond]

The problem we face with tx's in limbo, is that getTransactionBytes does not recognize the txid we just a minute earlier got from sendMoney.

Code:

{"errorCode":5,"errorDescription":"Unknown transaction"}

Thus we can not rebroadcast. It remains in limbo god knows how long?

Another problem that is not consistent with what we have talked here, is that we can not spend more than unconfirmedbalance. You said that "balance" is the actual balance, however we can not use more than 1M NXT from the following:

Code:

{"balance":902320000,"effectiveBalance":902320000,"unconfirmedBalance":108396200}

U r right. Tomorrow I'll release 0.3.20 with fixed issues.

Edit: Right now u can relaunch the client to "reset" unconfirmed balance.