iruu
|
|
February 06, 2014, 02:57:39 AM |
|
Immediate monstercrash starting 6.0 on my VPS....
The monstercrash is due to blockchain storage property re-added to web.xml. *.nxt files work.
|
|
|
|
rickyjames
|
|
February 06, 2014, 02:58:33 AM |
|
Do pruned and non-pruned blockchain node can interact with each other?
They would have to. THe genesis node has got to distribute the new genesis block to the non-genesis nodes in the minute. And while the new genesis block is being forged, no new transactions for that minute. The transaction nodes know that a genesis node is thinking.
|
|
|
|
iruu
|
|
February 06, 2014, 03:00:16 AM |
|
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.
|
|
|
|
lucky88888
Sr. Member
Offline
Activity: 404
Merit: 250
https://nxtforum.org/
|
|
February 06, 2014, 03:01:46 AM |
|
VOTE 0.1 FEE per transactionThis will encourage those new nxters who's only income are from faucets. If they get 2 nxt, they are likely happy to send 1nxt out for fun or to a friend and still end up with some balance. EVERYONE MUST UPDATE TO 0.6.0 to AVOID ANY LOSSES162.243.82.115 162.243.82.115 0 2 B 140 B NRS (0.6.0) @ MOON
|
Fuck Mt.Gox! Fuck Mintpal! Fuck Bter! FUCK kyc! Protect yourself use MGW! SUPERNET! Recommended ASSET ->InstantDex : Lead Dev Jl777 (decentralized multi currency instant exchange) Recommended ASSET -> Jinn : Lead Dev Come-from-Beyond (ternary processors!) https://nxtforum.org/news-and-announcements/(ann)-jinn/
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 03:09:30 AM |
|
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").
|
|
|
|
MarvellousMutant
Newbie
Offline
Activity: 39
Merit: 0
|
|
February 06, 2014, 03:09:42 AM |
|
|
|
|
|
pandaisftw
|
|
February 06, 2014, 03:13:06 AM |
|
If we do pruning (aka restart genesis) every 1k blocks, I'm pretty sure even the slowest smartphone can do it in under a second. Assuming a constant 1000tps, that's 60,000,000 transactions every 1000 blocks. I'm not sure how many processor cycles it takes to iterate through each transaction and do addition/subtraction to the proper accounts. I'm pretty sure my galaxy S2 (old phone, I know) can crunch that in a few seconds tops. Even if the device couldn't crunch all that data within the minute, what is prevent the node from precalculating? For example, as each new block is added, the node will add all of the transactions that happened in that block to the ones that happened before. In this way, when the 1000th block hits, all of the nodes will already have the complete picture, ready to broadcast, forming a seamless transition between the old genesis and the new. Those who have a different picture (less difficulty) will be rejected. Lastly, this: Did the author really attribute NXT's success to the ~60 members of reddit? Terrible article, it reeks of paid advertising. I officially request that the NXTcommunityfund put out a bounty for the first person that successfully forges a block onto a simulated 300 GB NXT blockchain in a testbed setup. Full specifications of system used and documentation of experiences in accomplishing the task required to claim the reward.
If infrastructure committee does not take care of this, i will create bounty I like fee of .1 nxt for now, we can adjust again later I think marketing should shift to 100 tps and this allows raspis to be useful, let moores law keep doubling our tps. Bitcoin blockchain does not gain tps with moores law, nxt does In two years 300 gb wont seem so big Also, nxt core is such that all cool stuff, mission critical, competitor defensive, fun and quirky, everything can be developed in parallel as long as we have the resources. We now have nearly 1 million usd budget to be able to fund everything in parallel, plus as nxt gains value so does budget! These are very good developments for nxt! We are discussing seious issues and ways to improve all aspects of nxt. Everyone can contribute. I am so proud to be part of NXT!!! James Where did 300GB come from? That's way too much. Nxt needs about 32GB (theoretical, unreachable maximum) for balances... Now that you mention this, I do remember C-f-b mentioning 32GB would be the hard limit, but why is this?
|
NXT: 13095091276527367030
|
|
|
iruu
|
|
February 06, 2014, 03:14:13 AM |
|
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.
|
|
|
|
iruu
|
|
February 06, 2014, 03:15:41 AM |
|
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.
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 06, 2014, 03:16:55 AM |
|
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.
|
"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
|
|
|
MarvellousMutant
Newbie
Offline
Activity: 39
Merit: 0
|
|
February 06, 2014, 03:17:39 AM |
|
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
|
|
|
|
opticalcarrier
|
|
February 06, 2014, 03:17:43 AM |
|
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
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 03:19:44 AM |
|
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")?
|
|
|
|
joefox
|
|
February 06, 2014, 03:27:09 AM |
|
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
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 03:30:48 AM |
|
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).
|
|
|
|
Mistafreeze
|
|
February 06, 2014, 03:31:42 AM |
|
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.
|
|
|
|
mezzovide
Member
Offline
Activity: 101
Merit: 10
|
|
February 06, 2014, 03:35:39 AM |
|
add me 0.1 fee
|
Btc : 12LMdyWoyjJ1BZxfWmaZMWjTXn7S9y5EdK
|
|
|
iruu
|
|
February 06, 2014, 03:36:54 AM |
|
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.
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
February 06, 2014, 03:49:44 AM |
|
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).
|
|
|
|
pinarello
Full Member
Offline
Activity: 266
Merit: 100
NXT is the future
|
|
February 06, 2014, 03:52:04 AM |
|
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. awesome, is it ready link?
|
|
|
|
|