cuevasm
commented
7 months ago Housekeeping: You reference Methods 1, 2, and 3 here but do not summarize them, will be easier for others to follow this conversation if you specify what those are in this post: 🙏
My thoughts on the proposal: I generally like it, in my mind, it is more a reframing of methods and instructions than a fundamental change to the design/ethos of the voting system.
My suggestions:
- From a 'complete L2' perspective, people should be able to vote using BTC (i.e. not be dependent on the L2). We should keep this method but provide better instructions. Then, IF they can't figure out sending from the proper address out of their BTC wallet, they have a second option with the Stacks address.
- A challenge to overcome here will be that many solo Stackers will not have any STX available in their wallet to send because it's common for folks to Stacks 100% of what's in their wallet in Stacking. I suppose they can add a bit and then vote, but this may just end up harder for some folks than a BTC dust amount using the proper address.
To explore: stackers -> vote here (send 0.000001 stx) non stackers -> vote here (send vote tx)
Having different methods these parties have to self-select from actually seems unnecessary to me, so could we further simplify? With the STX address, I believe you could work backwards with API calls to see if they are a non-Stacker or Stacker without them needing to do anything?
Imagine that there is one yes address and one no address and all people had to do was send a dust amount (or auth if they happen to use an Xverse or Hiro wallet) from any address they own, Stacking or not - from there, the rest is tabulated and sorted based on the address history automatically. Elegant ya?
radicleart
Lessons from Nakamoto SIP Voting
The following refers to the recent Nakamoto SIP vote on stx.eco in which three voting mechanisms were provided;
Problems
Solo stacker voting
Many solo stackers were unable to send the bitcoin transaction from their reward address, due to address rotation in the wallet. The majority of solo stacker votes, as many as two thirds, had to be excluded from the count.
Pool stacker voting
Pool stackers sent a stacks transaction from the address they had used to join a stacking pool. However, the majority of vote transactions came from addresses which were not stacking, indicating that the web site and instructions had not been clear.
Liquid stacking
Liquid stackers were represented as a block vote.
Improvement proposal
The following changes are proposed to simplify the interface for voting on stacks upgrades.
Under this proposal, methods 1 and 2 from the Nakamoto vote will be combined - solo stackers no longer send bitcoin transactions. Solo stackers with stacks split across several wallets will have the flexibility of voting from any or all of their stacking addresses.
Liquid stackers vote in exactly the same as solo and pool stackers.
The tabulating software performs the task of indexing the pox and stStx contract data to determine the voting power of a given address.
The stx.eco ui/ux is improved to ensure the stackers understand the voting criteria before sending the vote transaction - e.g. the voting QR codes are shown after some user interaction.
Where stackers = same method for solo/pool/liquid stackers.