[Nxt] API of Nxt

[marcus03]

2.) It was said that an account that has no public key in the BC yet (no outgoing transactions) was more prone to a brute force attack. Could anyone explan why? I didn't get it. My idea is that a brute force attack works like this: dictionary words or random input generates a public and private key pair, the latter being the account number. I see no difference in the chances of finding an existing account number when using this procedure depending on if the public key is in the bc or not.  

Search space for unrevealed key is only 2^64.

Always busy, right.    Not enough info for me to understand...

No problem  - maybe someone else can jump in?

[1714105561]

1714105561

[1714105561]

1714105561

[marcus03]

And anothere one:

Account numbers are returned as json strings by the HTTP API, but they are always numbers.

Can I assume they always will be number inside these strings?
Or is it a bug in the API code?

[Come-from-Beyond]

And anothere one:

Account numbers are returned as json strings by the HTTP API, but they are always numbers.

Can I assume they always will be number inside these strings?
Or is it a bug in the API code?

They r always numbers. They r represented as strings coz JS may round them.

[kjannis]

Hi,

I am running a client on a VPS and want to check every x minutes for new transactions.
However I have a feeling it is not downloading the needed data for that account.
How can I make sure my client keeps downloading the data for an account?

Can I force this somehow? Perhaps by using curl every x minutes to a certain url?

Thanks?

[marcus03]

(Copied over from the main thread for reference.)

How to find the account that will forge the next block.

1. Do http://localhost:7874/nxt?requestType=getState to get value of "lastBlock"
2. Do http://localhost:7874/nxt?requestType=getBlock&block=10621696942372068326 (assuming 10621696942372068326 is the value of "lastBlock")
3. Convert "generationSignature" into binary and append public key bytes returned by getAccountPublicKey
4. Calculate SHA256(generationSignature, publicKey)
5. First 8 bytes as unsigned long in little-endian notation is HIT
6. Value of "baseTarget" multiplied by effective balance of the account is STATIC_TARGET
7. Do steps 3-6 for each account and find the one with lowest HIT/STATIC_TARGET ratio, this account will forge next block

We have a new block about every two minutes, so to always show the account that forges the next block, I need to do this calculation over all accounts again and again? Plus, I need always up-to-date effective balances.

I could implement this and it would currently run, but it will simply not scale with further adoption of NXT.

For now, I'll not implement this. (And I don't see a huge benefit in showing the account forgiung the next block anyway.)

[Come-from-Beyond]

I could implement this and it would currently run, but it will simply not scale with further adoption of NXT.

This is made intentionally.

[marcus03]

I could implement this and it would currently run, but it will simply not scale with further adoption of NXT.

This is made intentionally.

Then why did you say that clients could support TF? I see no benefit.

[Come-from-Beyond]

I could implement this and it would currently run, but it will simply not scale with further adoption of NXT.

This is made intentionally.

Then why did you say that clients could support TF? I see no benefit.

It's trivial to find who will forge next block among a million accounts, but impossible to predict who will do it in 1440 blocks.

[marcus03]

I could implement this and it would currently run, but it will simply not scale with further adoption of NXT.

This is made intentionally.

Then why did you say that clients could support TF? I see no benefit.

It's trivial to find who will forge next block among a million accounts, but impossible to predict who will do it in 1440 blocks.

What is the benefit of knowing who will forge the next block? From a client end-user perspective and in general?

[Come-from-Beyond]

What is the benefit of knowing who will forge the next block? From a client end-user perspective and in general?

Users can send transactions directly to the miner. In general this helps to achieve VISA processing volume.

[marcus03]

What is the benefit of knowing who will forge the next block? From a client end-user perspective and in general?

Users can send transactions directly to the miner. In general this helps to achieve VISA processing volume.

There is no mining in NXT... Just kidding... 

Is this supported by the current API? How would I send a transaction to the node that has the account open that will forge the next block?

[Come-from-Beyond]

Is this supported by the current API? How would I send a transaction to the node that has the account open that will forge the next block?

This will be implemented later. ETA is about 6 months.

[marcus03]

It's trivial to find who will forge next block among a million accounts, but impossible to predict who will do it in 1440 blocks.

It's not trivial for clients, since they will not have all account balances and private keys.

IMHO this should be implemented in the core. If it's really trivial, just add the next forging account as a return value to the getBlock function.

[joefox]

Search space for unrevealed key is only 2^64.

Always busy, right.    Not enough info for me to understand...

No problem  - maybe someone else can jump in?

The account number is only a piece of the public key (the first 64 bytes, I think?), so the mapping of passphrases to account numbers is not one-to-one.  As soon as you find the first possible combination that unlocks that account, it's yours.  Anyone else who finds another possible passphrase after that point will be denied access to that account number, since it's already "taken".

[Come-from-Beyond]

It's not trivial for clients, since they will not have all account balances and private keys.

IMHO this should be implemented in the core. If it's really trivial, just add the next forging account as a return value to the getBlock function.

Ok.

[marcus03]

I would need a call to get the Alias ID for an alias, so I can then call getAlias with the ID.

I will need it in the blockchain explorer part of my client when cleaning up the transactions from orphaned blocks.

[wesleyh]

what is type, subtype of transaction? possible values and explanations of them? thx

[marcus03]

what is type, subtype of transaction? possible values and explanations of them? thx

Look at the output of getConstants or look into source code.

[marcus03]

Which balance is show in the NRS client? "Unconfirmed balance"?

[Come-from-Beyond]

Which balance is show in the NRS client? "Unconfirmed balance"?

Yes