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.
Topic: [Nxt] API of Nxt - page 11. (Read 37336 times)
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.
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.
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".
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.
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.
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?
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.
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?
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.
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.
I could implement this and it would currently run, but it will simply not scale with further adoption of NXT.
This is made intentionally.
(Copied over from the main thread for reference.)
How to find the account that will forge the next block.
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
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.)
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?
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?
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?
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.
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?
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?
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?
1.) There are no transactions that transfer earned fees to an account, right? So, if I would want to calculate the balance for an account, I would need to sum up all transaction from/to this account, plus I would need to look at each block to see if this account is the generator for the block and then add the fees in this block to the account balance. Right?
Right.
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.
I plan to implement TF in my client and I have two questions:
1.) There are no transactions that transfer earned fees to an account, right? So, if I would want to calculate the balance for an account, I would need to sum up all transaction from/to this account, plus I would need to look at each block to see if this account is the generator for the block and then add the fees in this block to the account balance. Right?
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.
Thanks for your help!
Marcus
1.) There are no transactions that transfer earned fees to an account, right? So, if I would want to calculate the balance for an account, I would need to sum up all transaction from/to this account, plus I would need to look at each block to see if this account is the generator for the block and then add the fees in this block to the account balance. Right?
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.
Thanks for your help!
Marcus
hello,
I am thinking about a way to secure my account for the time being. If I generate an account ID outside nxt client(just use sha256/curve25519 to generate account id, not logon to the client), and send my NXTs to this account, is it safer or more dangerous than the ordinary way?
In this case, even the nxt client don't know my privatekey/publickey, it should be safer. However, since the accountid is only 64 bits interger, the probability of collision is much higher than 256 bits publickey. I read from other threads that when a new passphrase is log on, the system will check the publickey to avoid the conincidence of collision. But in my case, I generate the account outside nxt client, there's no corresponding public key exist in the system, what if a person logon later with different passwd but the accountid happen to be the same as mine? does my balance all go to his account?
I am thinking about a way to secure my account for the time being. If I generate an account ID outside nxt client(just use sha256/curve25519 to generate account id, not logon to the client), and send my NXTs to this account, is it safer or more dangerous than the ordinary way?
In this case, even the nxt client don't know my privatekey/publickey, it should be safer. However, since the accountid is only 64 bits interger, the probability of collision is much higher than 256 bits publickey. I read from other threads that when a new passphrase is log on, the system will check the publickey to avoid the conincidence of collision. But in my case, I generate the account outside nxt client, there's no corresponding public key exist in the system, what if a person logon later with different passwd but the accountid happen to be the same as mine? does my balance all go to his account?
Yes, ur balance will go to that account.
hello,
I am thinking about a way to secure my account for the time being. If I generate an account ID outside nxt client(just use sha256/curve25519 to generate account id, not logon to the client), and send my NXTs to this account, is it safer or more dangerous than the ordinary way?
In this case, even the nxt client don't know my privatekey/publickey, it should be safer. However, since the accountid is only 64 bits interger, the probability of collision is much higher than 256 bits publickey. I read from other threads that when a new passphrase is log on, the system will check the publickey to avoid the conincidence of collision. But in my case, I generate the account outside nxt client, there's no corresponding public key exist in the system, what if a person logon later with different passwd but the accountid happen to be the same as mine? does my balance all go to his account?
I am thinking about a way to secure my account for the time being. If I generate an account ID outside nxt client(just use sha256/curve25519 to generate account id, not logon to the client), and send my NXTs to this account, is it safer or more dangerous than the ordinary way?
In this case, even the nxt client don't know my privatekey/publickey, it should be safer. However, since the accountid is only 64 bits interger, the probability of collision is much higher than 256 bits publickey. I read from other threads that when a new passphrase is log on, the system will check the publickey to avoid the conincidence of collision. But in my case, I generate the account outside nxt client, there's no corresponding public key exist in the system, what if a person logon later with different passwd but the accountid happen to be the same as mine? does my balance all go to his account?
Jump to: