@blocktrades Thank you for what you do for us. I don’t think that is not said enough times.
Question: how are the second round of airdrop code will be determined? By voting you mentioned... but what kind and how. As we are a DPOS system hope that will be DPOS as well.
Another question: Hoping lot of steem will convert to Hive in near future... it is possible to give us a favorable commission at Blocktrades website to help us migrate our tokens. That way lot of holders probably won’t take the exchange route? Just a thought... maybe even for a limited time...
Regarding personal time, I am glad you are finding time to read. I read every day and also listen to audiobooks while I take long walks. That’s all we can do in the present world!
The excluded accounts will be divided up into groups based on reasons why they were excluded. For each group, there will be a FOR and AGAINST airdrop proposal. The stakeholders can then vote on their favored proposal for each group. Like all proposal votes, the voting will be stake-weighted. The devs will then add the list of all groups that will receive the second airdrop to the HF code and witnesses will have to decide whether they want to run the new code.
Note that such proposal votes aren't binding on witnesses (there is no way to force them to run new code) It's basically a way to poll the stakeholders. But the higher the voter turnout on the proposals, the more compelling the argument to witnesses will be to run the new code (since they might get voted out if they don't).
The code developed for this sounds like it could be a very interesting blockchain feature - a single DAO proposal which pays out to a large number of accounts. If I'm not mistaken, currently a given proposal can payout to only a single account. This sounds highly interesting to me because it opens up new avenues perhaps not explored before - a single proposal carried out by a large collective group of people who collectively receive funding. I guess it could be just a few or it could be hundreds of people.
Furthermore, another interesting feature would be the ability to hold the proposal payment in escrow and release it only when certain criteria are met (i.e. in the current situation the criteria are stakeholder voting on a proposal and witnesses updating their nodes to the new code). Again, the current second airdrop situation sounds like a use-case for this kind of feature, but I guess it would be done only one time (through a hardfork) rather than being a blockchain feature that can be used at will.
Yes, we're doing this as a one time hardfork, as the needs are somewhat specific (for example, it's not just Hive, it's also HBD, and it's a one time payment instead of something that pays out over time).
The proposal system could do with some improvements though, and we should probably setup a working group before too long to look into what should be done first.
That sounds fair! Thanks for the explanation.