elective-stereophonic
elective-stereophonic
New fees and size limits in 1.7
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.11.15 | Latest Experimental Nxt Client: Nxt 1.12.0e

Pages: 1 2 3 [4] 5 6  All

Author Topic: New fees and size limits in 1.7  (Read 20777 times)

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: New fees and size limits in 1.7
« Reply #60 on: November 14, 2015, 11:54:05 pm »

The deadline is not Dec 1st, the hard fork will take place probably early January. Furthermore, if it is a matter of a few more weeks only, we can encode two different hard fork blocks in the same release, so that shuffling and other new features for example get enabled on Jan 5th, the fee increase and size limit changes take effect on Jan 15th.

It is not the difference between 160 and 200 bytes, it is the difference between 200 and 32 bytes. I want the MGW team to make the switch to prunable, even if it means extra work, and even possibly doing a two stage hard fork as described above.

Ever since the prunable feature was released in April, I have repeatedly stated that projects like MGW should migrate to it, yet they kept ignoring this. I have no doubt that if we let them use 200 bytes permanent AMs, MGW will plan to use permanent forever, and to save themselves a few weeks of work (and grepping through the code to add a parameter, even if in many places, doesn't take weeks), they will not care if this causes blockchain bloat for everyone else using the platform. Tragedy of the commons.
MGW uses the blockchain as its permanent record of deposits and withdraws. My understanding is that using prunable transactions means it disappears after 2 weeks.

How would you suggest to correlate the transactions made if the data is pruned away?

So it is not a matter of changing API calls. By using the blockchain, the user transactions are there, regardless of what happens to the servers. MGW recalculates balances by scanning the blockchain for all transactions, you know, like a blockchain.

I am confused why you keep advocating MGW use prunable data. Where should I store the user transactions info. These are part of the deposit/withdraws so there is no chance of them being separated and lost. Once we start storing the user transaction data in any other place than the actual transaction, then it loses the blockchain aspect it has.

Any fee increase will need to be passed on to end users as MGW fees are not covering costs as it is.

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: New fees and size limits in 1.7
« Reply #61 on: November 15, 2015, 12:08:14 am »

Core-devs change the current proposal by a few bytes and another community team is saved a lot of work.
But you'll have to do that work eventually anyway, right? 200 bytes even at 1 NXT per 32 bytes is 7 NXT, and if you switch to prunable data it would cost only 1 NXT. However the vote goes, it will cost 1/7th as much to change. Surely SuperNet would prefer the cheaper option? Or do you not really care, because you pass the costs onto your users?

That said, I would be interested in the rationale for the limit being 160 bytes, rather than, say, 128. Is there some specific use-case it is catering to? Is it the average transaction size (without attachments) - I gather that's usually between 150 and 200 bytes?
Prunable storage of people's deposit/withdraw info?

That will open up a lot of new edge cases. I certainly dont want to rely on public servers keeping permanent copies of all such info and there is no guarantee that there would be any such servers with a permanent record

so the data needs to be in the permanent data. I keep saying this over and over

permanent data and it is part of the asset transfers, so there is no chance of them getting lost.

I certainly dont have a month (yes, debugging MGW is very timeconsuming) to code and debug an MGW that uses prunable messages (using remote servers, setting up some internal servers as archive nodes, testing remote retrieval, etc). Even if I had the time, this prunable design would degrade MGW reliability by making it a LOT more complicated than now. Plus it would depend on public servers for proper operations

The only practical solution i see if txfees go up is to increase the MGW fee, that is not a problem for me to do. I will just charge 10NXT txfee for each MGW tx, which would cover the worst case costs and a bit extra

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

xiahui135

  • Full Member
  • ***
  • Karma: +15/-11
  • Offline Offline
  • Posts: 150
    • View Profile
Re: New fees and size limits in 1.7
« Reply #62 on: November 15, 2015, 03:52:50 am »

why not make the base fee changeable in the block-chain?
If nxt price go more than 10x higher, the fee is too high. We should prepare for the high price, not to limit the price to go high.

Before, the price is main determined by speculation when people just buy in a centralized exchange. Specutors do not care much about the transation fee, because it will not affect them much.
But we aim to make the price determined by application in future, if nxt will to success. Given this, we need to encourage usage of the our block chain, and lower fee make sense. the fee structure should be low enough, just to prevent abuse.
Logged

LocoMB

  • Hero Member
  • *****
  • Karma: +101/-37
  • Offline Offline
  • Posts: 751
    • View Profile
Re: New fees and size limits in 1.7
« Reply #63 on: November 15, 2015, 05:47:03 am »

why not make the base fee changeable in the block-chain?
If nxt price go more than 10x higher, the fee is too high. We should prepare for the high price, not to limit the price to go high.

Before, the price is main determined by speculation when people just buy in a centralized exchange. Specutors do not care much about the transation fee, because it will not affect them much.
But we aim to make the price determined by application in future, if nxt will to success. Given this, we need to encourage usage of the our block chain, and lower fee make sense. the fee structure should be low enough, just to prevent abuse.

That is what I am worried about too! When volatility occurs, it changes the whole fee structure, and can seriously impede services that rely on a certain calculations!

How about this:
Pegging a base fee like a message or sendMoney TX to an average basket of some real world utility, for example 50th of a surface mail letter.
Such a physical utility fee is under physical cost constraints, because the letter has to be physically handled and expedited, and that is always related to resource and time usage.
PoW is linked to electricity costs- this scheme would create a somehwat similar link too.
As in this discussion the term 'utility value' keeps popping up, why not take it to the logical step and tie the base TX cost to a physical utility?

There is a nice example for an immutable indicator like this: The Baltic Dry Index (BDI)

This is the only index that cannot be manipulated, and there exist no futures and other leveraged instruments for this, hence the BDI is the best gauge for world trade.
Surface mail letter costs are similar immutable costs of transporting information stored on a physical medium, but it could also be any similar utility used as gauge.
« Last Edit: November 15, 2015, 05:53:18 am by LocoMB »
Logged
TOX
90E54E5B5213290EE616D425CADC473038CFABFA53C913271AA8559D1937DC4AF3A354A9E4E5

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: New fees and size limits in 1.7
« Reply #64 on: November 15, 2015, 06:06:57 am »

why not make the base fee changeable in the block-chain?
If nxt price go more than 10x higher, the fee is too high. We should prepare for the high price, not to limit the price to go high.
It has been said several times that if the price goes significantly higher, we will do another poll and change the fee, just like we are doing now. Price was already 10x higher once, with the same fee, and it was not a problem. We do hard forks about every 6 months, if the price starts going solidly up we do have time to react, and in the worst case of very sudden price increase we will do another hard fork just to adjust the fees sooner.

Historically, NXT has been less volatile than other cryptocurrencies.
 
Quote
How about this:
Pegging a base fee like a message or sendMoney TX to an average basket of some real world utility, for example 50th of a surface mail letter.
Such a physical utility fee is under physical cost constraints, because the letter has to be physically handled and expedited, and that is always related to resource and time usage.
PoW is linked to electricity costs- this scheme would create a somehwat similar link too.
As in this discussion the term 'utility value' keeps popping up, why not take it to the logical step and tie the base TX cost to a physical utility?

There is a nice example for an immutable indicator like this: The Baltic Dry Index (BDI)

This is the only index that cannot be manipulated, and there exist no futures and other leveraged instruments for this, hence the BDI is the best gauge for world trade.
Surface mail letter costs are similar immutable costs of transporting information stored on a physical medium, but it could also be any similar utility used as gauge.
How do you get the blockchain to read such an external index in a safe and trustless manner? How long will it take to implement and make sure it is secure? Is the complication and the risk of doing that automatically really worth it? This is a topic for a separate discussion, now we need to decide about the changes to take effect in 1.7, given the tools (voting) and software features we already have.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: New fees and size limits in 1.7
« Reply #65 on: November 15, 2015, 06:33:26 am »

Prunable storage of people's deposit/withdraw info?
Yes, of course! This data is not needed for the blockchain to function, only your software needs it, therefore your software must take care of preserving it. And this has been made exceedingly easy for you, because you only need to change a few nxt.properties in the config file of your servers (servers you control, not public ones) to have them keep this prunable data forever for you, without forcing everyone else to also keep it forever.

Quote
That will open up a lot of new edge cases. I certainly dont want to rely on public servers keeping permanent copies of all such info and there is no guarantee that there would be any such servers with a permanent record
No it will not. And I said, you should run your own servers that you control. The public servers are for a backup - and you already rely on them to serve you the blockchain, right?

Quote
so the data needs to be in the permanent data. I keep saying this over and over

permanent data and it is part of the asset transfers, so there is no chance of them getting lost.
Such statements only show that you have no clue about what prunable data is.

Quote
I certainly dont have a month (yes, debugging MGW is very timeconsuming)
Yeah, a common sign of badly designed code.

Quote
to code and debug an MGW that uses prunable messages (using remote servers, setting up some internal servers as archive nodes, testing remote retrieval, etc). Even if I had the time, this prunable design would degrade MGW reliability by making it a LOT more complicated than now. Plus it would depend on public servers for proper operations
It has been explained to you that you can and should run your own servers, set to store prunable data forever, and as long as your servers don't all go down for more than two weeks at a time you never need to use public servers, and if your servers do all go down for more than two weeks, only then they will need to retrieve the expired prunable data from such public archival nodes. And this retrieval process has been all implemented and tested by the Nxt core developers, who have spent months on that so that projects like yours can afford to be unreliable, have weeks of downtime and keep no backups, yet still be able to restore their data from public archival nodes when needed.

Quote
The only practical solution i see if txfees go up is to increase the MGW fee, that is not a problem for me to do. I will just charge 10NXT txfee for each MGW tx, which would cover the worst case costs and a bit extra
You don't care about adding bloat to the Nxt blockchain, and now you confirm you don't care about your users either.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: New fees and size limits in 1.7
« Reply #66 on: November 15, 2015, 06:46:25 am »

MGW uses the blockchain as its permanent record of deposits and withdraws. My understanding is that using prunable transactions means it disappears after 2 weeks.

How would you suggest to correlate the transactions made if the data is pruned away?
By setting nxt.maxPrunableLifetime=-1 and nxt.includeExpiredPrunable=true, your servers will keep prunable data forever, and serve it on request. At this point it becomes indistinguishable from permanent.

Quote
MGW recalculates balances by scanning the blockchain for all transactions, you know, like a blockchain.
No, it is using the blockchain as a database for storing arbitrary data. And this is not what the blockchain is designed for. The blockchain is a tool for achieving decentralized consensus, maintaining decentralized ledger, and distributing data between peers in a trustless and verifiable manner. Once such arbitrary data has been distributed, any part of it that is not required by the blockchain itself (i.e. by new peers to be able to recreate the blockchain state and reach consensus with others in a trustless way), does not need to be kept by all peers. Software that needs such data should keep it itself in its own database, or disable pruning locally to continue keeping it in the same database as the Nxt blockchain.

Quote
I am confused why you keep advocating MGW use prunable data. Where should I store the user transactions info. These are part of the deposit/withdraws so there is no chance of them being separated and lost. Once we start storing the user transaction data in any other place than the actual transaction, then it loses the blockchain aspect it has.
Already explained. Disable pruning locally, and the data will never be lost. If your servers all crash or are destroyed at once, such data is still retrievable from public archival nodes. Run a few archival nodes yourself in separate locations, or find a way to motivate people to run them by paying them with some asset.

For light clients, have them verify that the public node they connect to provides the prunable service, i.e. stores expired prunable data indefinitely. I think it already became clear that light clients must check version and other properties of public nodes they rely on.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: New fees and size limits in 1.7
« Reply #67 on: November 15, 2015, 07:04:37 am »

Prunable storage of people's deposit/withdraw info?
Yes, of course! This data is not needed for the blockchain to function, only your software needs it, therefore your software must take care of preserving it. And this has been made exceedingly easy for you, because you only need to change a few nxt.properties in the config file of your servers (servers you control, not public ones) to have them keep this prunable data forever for you, without forcing everyone else to also keep it forever.

Quote
That will open up a lot of new edge cases. I certainly dont want to rely on public servers keeping permanent copies of all such info and there is no guarantee that there would be any such servers with a permanent record
No it will not. And I said, you should run your own servers that you control. The public servers are for a backup - and you already rely on them to serve you the blockchain, right?

Quote
so the data needs to be in the permanent data. I keep saying this over and over

permanent data and it is part of the asset transfers, so there is no chance of them getting lost.
Such statements only show that you have no clue about what prunable data is.

Quote
I certainly dont have a month (yes, debugging MGW is very timeconsuming)
Yeah, a common sign of badly designed code.

Quote
to code and debug an MGW that uses prunable messages (using remote servers, setting up some internal servers as archive nodes, testing remote retrieval, etc). Even if I had the time, this prunable design would degrade MGW reliability by making it a LOT more complicated than now. Plus it would depend on public servers for proper operations
It has been explained to you that you can and should run your own servers, set to store prunable data forever, and as long as your servers don't all go down for more than two weeks at a time you never need to use public servers, and if your servers do all go down for more than two weeks, only then they will need to retrieve the expired prunable data from such public archival nodes. And this retrieval process has been all implemented and tested by the Nxt core developers, who have spent months on that so that projects like yours can afford to be unreliable, have weeks of downtime and keep no backups, yet still be able to restore their data from public archival nodes when needed.

Quote
The only practical solution i see if txfees go up is to increase the MGW fee, that is not a problem for me to do. I will just charge 10NXT txfee for each MGW tx, which would cover the worst case costs and a bit extra
You don't care about adding bloat to the Nxt blockchain, and now you confirm you don't care about your users either.
Why are you making personal attacks on me? I think that is uncalled for.

BTC blockchain is quite large and each test requires to restart MGW, which scans the BTC data. That takes quite a bit of time. Since you are much better at creating well designed software than me, please tell me how I can make this go faster.

Since all MGW servers are running in datacenters, I dont really have control over them. Which means the user's mgw tx data is not protected by the decentralized NXT network.

MGW does not use public nodes.

And if to use public nodes, I would think there needs to be some contingency to deal with not being able to find the data. THAT is why I do not feel MGW using prunable data is wise. There are much fewer copies of the pruned data, since it is pruned. So a lot higher chance that it cant be found, to the point where I need to specifically deal with such cases.

Unless you are advocating that I just trust that there will always be public nodes available with a complete and accurate archive.

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: New fees and size limits in 1.7
« Reply #68 on: November 15, 2015, 09:50:32 am »

The public availability of an unabridged blockchain as we move to this new fees and limits model is a conversation that is driven by MGW / SuperNET now and I posted similar points in the 1.7 changelog thread.

We might not see other businesses talking about this yet and we should respect the utility that SuperNET has tried to drive into the NXT blockchain and hopefully many others will follow. If this happens then more people will consider and question the integrity of their ability to get a full blockchain copy.

The whole point of a blockchain based system is not to rely on data centre backups and shipping blockchain copies from one data centre to another using traditional methods.

If a prunable NXT is to succeed then a NXT business will need to be confident that it will always be able to access an unabridged copy of the blockchain and if the principles of decentralisation are to be maintained this cannot be solely the obligation of that business.

One of the things that it would be useful to be able to monitor is the health or contactable number of peers making the unabridged blockchain available, I guess a bit like the old torrent stuff, there may be lots of people who a sharing parts of the torrent but there are sometimes only a few sharing the complete torrent...

btw its not going to help if this descends into criticism / claims of how or why things are the way they are.
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

cryptoscout

  • Hero Member
  • *****
  • Karma: +100/-96
  • Offline Offline
  • Posts: 635
    • View Profile
Re: New fees and size limits in 1.7
« Reply #69 on: November 15, 2015, 10:45:07 am »

Guys,

I've reading this for the past days, BUT?

Nobody has actually asked the real reason why the fee should be flexible, Secondly have you actually asked what projects and business really need?

Personally, why don't you approach different models and see what they are paying and what they could pay and take this from a commercial view opposed to just a technical view.

I have my own views on this for the mobile banking, Digital Identity and reward programs as my view is every transaction of hash needs to be on the blockchain.
Logged

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: New fees and size limits in 1.7
« Reply #70 on: November 15, 2015, 10:51:17 am »

BTC blockchain is quite large and each test requires to restart MGW, which scans the BTC data. That takes quite a bit of time. Since you are much better at creating well designed software than me, please tell me how I can make this go faster.
Why can't you cache the state of the blockchain at some height, and then reload from that cache when you are debugging? A production restart would scan the entire blockchain as usual; this would just be a time-saver when testing. As a programmer myself, I know it's painful to have a long edit-compile-test cycle, and it is worth building extra infrastructure just to make it faster for debugging.

Quote
And if to use public nodes, I would think there needs to be some contingency to deal with not being able to find the data.
The suggestion is that you use private NRS nodes that you control.

(Although, if you made them public, that would help other companies that need archived data by providing some redundancy. Hopefully they will do the same. This needs to be bootstrapped.)

The whole point of a blockchain based system is not to rely on data centre backups and shipping blockchain copies from one data centre to another using traditional methods.
Once you have the archiving NRS nodes, you wouldn't need to be shipping blockchain copies using traditional methods. NRS does that itself. And, unlike a centralised data centre, it would be trust-free, because the Nxt block-chain stores hashes that ensure the nodes that store the archive don't change history.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: New fees and size limits in 1.7
« Reply #71 on: November 15, 2015, 10:58:04 am »

have you actually asked what projects and business really need?

Personally, why don't you approach different models and see what they are paying and what they could pay and take this from a commercial view opposed to just a technical view.
Businesses want zero fees, isn't that obvious? Would you expect any business to say they want to pay a fee?

For those who think our fees are high enough to prevent spam, just look at the most recent blockchain transactions right now.

Quote
I have my own views on this for the mobile banking, Digital Identity and reward programs as my view is every transaction of hash needs to be on the blockchain.
This is nonsense. Only what the blockchain needs should be stored permanently on the blockchain. You can use the blockchain to verify the hashes of your data, that was at some point processed through it, but storing the actual data forever is not what the Nxt blockchain is designed for. Do it yourself, setup an archival node, pay someone to run an archival node for you, or use a coin that is specifically designed to provide distributed storage (sia, storj, maidsafe, etc).
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

EvilDave

  • Hero Member
  • *****
  • Karma: +341/-40
  • Offline Offline
  • Posts: 1789
    • View Profile
    • NXT Foundation
Re: New fees and size limits in 1.7
« Reply #72 on: November 15, 2015, 11:41:05 am »

Maybe it's time to simply acknowledge that there will be a need for Nxt archival nodes, and to start off a seperate discussion exploring how best to maintain (or encourage people to maintain) these archival nodes.
Logged
Nulli Dei, nulli Reges, solum NXT
NXT Donations: NXT-BNZB-9V8M-XRPW-3S3WD
We will ride eternal, shiny and chrome!

Damelon

  • Hero Member
  • *****
  • Karma: +792/-54
  • Offline Offline
  • Posts: 2314
    • View Profile
    • Nxt Inside
Re: New fees and size limits in 1.7
« Reply #73 on: November 15, 2015, 11:48:48 am »

have you actually asked what projects and business really need?

Personally, why don't you approach different models and see what they are paying and what they could pay and take this from a commercial view opposed to just a technical view.
Businesses want zero fees, isn't that obvious? Would you expect any business to say they want to pay a fee?

For those who think our fees are high enough to prevent spam, just look at the most recent blockchain transactions right now.

This is not completely true.

Business don't like fees is probably a more accurate statement, especially fees they don't see a use for.
Businesses do not mind fees that come with a benefit, and where it's clear that they get value for them.

I would not mind at all to pay fees that enable the party getting them to make sure my business benefits from them.

This is one of the core reasons sales and marketing exists: to explain how costs relate to services. If that translates into a fair deal, no business worth its salt will actually mind.
Logged
Member of the Nxt Foundation | Donations: NXT-D6K7-MLY6-98FM-FLL5T
Join Nxt Slack! https://nxtchat.herokuapp.com/
Founder of Blockchain Workspace | Personal Site & Blog

cc001

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 829
    • View Profile
Re: New fees and size limits in 1.7
« Reply #74 on: November 15, 2015, 11:50:19 am »

Maybe it's time to simply acknowledge that there will be a need for Nxt archival nodes, and to start off a seperate discussion exploring how best to maintain (or encourage people to maintain) these archival nodes.

would it be possible to create a new/separate business branch on top of maintaining archival nodes? Similar to forgers or miners, you could earn some fees (or other kind of income) if you maintain such archival nodes?
Logged
cc001 Personal - NXT-8RXS-2SSK-RNF2-HSNL8
NxtReporting.com - The Nxt Asset Exchange Portfolio Manager with Profitability Tracking - Donations are greatly appreciated on NXT-5W4G-GAR6-JHJP-H8ZTW

Seccour

  • Sr. Member
  • ****
  • Karma: +68/-15
  • Offline Offline
  • Posts: 380
    • View Profile
Re: New fees and size limits in 1.7
« Reply #75 on: November 15, 2015, 12:22:53 pm »

Maybe it's time to simply acknowledge that there will be a need for Nxt archival nodes, and to start off a seperate discussion exploring how best to maintain (or encourage people to maintain) these archival nodes.

would it be possible to create a new/separate business branch on top of maintaining archival nodes? Similar to forgers or miners, you could earn some fees (or other kind of income) if you maintain such archival nodes?

Yeah but from where the income will come from ? And how we will know if the node realy archive everything ?
Logged
SecFund : 9125535795764729261 (Asset ID)

allwelder

  • Hero Member
  • *****
  • Karma: +196/-13
  • Offline Offline
  • Posts: 1867
  • NxtChina.org
    • View Profile
    • NxtChina.org
Re: New fees and size limits in 1.7
« Reply #76 on: November 15, 2015, 12:26:37 pm »

Low fees are killing forging economy and so just dangerous
But high fees may killing user base.
What we need is more fees with more users and more transactions,but not increasing fees of single transaction by decreasing users or transactions,right?
Logged
NxtChina |Weibo |Twitter Donation welcomed:NXT-APL9-66GU-K8LY-B3JJJ

cryptoscout

  • Hero Member
  • *****
  • Karma: +100/-96
  • Offline Offline
  • Posts: 635
    • View Profile
Re: New fees and size limits in 1.7
« Reply #77 on: November 15, 2015, 12:43:03 pm »

have you actually asked what projects and business really need?

Personally, why don't you approach different models and see what they are paying and what they could pay and take this from a commercial view opposed to just a technical view.
Businesses want zero fees, isn't that obvious? Would you expect any business to say they want to pay a fee?

For those who think our fees are high enough to prevent spam, just look at the most recent blockchain transactions right now.

Quote
I have my own views on this for the mobile banking, Digital Identity and reward programs as my view is every transaction of hash needs to be on the blockchain.
This is nonsense. Only what the blockchain needs should be stored permanently on the blockchain. You can use the blockchain to verify the hashes of your data, that was at some point processed through it, but storing the actual data forever is not what the Nxt blockchain is designed for. Do it yourself, setup an archival node, pay someone to run an archival node for you, or use a coin that is specifically designed to provide distributed storage (sia, storj, maidsafe, etc).


1st of all you don't need to store forever hence why Pruning is great some items may need to be stored 6 months to 7 years.

Secondly people don't want to pay fees but still have to in the real world and those doing a crypto business end up paying more then existing.

Companies that pay 2.50$ to 7.50$ fees would handsomely pay 25 to 75 cents fee if you can provide the same services or function.

So you say what you think and I will say what I think, it will never match but if you can find the middle then you have the solution to the Fees and capability, IE low to higher for Certain functions.

AE makes a lot of transaction that could be set to a % not fixed
MS could be set to flat fee of 0.1 to 0.5 NXT to make it more compelling to use.
Messaging with different variants of Capacity at different fee levels.
Voting a high fee to create the campaign and something low like 0.01 NXT as right now the voting system is more costly than existing systems ( you will say now it bloats the chain what if the voting is prunable upto 6 months later)

I could go on with loads of ways to commercialize NXT to be compelling  based on its functions
Logged

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: New fees and size limits in 1.7
« Reply #78 on: November 15, 2015, 01:28:42 pm »

No one is disagreeing that different value transactions have different fee's
This is already in the change log
These primary transactions and their parameters are NOT PRUNED...

People are voting for the base fee not all fees

The debate is around the use of AMs and storage of them.
The change is that the DEFAULT ubiquitous availability of  permanent additional transaction information stored in messages is reduced from 1000 (currently) to 160 bytes.
 
Whilst I might debate the 160bytes being too low with J-L I do agree that...
NXT is not a storage blockchain - it can't be because people providing the storage receive NO fees
Even the chains that exist to provide storage do not put the storage in the chain itself.

The mistake is to have started NXT with a 1K block for an AM and not a 64byte block - at least then increasing it could not break anything. Although people would be complaining about bloat due to the increased message size probably.

Pruning creates simply 2 views of the chain, a full view and an abridged view.. If you don't change with your config you will get and share the abridged view. users that need the full view need to configure and share the full view of the chain.

The issue of data availability only arises if there is no peer on the network you can reach which has an unabridged copy of the chain. If there are plenty of businesses / power users / community members out there who run with the settings outlined by J-L then this problem should never arise.

Applications that create permanent messages longer than 160 bytes need to adapt to create prunable messages, a simply parameter.

Applications that simply READ messages need NO Changes the copy of NXT that they access just needs to be configured to download and share an unpruned copy of the blockchain.
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

EvilDave

  • Hero Member
  • *****
  • Karma: +341/-40
  • Offline Offline
  • Posts: 1789
    • View Profile
    • NXT Foundation
Re: New fees and size limits in 1.7
« Reply #79 on: November 15, 2015, 02:05:55 pm »

Maybe it's time to simply acknowledge that there will be a need for Nxt archival nodes, and to start off a seperate discussion exploring how best to maintain (or encourage people to maintain) these archival nodes.

would it be possible to create a new/separate business branch on top of maintaining archival nodes? Similar to forgers or miners, you could earn some fees (or other kind of income) if you maintain such archival nodes?

Yeah but from where the income will come from ? And how we will know if the node really archive everything ?

That's the stuff that needs to be decided, guys.

@jl777 and Jean-Luc: do you two agree (  ;D ) on the need for archival nodes ?
If so, we can start making plans to support and maintain these nodes.

I'm happy to commit right now, personally, to running an archival node, in any case.
Logged
Nulli Dei, nulli Reges, solum NXT
NXT Donations: NXT-BNZB-9V8M-XRPW-3S3WD
We will ride eternal, shiny and chrome!
Pages: 1 2 3 [4] 5 6  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly