Author

Topic: NXT :: descendant of Bitcoin - Updated Information - page 1053. (Read 2761642 times)

full member
Activity: 148
Merit: 100
If I'm understanding this right, that means that if an otherwise active account gets a zero balance that carries over the blockchain pruning event, then the public key will be erased from the blockchain?  Or am I misunderstanding?
I don't think doing this during blockchain pruning is a good idea. Just sent everything below 1 NXT as a fee, automatically. Don't accept transactions to other accounts if their balance would be lower than 1 NXT after this. This way, it's not possible to have lower balance.  
Blockchain and balance sheet should be equivalent. Blockchain is an incremental update of balances, balance sheet is a consolidated version.  

It's possible to accept lower balances, but at 0.01 NXT minimum balance maximum theoretical balance sheet size is 3.2TB.

Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.  

Am not quite getting this - is your figure of 44721 based upon a "current snapshot" - as I am talking about the theoretical maximum storage required for either 1M accounts or 1B accounts.

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.  
newbie
Activity: 38
Merit: 0
I have a couple of thoughts to share before I go to work for the night.

First:
as someone who BELIEVES CfB when he says nobody should trust anybody, I believe that asking us all to "trust" a mandatory update to 0.5.12, followed by a miserable admission of error and a mandatory update to v0.6.0 a few hours later – all without an explanation of the issue – is a violation.  I have stopped my server and will not restart it until the nature of the "critical bug", and its fix, are disclosed.

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.

hero member
Activity: 490
Merit: 504
Articles writing updates - some topics were assigned in last days (open bounty is up to 3.000 Nxt/good long article)

- Why is pure Proof of Stake in Nxt best solution for cryptocurrencies?

- How can you mine Nxt only with solar energy?

- How could decentralized exchanges change the world? (no Government, no censorship, USA, China...) - + decentralized messaging, DNS

- The 51% Attack - technical details, history of 51% attacks, how it ended, Nxt solution (is Nxt safer than other PoS currencies?) (Ghash's pool is risking Bitcoin's security again with 40% of the network's hashpower and no one is talking about it. Pools of PoW machines with enormous hashpower is Bitcoin's most pressing concern and biggest flaw right now. Nextcoin is the best answer to this. Why is it not being talked about more?)
- Zahlen

- Nxt: gaming friendly currency (vs. Litecoin, a graphic cards killer) - Due to Litecoin's difficulty skyrocketing there is a global shortage of Graphic Cards, which piss off gamers tremendously and drive up the price for grahics cards. NXT solves this. (Uniqueorn's idea, maybe reserved for him..?)

- Nxt + Raspberry (+other similar platforms (Cubietruck)) (can be different articles, also short articles) (0 energy  forging package)

- Transparent Forging (very very technical, history of mining, comparisons)

Shorter articles/essays:

- Why should you invest in Nxt? (/Why should you invest in Nxt long term?)
- bithic
- Damelon
- many free spots

- Why is Nxt so friendly currency?: (i) It *doesn't* have VC capital backing. ii) It *doesn't* have "slick sales guys*. iii) It *does* have smart devs and an increasing following.  iv) It *is* delivering its promises (more or less) on time.) - more about the community, people form all over the world, community funding, decentralized company - a world of free individuals who all believe in Nxt. 1500 pages in Bitcointalk
- bithic

- How Nxt changed my life


