NXT :: descendant of Bitcoin - Updated Information

[Eadeqa]

Fee voting tally google doc spreadsheet.  Please check your vote and PM me if I made a mistake.

https://docs.google.com/spreadsheet/ccc?key=0Akjrt0LTBXgcdFFkSGMwXzd4Q2NPU21yU2NOYWVldlE&usp=sharing

fix me! only 1 to 0.1!

I never said 0.3333

0.01, so this thing isn't revisited any time soon

[1714120506]

1714120506

[1714120506]

1714120506

[1714120506]

1714120506

[1714120506]

1714120506

[1714120506]

1714120506

[1714120506]

1714120506

[iruu]

And somebody please tell me how you booby trap a genesis block so we've got to wait for source code release to start on this?

There's no need for this. A balance sheet is the exact same thing as blockchain, just in a different form. It doesn't matter what supposed traps are in a genesis block. It's not a problem.   

There's one big problem, a "referenced transaction". Currently you can send a transaction which is valid only if referenced transaction is valid. That's fundamentally incompatible with limited blockchain. So either the 'referenced transaction' is limited to 'transaction in the last n blocks' or it goes entirely.  

[CIYAM]

The performance version would be a list of public keys sorted by their account id with their balance id, which would take 34.34GB. This would have search performance lg(number of accounts), very fast.  

I still think you need to sort by account id not public key (as you send Nxt to an account # not to a public key) and of course there are Nxt accounts that actually don't have a public key associated with them (I think in terms of efficient DB structures as I've done a lot of work with that over the years).

There's one big problem, a "referenced transaction". Currently you can send a transaction which is valid only if referenced transaction is valid. That's fundamentally incompatible with limited blockchain. So either the 'referenced transaction' is limited to 'transaction in the last n blocks' or it goes entirely. 

Agreed - it would make sense to limit such things to the last 1440 blocks.

[iruu]

The performance version would be a list of public keys sorted by their account id with their balance id, which would take 34.34GB. This would have search performance lg(number of accounts), very fast.  

I still think you need to sort by account id not public key

But that's what I wrote. 

and of course there are Nxt accounts that actually don't have a public key associated with them

These would have to be treated separately, another list for uninitalized accounts, not a problem. 

[lyynx]

Has anyone been having issues since 5.12? I have been generating a ton of bad blocks since 5.11 and 5.12 . As of today, it has been out of control.

[Zahlen]

+2. Good post Zahlen. Better PM him in case he's stopped reading this thread.

Thanks, I did

Well, there goes my "work on Nxt" time for today. Becoming a trend lately

[opticalcarrier]

Regarding just purging accounts, what about when the value of .99NXT is extremely high, as we do expect it to? Or if an account with only .01 NXT in it has many aliases?  Then I dont think this would be feasable and I think we must design for the worst case of  .01 NXT (or .001 or .0001 or whatever we go with) in many accounts, and write a new genesis block with public keys coupled with balances and aliases, coded in binary format.

Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.

At a minimum you would need to store the account # (64 bits) plus the public key (256 bits) plus the balance (64 bits?) which would be 384 bits or 48 bytes per account.

Account id is a sha of public key. It doesn't need to be stored, except as an optimization.  
Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.  

thanks Ciyam for doing that math, I was away from home reading on my phone and was gearing up to do it myself when I got back

Actually it's 44720, sorry, didn't notice the rounding.
There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
For smallest increase 0.01, it's 447114 different balances possible at the same time, still with 1 NXT minimum balance.  

Im not following, what is the signifigance of the number 44720 in regards to 1 billion?  I feel dumb for not knowing, it seems like I probably should not have to ask this question  

EDIT: wait i figured it out, you are trying to save space on storing balances.  i r not completely dumb




Obviously we would purge

[xyzzyx]

Has anyone been having issues since 5.12? I have been generating a ton of bad blocks since 5.11 and 5.12 . As of today, it has been out of control.

Upgrade to 0.6.0, please.

http://wiki.nxtcrypto.org/wiki/Nxt_Software

[opticalcarrier]

To a certain extent if the lead developer issues a release and says it's critical we have no choice but to trust him.  But, outside developers can and should perform their own independent audits of new releases to see if something suspicious is done and raise the alarm if need be.

Most Nxt users are not "developers", so while I take your point, I also suggest that most people are being asked to update software without being able to understand OR verify the reason for the update.  It's the software-developer equivalent of "trust me. Just do it."

It's hypocritical to build a decentralized system that is supposed to be trustless, and then ask "untrusted" members of that community to "trust" that they should install new software and not ask questions of the "untrusted" people who issue the order.

You can do your own thing, of course, but I won't give.  I'm not gonna jump off a bridge just because Jean-Luc or CfB says so.  What they've done is bad, and they should feel bad.  When I get an explanation, I'll update my software.

must be something really bad like a zero day

[CIYAM]

But that's what I wrote. 

Sorry - my mistake in wording - so in your approach the account id is effectively a "transient" determined when you load an index node into memory?

[xyzzyx]

Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.

Is there any way this could lead to a Sybil attack?

Merchants may generate a unique address for each patron.  Once the public keys are discarded, how easy would it be for an attacker to generate one for that address?

[opticalcarrier]

And somebody please tell me how you booby trap a genesis block so we've got to wait for source code release to start on this?

There's no need for this. A balance sheet is the exact same thing as blockchain, just in a different form. It doesn't matter what supposed traps are in a genesis block. It's not a problem.   

There's one big problem, a "referenced transaction". Currently you can send a transaction which is valid only if referenced transaction is valid. That's fundamentally incompatible with limited blockchain. So either the 'referenced transaction' is limited to 'transaction in the last n blocks' or it goes entirely.  

other big problem is effectiveBalance vs balance and previous transactions not having 1440 confirmations

[CIYAM]

Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.

Is there any way this could lead to a Sybil attack?

If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?).

[xyzzyx]

other big problem is effectiveBalance vs balance and previous transactions not having 1440 confirmations

I don't think this will be a problem.  You would still have the most recent 1440+ blocks.

[opticalcarrier]

Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.

Is there any way this could lead to a Sybil attack?

If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?).

no i think hes right, and i was wrong.  you didnt quote his edit to add the blurb about merchants storing old accounts.  things could get very hairy and mixed up that way..  kinda dangerous the more I think about it, to completely purge.  wed have to well publicize the risk

would also have to handle the upcoming ability to transfer your effectiveBalance to lease your forging power out.  Wed either have to track that as well or just make it kick back to account owner upon pruning

[xyzzyx]

Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.

Is there any way this could lead to a Sybil attack?

If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?).

no i think hes right, and i was wrong.  you didnt quote his edit to add the blurb about merchants storing old accounts.  things could get very hairy and mixed up that way..  kinda dangerous the more I think about it, to completely purge.  wed have to well publicize the risk

They may not be able to do it *right now*, but in a few years it may become feasible.  From the attacker's point of view it's the same problem to solve as darkNXT mining.

[xyzzyx]

Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.

Is there any way this could lead to a Sybil attack?

If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?).

Would the account with a zero balance and a full public key survive the blockchain pruning event?  Perhaps I'm not understanding fully, but it looks to me that it wouldn't.

That is, the public key would be discarded on an empty account.  No?

[EmoneyRu]

More fun updates on my installer...a picture say it all:
It now checks the SHA-256 of the Nxt-Client-0-x-x.zip file BEFORE it is extracted and installed. If it fails, setup is forced to exit.
Still have some work to do, but the proof of concept is there and working.
 

Useless pop-up. 1 unneeded click

[CIYAM]

That is, the public key would be discarded on an empty account.  No?

Yup - but if when you go to create a new account you can include the public key it must use (this will require a fee to stop spamming) then it wouldn't matter if the same account with a different public key had existed before (and no way to "drain" that account).

[iruu]

Actually it's 44720, sorry, didn't notice the rounding.
There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
For smallest increase 0.01, it's 447114 different balances possible at the same time, still with 1 NXT minimum balance.  

Im not following, what is the signifigance of the number 44720 in regards to 1 billion?  I feel dumb for not knowing, it seems like I probably should not have to ask this question  

1 + 2 + 3 + ... + n = one billion.
The largest n so that the sum is not larger than one billion is 44720. Therefore, there are at most 44720 different balances possible at the same time. Or 447114 for 0.01 step.  

Sorry - my mistake in wording - so in your approach the account id is effectively a "transient" determined when you load an index node into memory?

I'm not sure what you're asking here. What is an 'index node'?
I have an array of pairs (public key, balance index), and I sort them by first 64 bit of public key's sha256, which is an account id.
If I want to find account's public key and balance I binary search for it in this sorted array, which gives me public key and balance index.
Balance index is an index into an array of all currently existing balances.  

no i think hes right, and i was wrong.  you didnt quote his edit to add the blurb about merchants storing old accounts.  things could get very hairy and mixed up that way..  kinda dangerous the more I think about it, to completely purge.  wed have to well publicize the risk
would also have to handle the upcoming ability to transfer your effectiveBalance to lease your forging power out.  Wed either have to track that as well or just make it kick back to account owner upon pruning

Accounts should be 256 bit public keys and that's it. 64 bit account numbers are a complete idiocy.  

The only way to both have a secure system and finite blockchain is to make accounts 256 bit, with extra code for backward compatibility with current accounts. Which is obviously not going to happen.