 Show Posts
|
|
Pages: « 1 2 3 [4]
|
@minusbalancer did you write the java code into c sharp / VB / Java sharp code? Or you wrap the java code around with the .NET interface?
Are you going to have it open source?
It's pure .NET. No java underlying. I will publish the source as soon as client will be stable enough to be forked |
|
|
|
UPD: Messaging was implemented at dotNXT. Here are some of the existent messages: 
|
|
|
|
To bring even more interest to my client I decided to make the current development version available to try. You can get it at https://mega.co.nz/#!YJ9TVCCY!MkmGIHfsQrLxLHlV-tkRsmZC3sxzm7a13o5qMp5XvycPlease note it's just a version to get the idea. PS: you do not need original NXT server running. and you do not need to unlock your accounts to see blocks, transactions, aliases and for sending the money |
|
|
|
Can I test it?
Sure, will drop you a link in private when i will get home (in 4-5 hours approx). |
|
|
|
I would like to apply to contest with my client as well.
.NXT (dotNXT)
It's pure .NET based client (yeah - no java required on Windows).
Planned release to public: 19 Jan 2014.
Supported features:
- Send Money, view your transactions.
- Register alias, browse aliases
- Forging (the transparent one as well)
- Hallmark checks
- Multiple accounts at 1 window
Currently known issues:
- Can not run as node
- Orphaned chains are not displayed correctly
Sorry minusbalancer, this reward is only for projests before 3th januari. Well i am working on it since december. I did not publish any info until first beta not to make any promises i couldn't handle. |
|
|
|
How often do you poll? As far as I understand, nxt uses http 'GET' to get json from nxt backend - at least that is what I do.
That begs the question for me: If it is 'GET' polling, the server can't 'PUSH', so the client must 'GET' 'continuously', ie at certain intervals.
Furthermore, there would be a certain set of data that keeps getting pulled, ie transactions, blocks, peers etc, the whole shebang that can be seen in the windows.
Polling is done the same way as original app does. 1 per second for unconfirmed transactions. 1 per second for the new blocks. However other nodes are polled by POST requests not the get one. It's functioning the same way original client behind the NAT/Firewall without port forwarding. So not too much trouble here. Node version is planed when the client gets stable. Source will not be released until the client gets stable enough to be forked. |
|
|
|
I would like to apply to contest with my client as well. .NXT (dotNXT) It's pure .NET based client (yeah - no java required on Windows). Planned release to public: 19 Jan 2014. Supported features: - Send Money, view your transactions. - Register alias, browse aliases - Forging (the transparent one as well) - Hallmark checks - Multiple accounts at 1 window Currently known issues: - Can not run as node - Orphaned chains are not displayed correctly Here are some screenshots that I just made  Accounts view:  Unconfirmed transactions:  Blocks:  Peers:  Aliases: TBD |
|
|
|
You has received the exchange fee 0.2% Why BTC withdrawal fees 1% again, so high, Robbery? I refuse.. BTC-E exchange fee 0.2%, but the withdrawal fees only 0.001 BTC. Then you could just start trading at btc-e with your NXT. Oh wait ... |
|
|
|
Imagine you do have the following sequences of blocks returned: b1, b2, b4, b3
All of the blocks are valid and aren't damaged. Existing code won't process this sequence. However adding just 1 line (updating currentBlockId) will make the code work like it was planned.
returned from WHERE? I assume you were reffering to commonBlockId not currentBlockId They will either be added after commonBlockId or, if there was a split, proper block will be removed and they will be added AFTER popped blocks. So I still don't see a problem You are correct. I was referring the commonBlockId. It will take too long too explain. I am not referring the scenario with 2 nodes. Imagine we do have just 1 node and the sequence is wrong in JSON. Still it's not 1 of the injected flaws so doesn't matter. |
|
|
|
The whole "futureBlocks" branch of code doesn't work because of the bug.
We should update the commonBlockId once we successfully push the block.
If we will have the "futureBlocks" it will roll out all of the newly added blocks (if any) because of non updated currentBlockId.
Then it will try to add the "futureBlocks" and will fail again. So at the end the whole block chain will be rolled back and peer banned.
It's at line 4570 and further.
Thx, I'll look at that. I disagree. I don't think it's wrong. I think these situations are simply exclusive. That is, there can't be both: new blocks added and futureBlocks added. (I was claiming this here: https://bitcointalk.org/index.php?topic=397183.msg4406466#msg4406466) Imagine you do have the following sequences of blocks returned: b1, b2, b4, b3 All of the blocks are valid and aren't damaged. Existing code won't process this sequence. However adding just 1 line (updating currentBlockId) will make the code work like it was planned. |
|
|
|
With the published code no one will be able to generate any block ever.
In getEffectiveBalance() we do have the check for the account age of 1440 (blocks).
Since at the beginning of the functioning the system all of the accounts had 0 age, none of them will be able to generate the block.
No blocks generated => no age increase.
Accounts listed in genesis block can generate blocks, their age is not analyzed. Agree. Then we do have the other bug - outgoing transactions are not deducted from the "genesis" created accounts while calculating the effective balance. Edit: incoming |
|
|
|
|
With the published code no one will be able to generate any block ever.
In getEffectiveBalance() we do have the check for the account age of 1440 (blocks).
Since at the beginning of the functioning the system all of the accounts had 0 age, none of them will be able to generate the block.
No blocks generated => no age increase.
|
|
|
|
|
The whole "futureBlocks" branch of code doesn't work because of the bug.
We should update the commonBlockId once we successfully push the block.
If we will have the "futureBlocks" it will roll out all of the newly added blocks (if any) because of non updated currentBlockId.
Then it will try to add the "futureBlocks" and will fail again. So at the end the whole block chain will be rolled back and peer banned.
It's at line 4570 and further.
|
|
|
|
Lets take a look at the method that returns the block id: byte[] hash = MessageDigest.getInstance("SHA-256").digest(getBytes());
BigInteger bigInteger = new BigInteger(1, new byte[] {hash[7], hash[6], hash[5], hash[4], hash[3], hash[2], hash[1], hash[0]});
return bigInteger.longValue();
The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method. Hash function is calculated based on all of the bytes from the block. Id is taken from first 64 bits of the hash. Not the first 64 bits of the getBytes() |
|
|
|
|
Hi everyone.
Is NXT worth spending an investment?
Can someone tell their ideas?
Cheers!
|
|
|
|
|
