[Nxt] API of Nxt

[marcus03]

Is the broadcastTransaction API call functional?

I've implemented the client-side signing. My transaction verifies successfull against my Curve code, and it is accepted by NRS:

Code:

[2014-02-22 21:03:50.839] DEBUG: Broadcasted new transaction 5198035352813641840

However, the transaction never shows up in my client or in BC Explorer online.

[Come-from-Beyond]

Is the broadcastTransaction API call functional?

I've implemented the client-side signing. My transaction verifies successfull against my Curve code, and it is accepted by NRS:

Code:

[2014-02-22 21:03:50.839] DEBUG: Broadcasted new transaction 5198035352813641840

However, the transaction never shows up in my client or in BC Explorer online.

What r the bytes?

[marcus03]

Is the broadcastTransaction API call functional?

I've implemented the client-side signing. My transaction verifies successfull against my Curve code, and it is accepted by NRS:

Code:

[2014-02-22 21:03:50.839] DEBUG: Broadcasted new transaction 5198035352813641840

However, the transaction never shows up in my client or in BC Explorer online.

What r the bytes?

Found the problem. The signature bytes were all zero. It now works and I just sent my first client signed transaction. :-)

[marcus03]

Can you point me to the transaction format for the asset exchange transactions (issueAsset, transferAsset, placeAskOrder, placeBidOrder, cancelAskOrder and cancelBidOrder)?

EDIT: Also, with my own Curve implementation, how do I get the account number for a secret, so that I don't have to use "getAccountId&secretPhrase=..." any longer? Is it an operation on the account's publicKey?

EDIT2: found the answer to my 2nd question. PUBLIC KEY -> SHA256 -> (TAKE LOWER 8 BYTES) -> 64bit Account ID

Still need the asset exchange transaction formats. :-)

EDIT3:

Decompiled the Java code and I got issueAsset to work.

transferAsset transaction in the testnet does not show up in the network. Here's an example:

Asset transfer - From Sender: 13266890203335482459 Recipient: 100000 Asset: 18018524522923576964 Quantity: 2 Fee: 1 Deadline: 1440

Bytes:
020134467800A0055AE68D12CEC8065BED3B2502EDBF41D6FE0C05CD106C8607C637F94FB69E433 DA0860100000000000000000001000000000000000000000053CE6520A8C3B1DD03640106564166 662BD514C1B2B421E3378A56BE9C11BF0DE73E819021C7EDBDA6D391354ECB44F166D90E5914484 3B63BEBA4D288D25C2B844E865D96A80EFA02000000

[roslinpl]

Is the broadcastTransaction API call functional?

I've implemented the client-side signing. My transaction verifies successfull against my Curve code, and it is accepted by NRS:

Code:

[2014-02-22 21:03:50.839] DEBUG: Broadcasted new transaction 5198035352813641840

However, the transaction never shows up in my client or in BC Explorer online.

What r the bytes?

Found the problem. The signature bytes were all zero. It now works and I just sent my first client signed transaction. :-)

solved ! Great!

[Come-from-Beyond]

Bytes:
020134467800A0055AE68D12CEC8065BED3B2502EDBF41D6FE0C05CD106C8607C637F94FB69E433 DA0860100000000000000000001000000000000000000000053CE6520A8C3B1DD03640106564166 662BD514C1B2B421E3378A56BE9C11BF0DE73E819021C7EDBDA6D391354ECB44F166D90E5914484 3B63BEBA4D288D25C2B844E865D96A80EFA02000000

Maybe "Not enough funds" error? What debuging shows?

[marcus03]

Bytes:
020134467800A0055AE68D12CEC8065BED3B2502EDBF41D6FE0C05CD106C8607C637F94FB69E433 DA0860100000000000000000001000000000000000000000053CE6520A8C3B1DD03640106564166 662BD514C1B2B421E3378A56BE9C11BF0DE73E819021C7EDBDA6D391354ECB44F166D90E5914484 3B63BEBA4D288D25C2B844E865D96A80EFA02000000

Maybe "Not enough funds" error? What debuging shows?

NRS returns a transaction ID, so it's not "Not enough funds".

