elective-stereophonic
elective-stereophonic
Nxt 2.0 design
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.1 Upgrade before block 2870000 is mandatory!

Pages: 1 ... 16 17 [18] 19 20 ... 51

Author Topic: Nxt 2.0 design  (Read 210712 times)

sadface

  • Sr. Member
  • ****
  • Karma: +16/-2
  • Offline Offline
  • Posts: 273
    • View Profile
Re: Nxt 2.0 design
« Reply #340 on: February 12, 2016, 06:41:50 pm »

but there is no pruning on the mother chain. it sounds very vague without any numbers to go with it.
Logged

petko

  • Full Member
  • ***
  • Karma: +24/-0
  • Offline Offline
  • Posts: 100
    • View Profile
    • My blog
Re: Nxt 2.0 design
« Reply #341 on: February 12, 2016, 07:10:39 pm »

but there is no pruning on the mother chain. it sounds very vague without any numbers to go with it.
tps on the mother chain will not be increased (or may even be decreased). Transaction throughput of the whole system will
Logged

sadface

  • Sr. Member
  • ****
  • Karma: +16/-2
  • Offline Offline
  • Posts: 273
    • View Profile
Re: Nxt 2.0 design
« Reply #342 on: February 12, 2016, 07:24:31 pm »

thanks for the answers so far, however this is taking more posts than it should :)
you must have some numbers in mind. its such a big design change, there really should some detail on what to expect. if we go from e.g. 7 tps to 10 or 20, then a legitimate question would be: 'why even bother?'.
if you cant outline a very rough estimate, then its a total shot in the dark.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #343 on: February 12, 2016, 07:40:08 pm »

For the last two years, we have 1880996 transactions, which makes approximately 1.8 transactions per MINUTE.

The database size is 1.5 GB, takes 2 h to download on a fast machine, 24 h on a slow one.

If we had 200 transactions per minute instead for the last 2 years, the database size would have been X GB, and it would take Y hours to download even on a fast machine.

Calculate X and Y and see if the 255 transactions per block is really the limiting factor we should worry about.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

lurker10

  • Hero Member
  • *****
  • Karma: +168/-33
  • Offline Offline
  • Posts: 1334
    • View Profile
Re: Nxt 2.0 design
« Reply #344 on: February 12, 2016, 07:56:17 pm »

For the last two years, we have 1880996 transactions, which makes approximately 1.8 transactions per MINUTE.

The database size is 1.5 GB, takes 2 h to download on a fast machine, 24 h on a slow one.

If we had 200 transactions per minute instead for the last 2 years, the database size would have been X GB, and it would take Y hours to download even on a fast machine.

Calculate X and Y and see if the 255 transactions per block is really the limiting factor we should worry about.

42 kb * 1440 * 365 = 21 GB a year. Most people download the blockchain from peerexplorer, I think. It's not the size of the blockchain per se, I believe, it's how efficient the database H2 is in selecting and updating in millions of rows?

One blockchain is not scalable, we need sidechains before it becomes a problem. Luckily we have JL who knows what to do :)
« Last Edit: February 12, 2016, 07:58:37 pm by lurker10 »
Logged
Run a node - win a prize! "Lucky node" project jar: NXT-8F28-EDVE-LPPX-HY4E7

sadface

  • Sr. Member
  • ****
  • Karma: +16/-2
  • Offline Offline
  • Posts: 273
    • View Profile
Re: Nxt 2.0 design
« Reply #345 on: February 12, 2016, 07:58:16 pm »

For the last two years, we have 1880996 transactions, which makes approximately 1.8 transactions per MINUTE.

The database size is 1.5 GB, takes 2 h to download on a fast machine, 24 h on a slow one.

If we had 200 transactions per minute instead for the last 2 years, the database size would have been X GB, and it would take Y hours to download even on a fast machine.

Calculate X and Y and see if the 255 transactions per block is really the limiting factor we should worry about.