Future (short) articles: (now it's to soon):

- Who accepts Nxt as a payment? (+ fee in Nxt vs. Bitcoin vs. fiat (VISA))
- Nxt invites altcoins to host on it's blockchain
- Can be a new internet stored on Nxt's blockchain / DNS system?
- Nxt clients: Damelon

Have you got any idea about some other article? Share it. We would love to have more scientific articles, financial, economical, IT...

Discussion in Topic: Nxt marketing & promotion
https://bitcointalksearch.org/topic/nxt-marketing-promotion-nxt-forum-now-moved-to-nxtforumsorg-412243
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.
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.  

If I'm understanding this right, that means that if an otherwise active account gets a zero balance that carries over the blockchain pruning event, then the public key will be erased from the blockchain?  Or am I misunderstanding?
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.  

Am not quite getting this - is your figure of 44721 based upon a "current snapshot" - as I am talking about the theoretical maximum storage required for either 1M accounts or 1B accounts.
full member
Activity: 148
Merit: 100
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.  
legendary
Activity: 1512
Merit: 1124
Invest in your knowledge
Is it possible to have scaling transaction fees?


You know, for larger transactions to get hit with more transaction fees? This would be a really nice feature for NXT
full member
Activity: 266
Merit: 100
NXT is the future
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.

 Cheesy

awesome, is it ready link?
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
I am also not sure where the size estimates are coming from.

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.

If this were being stored in a "flat file" then 1M accounts would requre 48 MB (and 1B would require 48GB).

Assuming only a "flat file" was used (i.e. no index file) then a map (stored in RAM) to identify where to find each account (64 bit file offset) would be required (if we had 1B accounts then that map would easily be at least 2GB and although that isn't too unreasonable it would make starting up the node very slow as it would need to create that map by scanning a 48GB file).

More likely you'd use an index file then (so add 2-4GB extra) requiring a node that is handling 1B NXT accounts to allow for approximately 50-52GB (actually not too bad IMO) for the "last checkpoint".

Assuming that the "blockchain" between checkpoints is no greater than say 50GB then it would look as though 100GB would probably be enough (although this last calculation would need some more analysis).
full member
Activity: 148
Merit: 100
A balance sheet is not something that needs to be forged. Every node should do it by itself - it has all available data.  
The only thing they should do is send the hash of deterministically-generated balance sheet after block x. The version with most NXT behind it becomes the official one.  

Ah yes - of course - thanks (should have realised this) so each and every (full) node will constantly be doing its own updating of a ledger and getting ready to "wipe out" the old history.

I guess the problem comes though in what do you send a brand new node who has no block chain (or do they need to download one from the last "checkpoint")?

Unfortunately, the only answer is: they have to download the blockchain from somewhere, starting from last checkpoint (or genesis) in code. They just don't have to store it.  

This means that full blockchain still needs to exist, just not on all nodes. Perhaps nodes with full blockchain can get a boost to their forging chance, as a fee paid for blockchain storage service? Like 2x their normal chance.  
member
Activity: 101
Merit: 10
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


add me 0.1 fee  Smiley
sr. member
Activity: 897
Merit: 284
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.

 Cheesy
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Nxt is light because of its Proof of Stake mechanism, and it is agile because the "protocol layer" consists of simple transaction verification, a blockchain mechanism, and a few core transaction types.

To use another analogy: if Bitcoin were an implementation of the OSI Model, its core might be seen as layers 1 through 4.  Nxt is layers 1 and 2, with upper layers left open for other people to build.  Nxt has stripped Bitcoin down to its best, brightest, beating heart and "reset" its foundation.  This allows for far more flexibility and agility than Bitcoin currently has, BUT leaves the advanced work (the "upper layers") to the community.

Well expressed and I agree that indeed it is these core differences that are the "key things" that sets Nxt apart (and therefore where the major development efforts should be focused).
full member
Activity: 210
Merit: 100
I have a couple of thoughts to share before I go to work for the night.

First:
as someone who BELIEVES CfB when he says nobody should trust anybody, I believe that asking us all to "trust" a mandatory update to 0.5.12, followed by a miserable admission of error and a mandatory update to v0.6.0 a few hours later – all without an explanation of the issue – is a violation.  I have stopped my server and will not restart it until the nature of the "critical bug", and its fix, are disclosed.

Second:  
In response to the cri du coeur over what Nxt's "killer feature" is, since the future of forging on Raspberry Pi and smartphones seems bleak, I offer the following:

Nxt's biggest and best feature is its blockchain and network.  Bitcoin is forever stuck on a Proof of Work form of consensus and a built-in scripting system for transactions. Neither of these can be "undone", and in fact the Bitcoin devs are loading even more bloat into the Bitcoin core with every release.  Everything "future-focused" that is being built on top of Bitcoin is being built on top of these inefficient, slow, "core" features.  Nxt has removed all of this and created a whole new set of primitives that bypass both of these hindrances.  Nxt has inherited some of Bitcoin's challenges (fungibility, blockchain growth, passphrase security), but it has completely bypassed several of the other ones (low transactions per second, an increasingly centralized mining network that burns $17 million in electricity per day)

Nxt is light because of its Proof of Stake mechanism, and it is agile because the "protocol layer" consists of simple transaction verification, a blockchain mechanism, and a few core transaction types.

To use another analogy: if Bitcoin were an implementation of the OSI Model, its core might be seen as layers 1 through 4.  Nxt is layers 1 and 2, with upper layers left open for other people to build.  Nxt has stripped Bitcoin down to its best, brightest, beating heart and "reset" its foundation.  This allows for far more flexibility and agility than Bitcoin currently has, BUT leaves the advanced work (the "upper layers") to the community.

The more I listen to Andreas talk about Bitcoin in various forums and panels, the more strongly I feel that THIS is what sets Nxt apart.  So stick that in your marketing pipe and smoke it Wink
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
A balance sheet is not something that needs to be forged. Every node should do it by itself - it has all available data.  
The only thing they should do is send the hash of deterministically-generated balance sheet after block x. The version with most NXT behind it becomes the official one.  

Ah yes - of course - thanks (should have realised this) so each and every (full) node will constantly be doing its own updating of a ledger and getting ready to "wipe out" the old history.

I guess the problem comes though in what do you send a brand new node who has no block chain (or do they need to download one from the last "checkpoint")?
full member
Activity: 238
Merit: 100
A blockchain needs to be as long as longest possible fork, at least. I don't know, half a day? Definitely not 20 blocks.  

Agreed - so a new "genesis" block would have to be the balance of all accounts from before the last possible "re-org" point.

BTW - said "genesis" block is going to become "huge" in the future (if we had one million accounts then surely we are talking 200-300 MB which you are not very likely to be able to be sending to nodes very quickly - or are we working on some sort of special format to "compress" a genesis block?).

Although it could be divisive it might also be worth "pruning" tiny balance accounts (ones with less than or equal to the minimum fee say) and having those as "fee rewards" for the construction of the new genesis block (this gives some added incentive to create it rather than just to "skip your turn" because of the "work involved").


Very interesting idea on the fees thing to prune small accounts. Do they lose their aliases too though, along with public key?  But I think as long as its a network requirement for the next block to be a Genesis block then somebody will forge it.  But it would be nice for a little pay off
newbie
Activity: 39
Merit: 0
On the Blockchain Pruning:

Why dont we implement a Finite Blockchain?
This has been discussed for bitcoin for a longer time and one of the biggest hurdle was to implement the accounts tree as bitcoins can be saved offline.
This is not hte case for NXT, perhaps it could be used to solve our problem.

Here is the paper: http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf
sr. member
Activity: 490
Merit: 250
I don't really come from outer space.


If we can recast a genesis block every 20th block as part of the routine operation of the NXT blockchain, we have accomplished something very, very special - a self limiting blockchain that grows very slowly.
A blockchain needs to be as long as longest possible fork, at least. I don't know, half a day? Definitely not 20 blocks. 

1440 blocks is the limit for blockchain reorganization if I'm remembering correctly.  So it would have to be just beyond there.

full member
Activity: 148
Merit: 100
Now that you mention this, I do remember C-f-b mentioning 32GB would be the hard limit, but why is this?
One billion (all possible nxt coins) * 32 bytes (length of public key). This assumes 1 NXT minimum balance. 
Obviously, much less in practice.
full member
Activity: 148
Merit: 100
BTW - said "genesis" block is going to become "huge" in the future (if we had one million accounts then surely we are talking 200-300 MB which you are not very likely to be able to be sending to nodes very quickly - or are we working on some sort of special format to "compress" a genesis block?).
Yes, but there's no need for that.  
A balance sheet is not something that needs to be forged. Every node should do it by itself - it has all available data.  
The only thing they should do is send the hash of deterministically-generated balance sheet after block x. The version with most NXT behind it becomes the official one.  
Jump to: