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.12.1 Upgrade before block 2870000 is mandatory!

Pages: 1 2 [3] 4 5 6  All

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

petko

  • Full Member
  • ***
  • Karma: +24/-0
  • Offline Offline
  • Posts: 100
    • View Profile
    • My blog
Re: New fees and size limits in 1.7
« Reply #40 on: November 13, 2015, 06:56:46 pm »

We have discussed this before already. At the current transaction load, block size limit is not a factor that can influence the fees, unless we reduce it more than 10 times (and we do have two separate limits, both on transaction count and total transaction bytes size). Only when we get enough transaction traffic so that a significant percentage of the blocks are full, then a market rate fee can develop, by transaction senders willing to pay more in order to get their transaction included faster. With the current situation, if forgers can decide the fee it will gravitate towards zero, and expose the blockchain to spam. And we must think about the future, every MB of permanent data stored in the blockchain now is here to stay forever (the prunable side chains planned for 2.0 are not yet a reality and not guaranteed to be possible to implement). Migration to prunable data must be forced, leaving the permanent option only for those who really need it and are willing to pay the high fees for it.
We discussed this but I didn't fully understand your arguments and you didn't answer the last mail. So with the current algorithm we say "the network supports blocks with size MAX_PAYLOAD_LENGTH, but we are not going to waste space for transactions with fee below certain value". OK, makes sense.
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 #41 on: November 14, 2015, 12:54:10 pm »

We could remove the free allowance instead, but since prunable messages necessarily leave behind a 32 bytes permanent hash, charging the user for a permanent message of less than 32 bytes doesn't make sense as moving to prunable will not help for such short messages, it adds more overhead.
Would it make sense if we also change the charging for prunable attachments? In 1.5.1e that was "0.1 NXT per 1024 bytes, with the first 1024 bytes free (the regular transaction fee depending on its type still applies)". Is that still right, or did I miss a change log entry?

I am thinking along the lines of:
  • 1 NXT for payment with no attachment.
  • 5 NXT for payment with up to 32 bytes permanent attachment.
  • 5.1 NXT for payment with up to 1024 bytes prunable attachment.
  • Add 4 NXT for each further 32 bytes of permanent data.
  • Add 0.1 NXT for each further 1024 bytes of prunable data.
Or to put it another way, either 1 NXT, or 1 NXT + 4 NXT per 32 bytes of permanent data, or 5 NXT plus 0.1 NXT per 1024 bytes of prunable data. I think with a fee structure like this, the cheapest way to send data of a given type is always the way we'd prefer them to send it, without exploitable loopholes. The key is that the fee for prunable data includes the fee for 32 bytes of permanent data. We then have three variables to tune rather than one. For example we could set the base fee to 0.5 NXT, the permanent rate to 3 NXT, and the prunable rate at 0.1.

My goal is to allow simple transactions to be cheap, so that it is cheap to bid for assets, for example. I appreciate that some use cases, such as payment processors in Africa, really need cheap attachments too. I don't know what can be done about that.

Is this too complicated?
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 #42 on: November 14, 2015, 12:58:02 pm »

Low fees are killing forging economy and so just dangerous

It would not kill forging, cause it is already almost dead.
We currently have 43.4% of stake forging. Isn't that roughly what it's been for the last year or so? It's not ideal, but it's not dead, either. I guess it reflects a number of whales who don't forge because they want to protect their anonymity.
Logged

LocoMB

  • Hero Member
  • *****
  • Karma: +101/-37
  • Offline Offline
  • Posts: 751
    • View Profile
Re: New fees and size limits in 1.7
« Reply #43 on: November 14, 2015, 01:37:56 pm »

Apologies for not reading the whole thread.

I would like to float the following idea:

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 usage.

PoW is linked to electricity costs- this scheme would create a somehwat similar link too.
« Last Edit: November 14, 2015, 01:41:42 pm by LocoMB »
Logged
TOX
90E54E5B5213290EE616D425CADC473038CFABFA53C913271AA8559D1937DC4AF3A354A9E4E5

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1764
    • View Profile
Re: New fees and size limits in 1.7
« Reply #44 on: November 14, 2015, 02:01:18 pm »

Jean-Luc please consider increasing permanent size limit to 1000 bytes. I think people would prefer to pay extra fee than splitting the long message to 160 bytes.
Logged

NXT ENTERPRISE

  • Full Member
  • ***
  • Karma: +35/-14
  • Offline Offline
  • Posts: 194
    • View Profile
    • unanimously one
Re: New fees and size limits in 1.7
« Reply #45 on: November 14, 2015, 02:05:38 pm »

If it is an issue or argument on price costs - for me its not based in reality..

A cost of 1 - 10 nxt.... nothing.

But the scam complaint is that NXT went to a few.

People have an idea they can earn BTC by mining or earning.

