I fear I have to close the voting again, before I am allowed to do changes in the proposal.
Edit: I am not able to edit the proposal anymore, even not when I’ve stopped the voting.
I fear I have to close the voting again, before I am allowed to do changes in the proposal.
Edit: I am not able to edit the proposal anymore, even not when I’ve stopped the voting.
I like this idea since the majority of the TX used on chain for active users will be smart contact which if I read correctly won’t change. The simple transfer of ZIL would rise but even if the price is $5 in the future that makes this cost $0.50 compared to 10x or more on Ethereum lately. Before I decide, does staking/unstaking/claiming rewards count as a smart contract? Because a I crease in that would be bad for a lot of our stakers, since the efficient time to accumulate rewardsto restake would go up
Yes, any interaction with the staking smart-contract, e.g. increase stake, decrease stake, claim rewards is a smart-contract interaction and is not effected by the proposal.
Then I think it’s a great idea, it’s a big step towards our burn rate, protection from spam TX, without increasing the cost to even a tenth of Ethereum gas average, even when Zil is scaled to a value of $5. I would be against further increases in the future, but this is manageable and it’s benefit outweighs the cost
I voted Against.
Agree need something done with regards to spam protection and thanks for submitting well thought out proposal
Reason against is that with Sushiswap pancakeswap. Joeblo swap. The transactions fees are going to be what wins us the volume war.
Raise transactions fees After we have clearly eclipsed competition.
And… my hope as others is that Zil price is going much higher which will naturally already impact said transaction fees
I was thinking the same thing. Do the leg work but postpone implementation until deemed necessary.
Swapping by any means is not effected by this proposal.
Only normal transactions - sending ZIL from address A to address B - is effected by this proposal.
A normal transaction would cost 0.1 ZIL.
With increasing adoption of Zilliqa, the gas price can be lowered and this would have effect on both, normal ZIL transactions and smart contract execution.
Thanks for clarification on that point.
Allows me to much further consider your proposal. Simple fix might be in congestive period focus on total value of transaction and give higher value transactions priority
Most scammers attempts will be lower $value transactions.
Where would these higher fees then be distributed? Gzil holders?
At Zilliqa fees are burned, which is beneficial for all $ZIL holders, as it decreases inflation rate.
Your suggestion to prioritize high-valued transactions might also be an attempt, but probably much harder to implement, escpicially when it comes to smart contract transaction you would probably need some kind of oracle to tell you which is the value of a smart contract interaction.
Thank you ! You have gained my support when this moves to formal voting.
Your thorough knowledge of mechanics is appreciated
I think this is something to consider but not yet. Are we trying to solve a problem that doesn’t exist yet? As the price of Zil increases will this not be a deterrent to network spamming? At this time I think it’s important to keep the fees low and equitable for everyone. Low fees should be viewed as an incentive to use the Zil network over other chains. Now is not the time for higher network fees. We should be focusing on network growth and adoption imho.
Security issues are always best countered proactively, especially if that can be done on a protocol level as everything build on top is inherently more robust and protected. Since this only affects simple transactions, and also combats inflation, I see very little downside to this proposal beyond the logistics of implementing the change. I’m all for it.
I agree with you. There are people who are new to the crypto space. We must give them some more time to get accustomed to it. I don’t know much about spamming but do they have so much time for that unnecessary transfer. Cut them some slack let them evolve. No one has extra time to do unnecessary transfer perpetually.
Having said that instead of 50 times raise the fee by 5 times for next 3 months. Then based on the analysis and feedback decide future action. My $0.02!!
Research dusting attacks. Zilliqa is quickly growing, and because of that, more and more resources will inevitably be poured into discovering vectors of attack to the network and its users. The simple transaction fee if this implemented is still negligible compared to other comparable chains, that it does not present a hurdle towards adoption imo.
The network spamming you mention was only a stress test done by Zilgraph. It had no impact on the network as it remained stable, and I believe it shows the blockchain’s resiliency.
We should welcome this sort of community testing in this still early era of adoption for the chain.
I think those changes can be incorporated into the proposal if it goes onto the next stage
Bitcoin can use multiple inputs when sending, ZIL uses a single input. Would a dust transaction actually cause any of the same unspendable issues like Bitcoin? We don’t yet have comments so spam here is actually not very useful in a spam sense. Now if I make a token with a spam message and send it to you I can actually send spam.
No it would not function like a traditional dusting attack only using single inputs. That’s good you brought that up since I really wasn’t considering the network differences, however I was more or less just trying to provide an example of a type of attack that would have less resistance to implement by having the ability to cheaply spam transactions, however that would look like on the Zilliqa chain.
I agree with the idea of increasing fees for Zil transfers, however, not fully convinced with an increase of 50 times, especially if value of 1 zil increases. Maybe some kind of visualization comparing different numbers could be useful to justify. On the contrary, some low fees for transfer might actually attract users/devs and allow regular stress testing of the network