thats one way to answer it. i have to ask these questions to put the design proposal into perspective and i am surprised nobody else is asking. i find the outlining in the original post insufficient to form an opinion.
« Last Edit: February 12, 2016, 08:00:49 pm by sadface »
Logged

coinomat

  • Hero Member
  • *****
  • Karma: +214/-18
  • Offline Offline
  • Posts: 1520
    • View Profile
Re: Nxt 2.0 design
« Reply #346 on: February 12, 2016, 08:16:43 pm »

Don't know what to say guys.
LOL.
I wish you all the best.
after all you're the devs. do whatever the fuck you please :)
Logged
Time to go further

MrV777

  • Hero Member
  • *****
  • Karma: +115/-4
  • Offline Offline
  • Posts: 988
    • View Profile
Re: Nxt 2.0 design
« Reply #347 on: February 12, 2016, 08:18:54 pm »

I have a question that hopefully won't lead to another tangent.  I understand how the child chains will help with bloat and thus tps limits.  I think it's great to start thinking about this now if NXT is to have a future, otherwise it might be too late like what bitcoin is dealing with in their block limit.
Would anything in NXT 2.0 help with transaction speeds though?  I believe right now it is still recommended to wait for 10 confirmations of a tx (which is about 10 minutes), while I'm sure people would love to hear about instant transactions  ;D
« Last Edit: February 12, 2016, 08:21:34 pm by MrV777 »
Logged
NXT: NXT-BK2J-ZMY4-93UY-8EM9V
NXT nodes: 209.222.98.250, 216.155.128.10

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Nxt 2.0 design
« Reply #348 on: February 12, 2016, 08:24:51 pm »

Transaction confirmation speed will not change.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: Nxt 2.0 design
« Reply #349 on: February 12, 2016, 08:30:11 pm »

The suggestion is that each account, in order to receive fNXT according to his proportional NXT stake would have to register a specific "Keep Alive" property on his account. By this the account owner proves that he poses the passphrase for this account and that the she cares enough about NXT in order to register this property.
The distribution code will iterate over all accounts, filter out those who did not register the property, then distribute fNXT proportionally based on the NXT stake of the accounts that did register the property.
If we were going this route, I'd be more generous. I'd give the fNXT to any account that had any out-going activity in the 2 years prior to the fork. Such activity would prove the owner still knew the private key. Forging would count as an activity. (If they are forging on the main fork, they must have updated their node, and that shows activity.) This means a sleeping whale could wake up, make any trivial 1 NXT transaction, and go to sleep again, and that would be fine with me. It'd also mean that someone who was using Nxt, but not paying attention to the forum, would not miss out.

One good reason to use such a property or some other way of confirming the account is still in use would be to prevent giving fNXT to accounts without public keys announced.
Well, we could simple give fNXT to every account that has a public key. That would solve that issue.

How many NXT, without public keys, are there currently? Is it a significant threat?

If we want nxt to be money and valued as money in the future, it means you can buy it, save it, forget about it, come back a few years later and sell it, without having lost voting or forging rights in the meantime.
Mostly I agree with this. If we don't treat property rights as sacred, we set a bad precedent. It undermines faith in the system. I'm not sure any of the benefits of these schemes are worth compromising this.

There is an argument that what they own now is NXT and what they'd own in 2.0 would still be NXT. They'd miss out on fNXT but that is a new and different thing. I don't think this argument is really valid.
Logged

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: Nxt 2.0 design
« Reply #350 on: February 12, 2016, 08:44:18 pm »

Scaling by using snapshots causes all transaction history to be unsaved.
Even though nodes could still have that data, they have no incentive to share that date.
This would mean that I open my nxt account and I can't see my previous transactions, messages, trades, etc.
Just because it can be pruned doesn't mean it has to be. It means you can control what to keep. So you could keep all transactions involving your own account on your local machine, for example. (We already have the nxt.ledgerAccounts config setting as a kind of precedent for this.) Or you could keep all NXT and fNXT transactions and prune the child-chains that you weren't interested in.

