/* edit
I moved this post into a new thread.
Check out the Gravity Wallet thread for details.
2 Likes
This is an excellent proposal. And once we have zBTC https://twitter.com/cryptocheshire/status/1733572567774941593?t=dNH0ZHKy-5IRlKifjZ4sSg&s=19 feeless btc transactions can be done as well. We can also position the wallet as an alternative to LN…
Agree with the points re: secondary markets for qsr and IBD. The main vonstraint here is to establish a market for native zts (rather than wrapped) which can be achieved with a CEX listing or our own dex.
The IBD challenge is quite high prio for some of our devs afaik
3 Likes
I want to map all actions (either active or passive) that will be performed on NoM Phase 1:
User
- Fuse
- Unfuse
- Generate (initial) PoW for Plasma
- ZTS token issuance
- Transfer ZTS without extra data
- Transfer ZTS with extra data
- Create AZ project
- Create AZ phase
- Vote for AZ project
- Vote for AZ phase
Delegator
- Delegate
- Undelegate
Staker
- Stake
- Unstake
Sentinel
- Deploy Sentinel
- Revoke Sentinel
Pillar
- Deploy Pillar
- Revoke Pillar
- Pillar change reward percentages
- Pillar change rewards address
- Pillar change producer address
Full node
- Relay transaction
- Initial blockchain download (IBD) sync
Miner
- PoW links creation (merge-mining CPU-friendly PoW)
- Merge-mining Bitcoin (merge-mining ASIC-friendly PoW)
Liquidity provider
- Stake LP token
- Unstake LP token
are these new actions? Looks like we have some today? Like:
- Stake
- Unstake
All actions combined (Phase 0 and Phase 1). We need those to be able to determine how current and future incentives/disincentives might work.
For example, we have a disincentive for revoking Pillars (QSR required for the Pillar slot are burned).
I’ve suggested we have a disincentive for unfusing QSR (burn) and undelegating ZNN (burn).
missing:
- Pillar change producer address
Added LP actions.
Thanks @coinselor for the missing Pillar action.
I know it’s unpopular, but here are the arguments:
- Unfusing disincentive is necessary to deter a spam attack on the QSR lane.
- Undelegating disincentive is necessary to deter delegate hopping. It is very similar to pool hopping that can be seen in the Bitcoin mining industry.
Currently delegators and Sentinels have no responsibilities. This must change in NoM Phase 1 if we want to transition to a self-sustainable network.
Would a QSR lockup period accomplish the desired outcome?
Would a minimum delegation period accomplish the desired outcome?
1 Like
Interesting fact about pool hopping, I was unaware of the concept.
Are you saying we can mathematically increase our delegation APR by algorithmically changing pillars currently as an exploit to how momentums are produced (not just hopping to highgest paying APR and accounting for weight increase)? Or do you envision this being a problem specifically when merge-mining shares are implemented?
QSR already has a predefined lockup period. This alone won’t deter spammer. What deters a rational participant is economic punishment.
We can build a gaussian function: maximum throughput can be achieved only after a certain amount of time has passed and not indefinitely after that. Unfusing having a cost will also deter rational attackers because they will need to refuse the QSR to get maximum throughput again.
This won’t prevent hopping, just delay it.
Yes. You can exploit the system right now if you have a proper script.
Delegators are not miners. But the concept is similar: they delegate stake to Pillars (proxy staking) in the same way miners are pointing hashpower to mining pools (proxy mining). The problem is that delegators are not expending physical resources in the same way miners do.
1 Like
I see what you mean.
It seems like when it comes to delegation hopping, frequency-of-hop is a key factor. Setting an undelegation assessment on a time curve would negate the benefit of hopping. The longer a person stays the delegated to one pillar, the less benefit they might gain by strategically hopping, right? If correct, the fee could be a percentage that reduces over time.
I don’t think we want to deter rational participation. We just want to ensure that the network can operate within the maximum defined parameters. With that, nobody needs to be punished.
Bitcoin has no punishment system in the protocol. The protocol has parameters which require the very same resources to cheat, as to use the network as intended. Simplicity and an economy of natural cost vs benefit.
Zenon security is based on value and incentive.
We want to deter spam and other types of attacks that harm the network.
Bitcoin has punishment in the physical world: your miner costs money and consumes electricity. If you are mining a fork, you waste resources.
2 Likes
Not at all, if you need further clarifications dm me.