So they feel like there is still a piece of the pie to earn into. not so with nxt.

Although BTC mining is not real anymore... on a small to medium scale.

So for me is it not an idea at these low prices to allow substantial NXT costs to allow an earning in forging.

All the tokens are created so shouldn't forging spread the wealth?

I would like to see more of a dispersion in forging success regardless of fee costs.

Whats 5 nxt in dollar terms today and even if nxt went to 10c a nxt?

Is it a good thing for NXT that more people are actively forging or it does not matter?

My chances of a success forge if holding under 5000,000 nxt make me not even bother.

Is a broad forging good for NXT or its not a factor?
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 #46 on: November 14, 2015, 04:09:01 pm »

NXT ENTERPRISE, I'm not sure what you're suggesting. Forging doesn't really redistribute wealth because it goes in proportion to how much wealth you already have. And however much you have, the return on investment is going to be insignificant compared to other things you could do with your savings, even if the fees increase 10-fold. The motivation to forge is to secure the network, not fees, and I expect it will stay that way until usage increases 100-fold.
Logged

NXT ENTERPRISE

  • Full Member
  • ***
  • Karma: +35/-14
  • Offline Offline
  • Posts: 194
    • View Profile
    • unanimously one
Re: New fees and size limits in 1.7
« Reply #47 on: November 14, 2015, 04:50:07 pm »

yes thanks for that explanation.

For BTC it is easy to say - power counts.

We need a clarification of forging..

How does average joe involve himself.

Why bother etc.

I think NXT has a PR point of confusion.

We need to clarify the small points to gain momentum for new comers.

Everything has a timing and I am confident with J-L as the core.

i do think he is playing chess with many moves ahead.

The latest talk of voting everything in is silly.

You cannot vote a bunch of non-understanding to a point of success.

But as forging is an algorithm.

How can it be easily understood?

Can forging remain as it is and a collection be made?

ex.. forge as is, collect 1500 nxt and then offer it random as a jackpot.

People love to gamble, like a curse.

once and a while some forger gets a 1500 jack pot.

easily explained the benefits now of forging...



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 #48 on: November 14, 2015, 06:41:53 pm »

Jean-Luc please consider increasing permanent size limit to 1000 bytes. I think people would prefer to pay extra fee than splitting the long message to 160 bytes.
What I want is people to migrate to prunable, instead of splitting a long message into several small, and the inconvenience of such splitting should be another reason to do that. Just high fee isn't enough though when you reach very high fees, for example if we have 5 NXT per 32 bytes a 1000 bytes message would cost 156 NXT. For such expensive transactions we should start worrying about forger's abuse, either a forger waiting for his turn and filling a block with his own messages, or setting up a reseller service to includes others' messages for cheaper. For other expensive transactions types, we counteract this by throttling and spreading back of transaction fees. But for messages, this doesn't work because messages can be attached to any transaction type. We cannot throttle all transactions, and if we spread back the fees for all transactions it really changes the economy of forging, I prefer not to do such drastic change.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

NXT ENTERPRISE

  • Full Member
  • ***
  • Karma: +35/-14
  • Offline Offline
  • Posts: 194
    • View Profile
    • unanimously one
Re: New fees and size limits in 1.7
« Reply #49 on: November 14, 2015, 06:52:53 pm »

yes very concise.

But not so much in layman's terms.

What is your priority?

NOT overloading a block

or allowing financial payments for consuming?

also can you define prunable -

so a short message will show a smaller fee and a longer message will charge more?

So a user can see and intemperate their coming expenses?

Can a forger start to see what a block is worth?



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 #50 on: November 14, 2015, 06:57:04 pm »

Would it make sense if we also change the charging for prunable attachments? In 1.5.1e that was "0.1 NXT per 1024 bytes, with the first 1024 bytes free (the regular transaction fee depending on its type still applies)". Is that still right, or did I miss a change log entry?
For now fee for prunable remains unchanged, 0.1 NXT per 1024 bytes. If we do set a base fee 2x the current 1 NXT and scale up all fees twice, it would make sense to be consistent and increase this also to 0.2 NXT, but this will still be cheap enough.
Quote
Or to put it another way, either 1 NXT, or 1 NXT + 4 NXT per 32 bytes of permanent data, or 5 NXT plus 0.1 NXT per 1024 bytes of prunable data. I think with a fee structure like this, the cheapest way to send data of a given type is always the way we'd prefer them to send it, without exploitable loopholes. The key is that the fee for prunable data includes the fee for 32 bytes of permanent data. We then have three variables to tune rather than one. For example we could set the base fee to 0.5 NXT, the permanent rate to 3 NXT, and the prunable rate at 0.1.
What you are suggesting is removing the free allowance completely, and charging for those first 32 bytes, even in the case of prunable messages. I prefer to leave the free allowance, it is useful in many cases. In particular, it is better if merchants or exchanges use a small message attachment, with the order number or user account number, to indicate the purpose of each payment, rather than creating a new one-time use account for each payment, such account creation is more expensive for us. If we start charging extra even for those first 32 bytes, we completely discourage such use.
Quote
My goal is to allow simple transactions to be cheap, so that it is cheap to bid for assets, for example. I appreciate that some use cases, such as payment processors in Africa, really need cheap attachments too. I don't know what can be done about that.
About the needs of such payment processors, there is just orders of magnitude difference between the fees they can afford and the Western standards, there is just no way to have a fee that is cheap enough for them, yet high enough both to prevent spam and to ensure some economic rewards for forgers, in the rest of the world. I think the conclusion was that we need the prunable side chains, before we can think of special low fees for those countries, and even then it is not clear how they would be protected from potential spam attacks coming from elsewhere.

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: New fees and size limits in 1.7
« Reply #51 on: November 14, 2015, 08:40:39 pm »

What you are suggesting is removing the free allowance completely, and charging for those first 32 bytes, even in the case of prunable messages. I prefer to leave the free allowance, it is useful in many cases. In particular, it is better if merchants or exchanges use a small message attachment, with the order number or user account number, to indicate the purpose of each payment, rather than creating a new one-time use account for each payment, such account creation is more expensive for us. If we start charging extra even for those first 32 bytes, we completely discourage such use.
OK, thanks.
Logged

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: New fees and size limits in 1.7
« Reply #52 on: November 14, 2015, 09:19:36 pm »

Quote

Messages and EncryptedMessages (non-prunable):
Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after the first 32 bytes. For encrypted messages, the length is measured excluding the nonce and the 16 byte AES initialization vector.

I'm posting this here and in the other threads so its on record...
A Maximum permanent message length of 160 will cause some MGW transactions to fail unless this MGW is changed or this length is increased, still figuring out the minimum needed to sustain MGW unchanged but 160 is definitely too low. This will also increase MGW transaction costs depending on the base fee - for those of you voting...
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

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 #53 on: November 14, 2015, 09:22:45 pm »

The MGW must switch to prunable. This is what prunable messages are for.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: New fees and size limits in 1.7
« Reply #54 on: November 14, 2015, 09:31:43 pm »

The MGW must switch to prunable. This is what prunable messages are for.
Fine BUT this means changing all the asset transfer code across all of the different MGW builds (they are not all on the same version as I understand it) and we are not talking about going back to 1k per AM but more likely to something like 180-200 chars so save them a huge amount of work.

MGW uses the blockchain as a ledger and does a full rescan when it boots so i needs all messages.
I know this can be done with nodes running the prunable service but its still significant coding work and testing for the MGW teams to switch MGW to create prunable messages as part of the asset transfers.
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

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 #55 on: November 14, 2015, 09:37:50 pm »

To use create a prunable instead of permanent message, the only change is to add messageIsPrunable=true parameter to the asset transfer (or any other) create transaction call.

It is intentional that in the transaction JSON, both permanent and prunable messages appear as the same "message" field (and this is one reason you can't have both at the same time), this is to make the switch to prunable easier as parsing the JSON attachment does not need to change.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: New fees and size limits in 1.7
« Reply #56 on: November 14, 2015, 09:46:12 pm »

I completely understand the change how this is implemented in the JSON and the lengths you have gone to ease the decoding of messages are clear to me in the API from using it myself.

What is needed to implement it is exactly what you have outlined but this means MGW itself going through a development lifecycle that currently isn't planned I suspect and it may be this call isn't isolated in one place but in several.

Forgive me I don't understand the material difference between every node storing 160byte messages forever and storing 180-200 byte messages forever. MOST MGW messages are less than 160 - its just *a few* are not.

Core-devs change the current proposal by a few bytes and another community team is saved a lot of work.

If the deadline for the switch is December - I suspect this will be challenging for the Supernet team because in this case based on what I saw in the MGW code a while ago this is a more difficult change than accommodating the 1.6.2 change
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

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 #57 on: November 14, 2015, 09:58:02 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.
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: New fees and size limits in 1.7
« Reply #58 on: November 14, 2015, 10:43:02 pm »

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?
Logged

chanc3r

  • Hero Member
  • *****
  • Karma: +124/-50
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
Re: New fees and size limits in 1.7
« Reply #59 on: November 14, 2015, 11:06:32 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.

J-L thanks for the suggestion, in any case I think it would make sense to bring in the new features on one fork and implement the more potentially disruptive change on another fork, will discuss timelines with the supermet team to make the change.

I understand, also, this change is needed to ensure the MGW TX remain cost effective as prunable will be cheaper than permanent anyway.
Logged
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect
Pages: 1 2 [3] 4 5 6  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly