You are viewing a single comment's thread from:

RE: Steem vs. Hive - A Quest for New Governance Approaches? (Research Project - Call for Participation)

in #hive5 years ago

In retrospect, do you think the communication was appropriate about the fork taking place? How could it have been better communicated to the stakeholders affected, other than delaying it?

It could have been better. But I accept that time was of the essence. I think they weighed the risks, as they knew them, and it is what it is.

That's interesting, can you tell me more about that? Why would a delay of the hardfork have caused a threat?

Just to be clear, I'm referring to the delay between announcing the hardfork and deploying it. I believe they could have remained in the stand-off and delayed announcement for weeks, perhaps months. I don't believe the folks behind the hivefork thought they had weeks or months. And once announced, there we other risks.

Once announced, a greater deployment delay could have allowed the opposition an opportunity to attempt a hardfork of their own, just before the hivefork, which would have muddied the waters. The folks behind the hivefork anticipated this by stating they would fork no matter what the state of consensus was leading to the designated time.

I'm impressed that they took the risk because their other option was a secret (hive) hardfork, which would have looked very bad.

I don't know if they considered just staying in the stand-off and delaying the announcement.

Is there a trail of evidence of prior forking attempts? I would love to have a look at these.

Setting aside the prior attempt(s) at forcing Steemit, Inc. to do one thing or another, there have been several projects that split off to do their own thing (golos, whaleshares, smoke.io, bearshares, viz.world, vox.community, weki, dpays, norestlabs, et. al).

That's what I'm referring to. The community didn't really follow, much less any devs, and no apps that I'm aware of. They all failed to get the kind of attention Hive is getting.

In retrospect, do you think the softfork was appropriate? And was it appropriate for the counterparty at Steemit Inc to react in the way they did?

I always through the softfork was inappropriate. But I accept that witnesses can run any software they want on their node. The exact problem I have is when they say they'll run one thing but instead run another. And for a few blocks, they at least ran code without disclosing, until it was announced that they switched.

I understand the nuance that they thought there was an eminent risk. I just don't understand how a 20% stake represented such a risk. It's possible that if they announced their intent, the exchanges would not have entered the story the way they did and a dialog would have opened up. This would have possibly still allowed the Hive team up to 9 additional days of development while these talks were happening.

Steemit, Inc.'s response was also inappropriate. I believe there was a technical response that could have side-stepped the witness-initiated-softfork. Basically, an on-chain solution without needing the exchanges to get involved. Instead, they got the exchanges involved and alienated their own developers who quit in protest.

Did those witnesses take any precautions to prepare for such a response, or did they simply take the risk? Also, are there publically available sources of their considerations?

Not sure. I'm just going by what was said after the fact.

So, the Hive witnesses were in a sense united against a common enemy (which was Steemit Inc)?

From a staking perspective, yes. And once the exchanges entered, I think it's possible to claim there was even more unity. It also gave them confirmation (bias?) that the softfork was justified.

This sounds like the softfork was the initial cause of the dispute, whereas others have argued that it was a reaction to the dispute. Do you think the intention to centralize control came before the softfork, or after?

No, the softfork was a response to a) the sudden transfer of stake from Ned to Justin, b) mentions of a "token swap" which the witnesses perceive as an eminent hardfork by Tron, c) Justin's behavior on the Tron network, where he demonstrated willingness to use Tron founder stake to remove opposition, and d) no dialog from Tron for 9 days, causing the witnesses imagination to run wild.

As for centralized control, if someone has the keys, they have control. The fact that there's so much stake on exchanges is the problem. When there was 100% annual inflation and a two year power-down (where VESTS are protected from that inflation), that alone was a disincentive to keep STEEM on exchanges. What I'm saying is that in a sense, changing the inflation (HF16) unintentionally put the platform at risk.

Do you think both (or potentially even more) platforms are economically sustainable?

In the short term, I think both chains will be fine. In the long term, Hive has a fundamentally better economic outlook because the "dev fund" has been locked up. The long term for Steem is a little more uncertain, but no more than it was before the acquisition, in my opinion.

Sort:  

Thank you again so much for these clarifications @inertia! Your detailed reflections are tremendously helpful to paint a detailed picture of the situation.

Could I just ask you to help me out with the following:

b) mentions of a "token swap" which the witnesses perceive as an eminent hardfork by Tron, c) Justin's behavior on the Tron network, where he demonstrated willingness to use Tron founder stake to remove opposition

Do you by any chance have sources for these statements (e.g. blogposts on Steem or similar)? That would help us a lot to validate these claims with the original references.

Thank you in advance, and best wishes.

b)

<p dir="auto">The original statement that got everybody nervous about "token swaps" was: <p dir="auto"><br /> <sup><b>later retracted<span><a href="https://support.poloniex.com/hc/en-us/articles/360043406513-Coming-Soon-STEEM-Token-Swap" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">https://support.poloniex.com/hc/en-us/articles/360043406513-Coming-Soon-STEEM-Token-Swap <p dir="auto"><img src="https://images.hive.blog/DQmdYnsZQpVA2gsr6JNmrCLjCW6q2turtsMZt3zXLAk7ikB/image.png" alt="image.png" /><br /> <sup>As seen <a href="https://web.archive.org/web/20200216203653/https://support.poloniex.com/hc/en-us/articles/360043406513-Coming-Soon-STEEM-Token-Swap" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">on 2020-02-16<br /> <p dir="auto">It should be noted that once "token swap" was retracted, there was about a week prior to the softfork where Tron would pivot to the term "atomic swaps." <p dir="auto">The retractions were an attempt by Tron to deescalate. But at no time did Tron acknowledge the specific claim that there was a lack of disclosure involving the transfer of the "dev fund" which was the bigger issue to the witnesses who froze the accounts. <hr /> <p dir="auto"><strong>c) <p dir="auto">Regarding the use of Tron founder stake to remove three super representatives (SR): <p dir="auto"> <p dir="auto"><img src="https://images.hive.blog/DQmXMvEGLU46xn9thEAPUE7C4eCPog2ZRTGPzisj6RGnHxe/image.png" alt="image.png" /> <p dir="auto">I'm not convinces that Tron fully explained the security issue around this action. I suspect these SRs were routing (stealing) fees from malformed contracts. But I've never gotten any confirmation of this. The reason I think this is so is due to <a href="https://github.com/tronprotocol/tips/issues" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link">certain TIPS (Tron Improvement Proposals) that coincided with the <a href="https://github.com/tronprotocol/java-tron/releases" target="_blank" rel="noreferrer noopener" title="This link will take you away from hive.blog" class="external_link"><code>java-tron releases blocked by these SRs (specifically, TIP-37 and TIP-54). Again, all speculation on my part.

Apologies for my late response, but a big delayed thank you for your help @inertia!