No account control for the token that needs security the most, as it controls the security of all childchains?
Account control provides, well, control. Not security.
But surely we need that control? A corporate account might need 2 or more signatures to dispose of fNXT. And as I wrote a few days ago, we surely also need vote-by-fNXT to decide community issues. (Or will vote-by-fNXT be possible on the NXT child-chain?)

Would it not be possible to allow such transactions, but make them so expensive that they rarely get used and hence don't contribute much bloat? If you're right and they aren't needed, they won't be used at all.
Logged

TheCoinWizard

  • Hero Member
  • *****
  • Karma: +97/-55
  • Offline Offline
  • Posts: 614
  • Learn by questioning everything!
    • View Profile
Re: Nxt 2.0 design
« Reply #351 on: February 12, 2016, 09:05:05 pm »

I understand this is intentional and required from an economic perspective in your design. One flaw for nxt is that the nxt blockchain keeps getting bloated with death childchains snapshots while not getting rewarded for keeping this snapshot alive.
The cost of keeping that state has already been paid by transaction fees for that child chain, because the larger the state, the more transactions have been processed and fees paid.
You cannot pay an infinite service with a one time payment, sooner or later the service cannot be maintained. The service is keeping the (long death) childchain snapshot available on the fNXT blockchain.
Having to keep the final state of a dead chain, expressed as accounts balances, is much less than having to keep all transactions that led to this state.
True, the only problem is the loss of date....
Which can be solved with archival nodes, which should receive a financial incentive for doing that, otherwise that system wont be economically viable in the long term.
And if we really becomes a problem, we could think about defining some conditions under which such state can be dropped and the child chain deleted for good. No need to plan for this now.
A symptom of a bad system is the constant need for new rules and changing them constantly.
Quote from: TheCoinWizard
The current way of working, being complete transaction blockchains, already solved that incentive problem. Taking the solution away in order to scale better is not a good scaling solution
Scalability is way more important than this hypothetical problem.

I am glad you are taking it upon yourself to try to improve scalability, understand how your design improves upon that and am thankful. Using snapshots is indeed a way to improve upon that, but also creates new problems. You can improve scalability by having only a subselectons of nxt forgers supporting different childchains.
Quote from: TheCoinWizard
Duplicity being that every nxt node has a copy of every childchain, or in your case only snapshot.
It is better to not have every nxt node/forger having to process every childchain and keep every childchain.
Someone trying out a childchain doesn't need as much copies of its childblockchain as nxt has (archival) nodes. This duplicity all costs money.
It is not possible to establish consensus without every node having the full current state of all chains. Your proposal contains a desire to achieve that, but I don't see an explanation how it could be achieved.
It basicly is offering an interface that lets you create a nxt clone that uses the pos of nxt forger.
On top of that enabling nxt forgers to select which of these chains they want to forge upon, and how long they want to support new childchains for the purpose of bootstrapping.
Logged
Welcome to the After Nxt Calendar era...
Which started in the year 222 of the French Republic, Frost month, on the fifth day of the first week, better known as the 2456621th Julian day,
even better known as 24 November 2013 at 12:00:00 UTC.

Benzedi

  • Jr. Member
  • **
  • Karma: +7/-11
  • Offline Offline
  • Posts: 85
    • View Profile
Re: Nxt 2.0 design
« Reply #352 on: February 12, 2016, 11:45:57 pm »

The distribution of fNXT should be 1:1 and nothing else.

Anything else would build resentment from people who own NXT but haven't kept up with the community or simply want to trade it.
Logged

Vyazhan

  • Full Member
  • ***
  • Karma: +20/-0
  • Offline Offline
  • Posts: 110
    • View Profile
Re: Nxt 2.0 design
« Reply #353 on: February 13, 2016, 10:43:40 am »

I can't really dig through all of this, but just from a feeling, I feel it's gonna get a lot of people even more disinterested in NXT, as it's always complicated compared to many other cryptos and introducing this will remove more casual NXT users for sure :)
The casual user will hardly see any difference. When you download and start the NRS client, you will see the NXT child chain the way you see the current blockchain now, and all transactions will happen on that NXT child chain. The end user will not even be aware that there is a forging chain, unless he becomes interested in how to forge.

