Yes, the governance action is separately associated with each account. So a governance action by an account's proxy only sets the last time for the proxy, not for the accounts that proxy to that account.

I'm passionate about some aspects of Hive, less passionate about others. I'm mostly passionate about the rating calculation system I want to build on top of Hive, as I think it addresses some of the major

I agree, Hive users definitely want/need a user-created tokens and it's definitely part of our roadmap, in one form or another.

Why are we still trying to game theory the votes? Because that's the smart thing to do when you create an economic system. We have to accept there will always be side effects we can't predict before

There will always be auto-voting as long as there are curation rewards, IMO, because not every stakeholder will want to curate. Accepting that premise, I think the proposed solution will at least direct

Thanks for the input on the penalizing of small votes. What you said jibes with what I've heard in the past, although I wasn't aware this also reduced voting on comments. If I recall correctly, the original

if developer spots that he can push some rarely used data to external storage he would be very much willing to do so. "Not so fast!" says the reality - "You need that data to compute hash".

Yes, but I don't see the need for everyone to "get in early" on every good post that is created. There just needs to be sufficient good posts for them to vote on during the time they are curating

2nd layer smart contract tokens are likely to be the easiest solution to the economics problem you're bringing up. And to make sure that the Hive token holders benefit from the work done to develop it,

Yes, this is one of the probable ways to mitigate any potential problem.

There's two distinct concepts that are often confused: atomic swaps and trustless crosschain transfers. Atomic swap technology is well-established and relatively simple to implement (it was implemented

I also hope to see more digitial marketing/advertising take place, and while I don't plan to lead any such effort, I'm happy to vote for reasonable proposals on the subject.

The first thing we'll do is run a simulation to see the impact of doing nothing in particular. Then if there looks to be an issue, we'll examine ways to smooth it out more.

The current powerdown time discourages exchanges from staking their customers' coins. So I'm not eager to change the power down time.

Yes, I have much more to say on the topic of tokens (and tokenomics that are beneficial to Hive holders). But I don't want to get too deep into these economic issues until we've built some simple prototypes

I think we need to clarify on terminology first. We've never been time-linear in terms of rewards. Early voters always got more curation rewards than later voters. The planned change will make that not

I did some analysis a couple of weeks ago, and most of the slow down in hived API response time isn't really related to rocksdb itself. The first issue was related to locking, but we improved that a lot

Yes, I think we can revolutionize Hive app development with some of these changes.

Those are definitely part of the plan.

HMTs aren't that difficult, IMO. The issues in their development were mostly issues of software management. Our team hasn't done any work on HMTs since we started working on Hive, as we've been focused