Closed ghost closed 6 years ago
Max has announced that the fees are adjusted periodically, the first time at Mainnet launch. I think, this is better than some kind of automatic adjustment, the fees should be quasistatic.
Didn't know about that, but adjusted by who? If manually by dev team, it's not good solution, and anyway transactions fees should by chosen dynamically.
My understanding in a PoS environment, this could be voted on by the community. Number of delegates, number of votes, etc could also be voted on. Personally I would like to see it dynamic and not hard coded.
This is a difficult task for dynamic fees. The main reason is "This is difficult to find an indicator related to real price of a lisk". For PoW, the hashrate is a good indicator of the Bitcoin price. In DPoS (or PoS), since there is no dynamic forging expense, dynamic price algorithm is likely not sensible.
The only strategy so far is to perform regular updates in the minimum fees.
Note that high transaction fees can be seen as a countermeasure to prevent from too much speculation on the LSK price.
According to "countermeasure to prevent from too much speculation on the LSK price" I think that's bad, very bad. Higher price of Lisk tokens creates better funding for Lisk team. As far i remember @MaxKK keep some of Lsk for future development, is that correct? Price fluctuations have much more pros than cons. For instance price fluctuations bring tons of tons of new people by bringing attention to speculative capital, which also can bring press attention. Fluctuations will decrease in time as capitalisation grows. I see some possibilities on that, one is to relay on current stable one fiat currencies or even better gold and sliver by centralised source from Lisk servers as a temporary solution, which i think is still better than updating constant value in each update (which is also centralised). The final solution in my opinion might be a neural network which will learn and adapt accurate prices based on multiple factors like for example current daily volume traded via Lisk blockchain, just an example - it should be deeply investigated to chose all and the best factors, i think it's more than possible with neural networks, something similar should be done with fixed number of delegates and all fixed hardcoded values. Then Lisk will be more then revolutionary. This is thing i was thinking few months ago during seeing bitcoin being overtaken, decentralised blockchain platform with built in neural network which considers important variables and direction of development for it's own good and primary assumptions. In that case it can prevent centralisation issues with fixed number of delegates or problem with fixed price of features in lisk. Currently many people complains about fees.
I agree we can't please everybody. But we don't want to deal only with traders adoption. There is no perfect solution.
The solution you outline with NN is not consensus based. I belive we should see how DPoS works in the current state before taking action. If there is no bug, don't fix it. We have many more serious issues to fix before.
As for algorithm i would more try to work on a percentage (like 0.01%) of medium transactions.
For instance if over last 100 rounds, average transaction is 100 Lisk, fees would be 0.01 LISK
Not sure what to do with is @MaxKK . My opinion is that is this beyond the reach of lisk core dev. Label as "won't fix"?
We will definitely enhance and change the fee model. It's an important part of the whole platform.
As a potential dapp developer most likely targeting customers who don't already hold Lisk - stability in transaction fee pricing would be second only in importance to affordability from my perspective. I'm not sure which would be worst, me having to wear a huge price increase (relative to the major fiat currencies) for some days / weeks / months because Lisk suddenly increased in value or me having to tell my customers that the $x cost of a transaction they made 4 weeks ago is now $x * 7. Particularly when there has been no increase in the underlying costs of delivering said service.
I'm glad a change to the current fixed-Lisk system is being entertained.
@proehlen As a potential blockchain app developer next year on Lisk you will not have to worry so much. Within the sidechain you will be able to define the costs for transactions yourself.
@MaxKK That certainly helps. I guess its the cost of entry to the side-chain is what's at stake. Doesn't matter so much for high value, low volume transactions but has a huge impact on the inverse them. If Lisk was the postal service and in order to use my service you had to send a letter, you'd balk if the cost of a postage stamp was 50 cents one month and $3 the next. Anyway, appreciate you taking the time to reply.
@proehlen Exactly. Dynamic fees are a must-have so that they can be adjusted to the network load. Thanks to DPoS we are quite scalable. So the issue of high transaction fees is not that pressing after Lisk 1.0.0 like with other blockchain techs, especially because a big chunk of volume can be off-loaded into sidechains.
However, you are right and we will have to find a solution for it. First things first.
With Lisk price now hitting and for some time, passing $10 per token, it is already becoming expensive to transfer Lisk. If a user buys Lisk on exchange, it cost them almost $1 to send to their wallet, making Lisk more expensive to transfer than most tokens, except for BTC. This cost becomes really prohibitive as the price of Lisk continues to rise.
$10 was a month ago. It was $30 yesterday. Is the transaction fee still at 0.1 LSK? When I asked a client to look at LSK, they balked at the transaction fees, which is much higher than what they pay currently with fiat + 20th-century payment processors.
It will be solved.
Dynamic fees are on our roadmap. The issue will be revisited in Lisk 2.0.0 version. Closing for now. Thanks for your input.
Normally, tickets aren't closed when the issue is put on a roadmap, tickets are closed when the issue is fixed.
Currently in LISK we have static fees for delegate, dapp registration, sending tx etc.. It would be great to chose this value dynamically depending on some factors, price may go up in future and using LISK may become too expensive with particular functionalities.