How exactly the other child chains will be accessible, which of them if any will be possible to switch to from the default NRS client, this is all a matter of UI. Some child chain creators may want custom clients, with which only their child chain is visible. For commonly used child chains, for example if SuperBTC becomes such a child chain, there may be a way to switch to it from the default client. Or even do transactions on another child chain without the user realizing it, for example if placing an asset ask order and the user wants to place it in SuperBTC, the client submits the transaction on that child chain without the user having to be aware of how it works. How it is presented in the UI is a whole different story, it does not need to reflect how the server part works.

I see, thanks a lot for clearing this up and for providing a great explanation, I get this much better now!
Logged

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +439/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: Nxt 2.0 design
« Reply #354 on: February 14, 2016, 01:34:20 pm »

I have a straight question: is it possible to have all sidechain stuff without these fNXT and other NXT stuff?

Actually, when jean-luc introduced this plan to me, that was the first thing I asked too. I mean why would you have to go into all this trouble and risk of separating fNXT from NXT just in order to get child chains ?
The reason is, that if we keep using the same token for financial transactions (NXT) and forging (fNXT) we won't be able to prune the main NXT blockchain which represents most of the blockchain bloat. Since scalability is the most important design goal of this feature, this defeats the whole purpose.
By separating the chains, we can prune the NXT chain so that the blockchain only stores the current state + last 1440 blocks. This is obviously much smaller than keeping the whole NXT blockchain as is. Probably by a factor of 1:100 perhaps 1:1000.

I mean, take a look at the current transactions on the NXT blockchains, block 653136, 3 message related to ATM operator and 1 asset bid, block 653134 message transaction by ATM operator. block 653133 message related to NXTPricer.
Do we really need to keep these transactions in the blockchain forever ?

All other blockchains including first and foremost Bitcoin, has this problem. We can solve it. This is a huge competitive advantage.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

OutSL

  • Sr. Member
  • ****
  • Karma: +60/-0
  • Offline Offline
  • Posts: 332
  • Banned!
    • View Profile
Re: Nxt 2.0 design
« Reply #355 on: February 14, 2016, 02:52:40 pm »

I have a straight question: is it possible to have all sidechain stuff without these fNXT and other NXT stuff?
...
I mean, take a look at the current transactions on the NXT blockchains, block 653136, 3 message related to ATM operator and 1 asset bid, block 653134 message transaction by ATM operator. block 653133 message related to NXTPricer.
Do we really need to keep these transactions in the blockchain forever ?
do you think the solution you are looking for below will solve the problem of NXT ecosystem economic recession mentioned above?
All other blockchains including first and foremost Bitcoin, has this problem. We can solve it. This is a huge competitive advantage.

I have a straight question: is it possible to have all sidechain stuff without these fNXT and other NXT stuff?
for me and any business man or economist = inflation;
in the actual state of the NXT economy this will be the end of the road...

dear DEVs, you don't need to proof something to the blockchain industry or the crypto-currency world because you have already something! you have made an innovative all-in-one concept really unique and i am sure that under the wood there is a wonder as code and software architecture but that is not what the user sees, uses and needs ...
if only you invest the same effort to create this childchains architecture in rewriting the marketplace it will restart the economic dynamics... and bring a bit of life to this ecosystem...

Thank you and @++
Logged
Thank you for your financial help, your donations will be used in the R&D related to the implementation of NXT in the virtual worlds running under OpenSimulator.org | Donations Box : NXT-PC8Q-ZW86-7UYK-CC4XJ
Visit The NXT Community Virtal World! Your NXT 3D Chat Service

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1764
    • View Profile
Re: Nxt 2.0 design
« Reply #356 on: February 14, 2016, 03:22:30 pm »

I have a straight question: is it possible to have all sidechain stuff without these fNXT and other NXT stuff?

Actually, when jean-luc introduced this plan to me, that was the first thing I asked too. I mean why would you have to go into all this trouble and risk of separating fNXT from NXT just in order to get child chains ?
The reason is, that if we keep using the same token for financial transactions (NXT) and forging (fNXT) we won't be able to prune the main NXT blockchain which represents most of the blockchain bloat. Since scalability is the most important design goal of this feature, this defeats the whole purpose.
By separating the chains, we can prune the NXT chain so that the blockchain only stores the current state + last 1440 blocks. This is obviously much smaller than keeping the whole NXT blockchain as is. Probably by a factor of 1:100 perhaps 1:1000.

I mean, take a look at the current transactions on the NXT blockchains, block 653136, 3 message related to ATM operator and 1 asset bid, block 653134 message transaction by ATM operator. block 653133 message related to NXTPricer.
Do we really need to keep these transactions in the blockchain forever ?

All other blockchains including first and foremost Bitcoin, has this problem. We can solve it. This is a huge competitive advantage.
Finally we got some numbers. So you are implying we will have a 10 Mb blockchain instead of 1 Gb. Not bad. Although it is arguable that 990 Mb cut is worth experimenting with NXT splitting I think there are other options to achieve similar result without coin splitting.
Eg we could make payments and AE unprunnable and move everything else to sidechains. Or maybe even make bids and asks prunnable and assets permanent (if possible).
Also it looks like the prunning effect was never calculated properly (100x or 1000x is a big difference). We hardly can evaluate different options without better calculation of the effect on blockchain bloat.
Logged

martismartis

  • Hero Member
  • *****
  • Karma: +73/-10
  • Offline Offline
  • Posts: 1238
    • View Profile
Re: Nxt 2.0 design
« Reply #357 on: February 14, 2016, 04:08:18 pm »

I have a straight question: is it possible to have all sidechain stuff without these fNXT and other NXT stuff?

Actually, when jean-luc introduced this plan to me, that was the first thing I asked too. I mean why would you have to go into all this trouble and risk of separating fNXT from NXT just in order to get child chains ?
The reason is, that if we keep using the same token for financial transactions (NXT) and forging (fNXT) we won't be able to prune the main NXT blockchain which represents most of the blockchain bloat. Since scalability is the most important design goal of this feature, this defeats the whole purpose.
By separating the chains, we can prune the NXT chain so that the blockchain only stores the current state + last 1440 blocks. This is obviously much smaller than keeping the whole NXT blockchain as is. Probably by a factor of 1:100 perhaps 1:1000.

I mean, take a look at the current transactions on the NXT blockchains, block 653136, 3 message related to ATM operator and 1 asset bid, block 653134 message transaction by ATM operator. block 653133 message related to NXTPricer.
Do we really need to keep these transactions in the blockchain forever ?

All other blockchains including first and foremost Bitcoin, has this problem. We can solve it. This is a huge competitive advantage.

Thank you for explanation, now it is clear why this split is needed. Also, Blackyblack1 suggestion above seems good for thinking about.
Logged

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: Nxt 2.0 design
« Reply #358 on: February 14, 2016, 04:56:23 pm »

What about a system where NXT is burned to create fNXT? Has that been explored yet?
Logged
I head up content for BitScan, crypto business hub.

lurker10

  • Hero Member
  • *****
  • Karma: +168/-33
  • Offline Offline
  • Posts: 1334
    • View Profile
Re: Nxt 2.0 design
« Reply #359 on: February 14, 2016, 05:02:05 pm »

What about a system where NXT is burned to create fNXT? Has that been explored yet?

I like the idea. Get 1 NXT fused into 1 fNXT.

Someone will complain again and find reasons it's not fair or whatever.
Logged
Run a node - win a prize! "Lucky node" project jar: NXT-8F28-EDVE-LPPX-HY4E7
Pages: 1 ... 16 17 [18] 19 20 ... 51
 

elective-stereophonic
elective-stereophonic
assembly
assembly