I can only run this in testnet, so I don't see the debugging output...

[Come-from-Beyond]

NRS returns a transaction ID, so it's not "Not enough funds".

I can only run this in testnet, so I don't see the debugging output...

NRS would return id in any case. Well, let's wait for the update and check again.

[marcus03]

NRS returns a transaction ID, so it's not "Not enough funds".

I can only run this in testnet, so I don't see the debugging output...

NRS would return id in any case. Well, let's wait for the update and check again.

Got it to work.

The assetID 18018524522923576964 maps to these bytes in the transaction: 844e865d96a80efa

I had to typecast the uInt64 asset ID to int64 to get this hex representation.

[marcus03]

Bug in 0.8.0e:

http://127.0.0.1:7876/nxt?requestType=getPeer&peer=node45.nxtbase.com

returns:

{"platform":"22k.io","application":"NRS","weight":78879,"hallmark":nxt.peer.Hallmark@1e85e47e,"state":1,"announcedAddress":"node45.nxtbase.com","downloadedVolume":3084,"version":"0.7.6","uploadedVolume":7320}

This is malformatted json, due to the hallmark value.

Edit: Also in 0.8.1.e.

[Come-from-Beyond]

Bug in 0.8.0e:

http://127.0.0.1:7876/nxt?requestType=getPeer&peer=node45.nxtbase.com

returns:

{"platform":"22k.io","application":"NRS","weight":78879,"hallmark":nxt.peer.Hallmark@1e85e47e,"state":1,"announcedAddress":"node45.nxtbase.com","downloadedVolume":3084,"version":"0.7.6","uploadedVolume":7320}

This is malformatted json, due to the hallmark value.

I'm not sure if Jean-Luc reads this thread. U should point him to this bug, coz I don't work on experimental builds.

[abuelau]

Is there a limit on how many accounts can forge on the same NRS using the http://localhost:7876/nxt?requestType=START_OR_STOP&secretPhrase=SECRET?

[marcus03]

API, Latency and batch mode:

I've been rewriting my client to do client-side signing and connect to a random public node and I am now running into latency problems.

E.g. for showing a detailed list of peers I need to call getPeers and the cycle over all returned peers and call getPeer&peer=PEERNAME.

For long running public nodes like nodeX1.nxtbase.com getPeers returns 1000, 2000 or more peers and my client has to do that many back and fourth requests. This was no problem when running NRS locally, but it is a problem with remote hosts.

This might not be a a huge problem for peers (I could simply drop the peer list in my client), but it will be a problem for getting account transactions, asset trades and asset orders. This will simply not scale.

Proposal:

Offer batch mode API calls, e.g.:

getPeersDetail returning

{"peers":
  [{"shareAddress":true,"platform":"PC","application":"NRS","weight":0,"state":2,"announcedAddress":"199.217.117.152","downloadedVolume":379,"version":"0.7.3","uploadedVolume":12647},
  ...
  ]
}

For peers it might make sense to add a filter option like "state=1" to only get the connected peers.

Similiar batch calls would make sense for getting account transactions, orders and trades, probably together with startIndex/endIndex or startDate/endDate where applicable.

[opticalcarrier]

API, Latency and batch mode:

I've been rewriting my client to do client-side signing and connect to a random public node and I am now running into latency problems.

E.g. for showing a detailed list of peers I need to call getPeers and the cycle over all returned peers and call getPeer&peer=PEERNAME.

For long running public nodes like nodeX1.nxtbase.com getPeers returns 1000, 2000 or more peers and my client has to do that many back and fourth requests. This was no problem when running NRS locally, but it is a problem with remote hosts.

This might not be a a huge problem for peers (I could simply drop the peer list in my client), but it will be a problem for getting account transactions, asset trades and asset orders. This will simply not scale.

Proposal:

Offer batch mode API calls, e.g.:

getPeersDetail returning

{"peers":
  [{"shareAddress":true,"platform":"PC","application":"NRS","weight":0,"state":2,"announcedAddress":"199.217.117.152","downloadedVolume":379,"version":"0.7.3","uploadedVolume":12647},
  ...
  ]
}

For peers it might make sense to add a filter option like "state=1" to only get the connected peers.

Similiar batch calls would make sense for getting account transactions, orders and trades, probably together with startIndex/endIndex or startDate/endDate where applicable.

yes, I concur with the &state=1 modification to the getPeers API.  IF only to support light-clients.

[marcus03]

yes, I concur with the &state=1 modification to the getPeers API.  IF only to support light-clients.

Well, peers are nice to look at, but not vital. Transactions, orders and trades are.

Just like a new user, I've just added an existing account in my client and retrieving the ~6000 acount transactions for the first time took like 20 minutes... This is not going to fly...

I've tried this with a nextbase node running 0.7.6 and my own remote node on 0.8.2e with roughly the same result. Getting these transactions from a local node takes around 14 seconds.  

[wesleyh]

yes, I concur with the &state=1 modification to the getPeers API.  IF only to support light-clients.

Well, peers are nice to look at, but not vital. Transactions, orders and trades are.

Just like a new user, I've just added an existing account in my client and retrieving the ~6000 acount transactions for the first time took like 20 minutes... This is not going to fly...

I've tried this with a nextbase node running 0.7.6 and my own remote node on 0.8.2e with roughly the same result. Getting these transactions from a local node takes around 14 seconds.  

Load on demand, you need not get all 6000 transactions at once. Only if the user scrolls to the end of the table, you can fetch new ones. So limit to 100 transactions at start or something. You can also cache transactions with more than > 1440 ?  confirmations.

[btc2nxt]

bug reports

1. assetid= 9458407878065988264 AuroraCoin ( other tester issued this asset)
quantity=90, price=100 (other tester placed this ask order)

2. i place a bid order
quantity=120, price=100

3. left quantity is ok in bid order
quantity=30, price=100

4. cancel this bid order
quantity=30, price=100

5. but ask order show like this
quantity=30, price=100
i think should show noting


btw, i have trouble getting my balance detail, i don't know how many assets matched from api.
if api can return matched quantity and price, get balance detail may be simple.

there are subtype values in asset  api
type =2
subtype=1 issue asset
             2 ask order
             3 bid order
             4 cancel ask order
             5 cancel bid order

[marcus03]

yes, I concur with the &state=1 modification to the getPeers API.  IF only to support light-clients.

Well, peers are nice to look at, but not vital. Transactions, orders and trades are.

Just like a new user, I've just added an existing account in my client and retrieving the ~6000 acount transactions for the first time took like 20 minutes... This is not going to fly...

I've tried this with a nextbase node running 0.7.6 and my own remote node on 0.8.2e with roughly the same result. Getting these transactions from a local node takes around 14 seconds.  

Load on demand, you need not get all 6000 transactions at once. Only if the user scrolls to the end of the table, you can fetch new ones. So limit to 100 transactions at start or something. You can also cache transactions with more than > 1440 ?  confirmations.

I am caching existing transactions with more than 720 confirmations. The problem I described is only with getting transactions for the first time.

The solution you describe is more of a workaround. I would need to define how many transactions to fetch for the user and then use

getAccountTransactionIds&account=<accountid>&timestamp=<timestamp>

with varying timestamps to get roughly as many transactionIDs as I want and then fetch the details for these IDs. There is no order defined in the list of transactionsIDs returned with getAccountTransactionIds, so I can't just fetch the details for the first X transactions.

The timestamp parameter is more for getting new transactions since the last fetch.

Again, this is a workaround and I suggest to look at how all the exchanges implemented their APIs. They make no separation between getting IDs first and then fetching trade/order details, but you simply specify index values and/or timestamp values and receive all details in one batch reply with one call. This does scale nicely.

[marcus03]

Maybe I am making a false assumption here.

Is there an order defined on the transactionsIDs returned by

getAccountTransactionIds&account=<accountid>&timestamp=<timestamp>

?

If so, always, even with <timestamp>=0?

[btc2nxt]

http://holms.cloudapp.net:6874/nxt?requestType=getAccountTransactionIds&account=1562462127635514638&timestamp=0

i always do with timestamp=0