Soliciting feedback on pre-emptive methods to protect Hive against a malicious court order ...
A week ago, I was listening to the live broadcast of Community Token Talk (CTT) Episode 61. @starkerz and @theycallmedan were talking about Hive’s resilience against attack and its resilience against regulation and coercive government actions.
They discussed (from 1:30:45 to 1:33:40) a tweet from @v4v.app (@brianoflondon) about what might happen if a malicious government tried to force Hive to censor an account or seize a wallet or some similar action.
@starkerz began the discussion by referencing how the High Court of England and Wales was able to intervene and force a ‘decentralized platform’ (oasis.app) to seize 120,000 ETH from a wallet that had been used in an attack on Jump Crypto’s Wormhole bridge.
Here is the statement from oasis.app announcing the actions they took (via their multisig protocol) in response to the court order. It bears noting that the court order and the Oasis Multisig implementation of the court order occurred ALL IN ONE DAY.
@starkerz and @theycallmedan then discussed how difficult it would be for a court to order 17 of the top 20 witnesses on Hive to do such a thing.
That got me to thinking. Should we incorporate a ‘feature’ into Layer 1 that would make it nearly impossible for a court to effectively order even ONE witness to take an action that might go against the community’s wishes. In other words, a ‘feature’ that would allow a witness faced with such a court order to elegantly and effectively resist implementing the court order.
I will explain a couple proposed solutions below, but first, here is the rest of the backstory.
A couple weeks ago, @brianoflondon tweeted about the need for a canary system, sort of like an emergency broadcast system where the entire Hive community could be notified if one of the witnesses was ever targeted by a malicious court order from an authoritarian government, or whatever other ‘emergency’ might arise.
Then @edicted tweeted about the possibility of paying witnesses who defy a court order out of the DHF.
To which @brianoflondon replied with the tweet mentioned above, the one that started this discussion on CTT:
I then joined in that Twitter convo, presenting an idea to help mitigate such an attack:
That led to some back-and-forth with @starkerz. Here’s that thread:
Then, on yesterday’s CTT (Episode 62), @starkerz and @theycallmedan briefly discussed my original idea (from 2:13:00 to 2:21:05) and an offshoot (suggested by @theycallmedan) wherein a witness could “press a button to forfeit all incoming witness votes” and return all their votes to a ‘consensus pool’; also, @brianoflondon reiterated the potential benefits of an ‘Emergency Broadcast System’.
Then @starkerz suggested I write a blog post about the concepts, to get some broader feedback from the Hive community (hence this post).
So, as of right now, we have three (3) potential new Layer 1 features on the table:
- @brianoflondon’s ‘Emergency Broadcast System’, which would enable witnesses to declare an emergency message to be broadcast to the community.
- @trostparadox’s ‘Whack-A-Mole Switch’, which would grant any account the ability to irrevocably delegate 100% of their incoming witness votes to any one alternative account.
- @theycallmedan’s ‘Deadman’s Switch’, which would grant any account the ability to irrevocably decline all incoming witness votes and send them to a concensus pool.
Below are four comment threads, one for each of the above features and one for general comments.
Comment thread for general comments
Comment thread for an ‘Emergency Broadcast System’ as proposed by @brianoflondon
Comment thread for a ‘Whack-A-Mole Switch’ as proposed by @trostparadox
Comment thread for a ‘Deadman’s Switch’ as proposed by @theycallmedan
Also, If you want to propose a completely new feature to potentially address the problem of malicious court orders and/or other forms of attack, please create a new comment thread below.
Posted Using LeoFinance Beta
Comment thread for a ‘Deadman’s Switch’ as proposed by @theycallmedan
Reply to this comment to make comments about the need for and/or ways to implement a ‘Deadman’s Switch’ for Hive.
The main idea is to implement a quick and reliable way for any witness who is targeted by a malicious court order to forfeit all incoming witness votes and return those votes to a ‘consensus pool’.
This sounds good, depending upon how the consensus pool works. Would the pool then vote for witnesses based on a consensus achieved by Hive users, and if so using what consensus mechanism? If using The Matrix-8 Solution this would definitely get my vote.
Comment thread for a ‘Whack-A-Mole Switch’ as proposed by @trostparadox
Reply to this comment to make comments about the need for and/or ways to implement a ‘Whack-A-Mole Switch’ for Hive.
The main idea is to implement a quick and reliable way for any witness who is targeted by a malicious court order to shift all incoming witness votes to an alternative trusted account -- to provide a very quick method for a witness to shield their account from being forced to act against the community's wishes.
Here are some of the 'requirements' I envisioned for the 'Whack-A-Mole Switch':
As usual your proposals are reasonable, but this time you also come up with the perfect name "Whack-A-Mole" switch. The delegating 100% makes this more than a "Catch me if you Can". It's a whole new witness.
That’s correct. However, the witness could (if they wanted to) delegate to one of their own alt accounts and merely buy time while the courts investigate who owner of the new account is. Legally, that would probably be a risky move, though, as that could be construed as obstruction rather than contempt. As long as it’s done before any official decree is made, though, it would be roughly equivalent of closing a bank account and opening a new one somewhere else. The burden would be on the courts to determine / prove ownership.
Comment thread for an ‘Emergency Broadcast System’ as proposed by @brianoflondon
Reply to this comment to make comments about the need for and/or ways to implement an ‘Emergency Broadcast System’ for Hive.
The main idea is to implement a way to communicate an important message to as many members of the Hive community as quickly as possible.
I have a relatively simple suggestion for how to implement an emergency broadcast system.
Allow each witness to 'declare' a message via their node, the same way they declare their 'vote' for HBD APR.
Then, each front-end can set parameters determining how many of the Top 20 witnesses must be declaring the same message before they take action to highlight that message via their front-end (or other methods).
They could also use different display methods depending upon how many witnesses are in agreement regarding a given message.
I have many ideas for how this could work and we need to bash them around to find the simplest.
The underlying structures we have on Hive are such that sharing text and information is trivial.
What is missing is some agreed way for front ends to recognise when such a signal has been sent and display it to all users in some way.
First suggestion from me: a standard post format and then when enough top 20 witnesses have signed it with a common comment response, like "Co-Signed by Witness Name" front ends can make sure it is alerted in their front end in whatever way they deem appropriate.
This feature could be implemented immediately by individual front-ends.
Someone just needs to publish a standard format that the witnesses agree to use.
If any consensus witness takes an action like "Deadman's switch", the notification systems by all frontends could be set up to pick up that action and give a notification to users. Any sort of broadcast system can live on layer 2.
General comment thread, for general comments related to this post
Reply to this comment to make general comments about the post.
If you want to comment about one of the ‘features’ mentioned in the post, reply to one of the comments below:
Comment thread for an ‘Emergency Broadcast System’ as proposed by @brianoflondon
Comment thread for a ‘Whack-A-Mole Switch’ as proposed by @trostparadox
Comment thread for a ‘Deadman’s Switch’ as proposed by @theycallmedan
I suspect that activating a deadman's switch, or choosing to relinquish witness votes, would render the witness in contempt of court in many jurisdictions. I have not previously considered legal jurisdiction of witnesses in voting for them, but it may be necessary to limit the number of witnesses subject to any particular legal jurisdiction in order to preclude a consensus being subject to court order in that jurisdiction. Say, no more than 4 witnesses in the top 20 can be subject to the Crown, or US law, or EU law, and etc., for example. This would prevent a court order from being able to compel a fork absent an alliance of jurisdictions, since 4 witnesses cannot fork.
I also suggest that in the event a court, or group of courts spanning jurisdiction necessary to subject a consensus of witnesses to court order, a proposal be activated that reforms the governance mechanism of Hive such that the subject consensus no longer suffices to enact forks.
Some potential mechanisms, which might be activated sequentially as necessary, would be increasing the number of consensus witnesses to 100, or another number that would be required to create consensus;
or eliminating the authority of witnesses to decide to fork, but requiring a proposal to be supported by all witnesses, or a supermajority of all witnesses, or a supermajority of the entire community, or a unanimous vote of the entire community, before witnesses are authorized to fork;
or rotating the specific party(s) controlling a witness node, so even absent lawful authority to fork a specific individual cannot be compelled to fork since their administration of the node isn't of sufficient duration to install subject code.
or yanking the authority of witnesses subject to court order and only allowing witnesses not currently under court order to be in the potential consensus pool, so that they have no choice to relinquish their authority;
or claiming an AI independently acts to make such decisions, and witnesses do not have the authority to tinker with the AI, which only can be granted through a successful proposal by the community entire. This would require courts to order the entire community to vote the proposal to alter the AI, since AI are not subject to court order, not being persons. At the least, it would significantly delay applicability of legal process until jurisdictions resolved on how to proceed with ordering non-persons to act;
or altering the voting mechanism in a way that would create chaotic inability to authorize witnesses to fork, disabling courts from targeting specific parties that possess authority to fork. Instead of stake weighting, we could choose to weight votes by numbers of followers, or number of posts, or number of published words in published posts, reputation, number of people followed, or some rotation or hourly cycle of these and/or other weighting schemes that would preclude courts from determining who to order to do their bidding.
The point of these initiatives would be to not leave the witnesses under court order liable to contempt of court for acting to thwart the court's order, but for their authority to act to fulfill the order to be removed from them without their personal action to do so.
Regardless of what is done to secure Hive from court orders, an Emergency Broadcast System is highly advisable, and whether a canary, a system of canaries, or simply posts describing the emergent situation, absent a gag order accompanying a court order, I cannot see witnesses coming under contempt for informing Hive of the situation. IANAL, however, and legal counsel should be sought to confirm this.
Thanks!
Thanks for the thoughtful comments.
I agree that there might need to be a mechanism that can be invoked by the community in the event a witness ends up in a position where they cannot be the one pulling the plug on their own node.
However, that type of system would need some serious thought, because it could conceivably be co-opted to take down legitimate witness nodes.
An urgent notice to voters asking them to unvote would be preferable, imho, to a system that allowed a third party (not the witness and not the voters) to intervene.
Any action taken by an individual to thwart a court order puts them at risk of contempt.
Certainly very careful planning is necessary to implement any mechanism that can affect governance. Such mechanisms can be only implemented in the event of court orders. If carefully prepared, potential misapplication can be prevented. It is essential IMHO that witnesses who are at risk of being subjected to court orders are indemnified from liability to contempt, and witnesses should absolutely have the ability to veto any scheme they feel is not safe, or is not going to be effective. Given that prior involvement of witnesses in any such scheme, their security should be adequately assured.
Since we are discussing legal matters, it is necessary to consult competent counsel. @apshamilton is such competent counsel, and so I tag him here to seek his consideration.
Absolutely!
I wonder if there could be some sort of poison pill that can be tied to receiving payment as a witness.
What I mean by that is that you are required to declare an alternative account and you are required to immediately declare whether or not you are subject to or potentially subject to a court order.
As soon as that court-order field is switched to “Yes” the delegation to the alternative account is executed, by the underlying code (i.e. by one of the subsequent witnesses).
Or maybe switching that status to “Yes” simply causes your node to be skipped until a certain percentage of the voters reaffirm you as a witness, or maybe that action gives the remaining witnesses the power to collectively vote to initiate the delegation.
Could a court hold someone in contempt for merely informing a business partner that they are subject to a court order or may soon be?
The simple solution to this is for the witness that has been targeted by any legal proceedings to activate the dead man switch BEFORE any formal legal Court order is made.
This should be easy because the law is very slow and the deadman switch could be activated by phone in less than a minute.
Except in case of ex parte proceedings (where the targeted side is not there or given notice) the witness will have plenty of notice.
Even in the unusual case of an ex parte order, immediate activation of the dead man's switch will undermine the Court's jurisdiction over the witness and the fact that the witness is not actually 'in Court" makes a contempt of Court finding both legally problematic and practically difficult to enforce.
These sorts of orders are generally civil orders not criminal and don't have any international standing.
So the targeted witness can flip the dead man switch and legally leave the jurisdiction for good measure.
Hereabouts, in the United States of Shamerica, contempt orders enable jurists to indefinitely jail the subject until they agree to comply with whatever order of the court they are found in contempt of. I'm unaware of anyone that has been held captive more than a year in this way, but there's literally no limit I know of.
In the OP above, the court order was enforced the day the order was issued. I think you're probably right, that acting prior to such an order is the only way to avoid being held in contempt.
Thanks!
Damn. This along with Civil Asset Forfeiture really flies in the face of the whole land of the free stuff...
What about the provision that no more than 4 witnesses from a given jurisdiction can be in the top 20? I think that precludes a court order from any given jurisdiction being able to compel of fork, since 4 witnesses cannot force a fork.
Thanks for the suggestion.
This type of brainstorming is exactly what I was hoping to encourage.
Whereas it takes 17 out of the top 20, a coordinated governmental attack would be so improbable and, whereas government actions are very slow as @apshamilton mentioned, I think some prudent but simple countermeasures would suffice.
Also, limiting jurisdictions would require witnesses to declare their jurisdictions, which would actually aid a malicious government in identifying and targeting witnesses to attack.
This would require all witnesses to disclose their location or jurisdiction, as potentially any witness can get in the top 20 in a matter of one block (3s).
I hadn't realized this brainstorming, and appreciate the consideration.
This is the most important point, IMO.
The proposed mechanisms does protect the blockchain itself, but does not protect the witness. For example, the "whack-a-mole switch" being irrevocable makes it impossible for a court order to determine the un-deployment of the switch. In the other hand, the court order can just punish the witness that does use the switch, encouraging him to NOT pull the switch.
These mechanisms will be used by witnesses that trust that "the system" (the courts, the government, the FBI, whatever) wouldn't be able to punish him, eg someone that does not have physical assets at all and is currently living in a country without extradition agreements. But what about a witness living in his home country and not willing to be arrested due some bogus judicial decision like "Oh you pulled the switch? You disrespected the court order and now you'll be arrested for 20 years, say goodbye to your wife and kids".
What I'm wanting to say is: not everyone is willing to throw away their lives just to defy "the system". The blockchain can't depend on the willingness of witnesses to sacrifice themselves for "the greater good". @apshamilton said that "the targeted witness can flip the dead man switch and legally leave the jurisdiction"; but what if they aren't willing to leave the jurisdiction due a plethora of valid personal/business reasons?
The community need a mechanism that's 100% independent from the targeted witnesses himself, so everyone else can pull the plug without the witness intervention (and possibly incriminating himself and exposing himself to legal punishments).
Although I agree that "the community" needs a way to deal with this, there is already a mechanism for that, which is for individuals to withdraw their votes.
It doesn't hurt to have a both-and solution -- where the witness can pull the switch (which will be very fast, but might not be advisable for the witness, depending upon the legal situation), but also where the community can pull the switch (which will admittedly be slower).
I am very hesitant, though, about any sort of mechanism wherein other witnesses could implement such an action on their own accord, because that merely sets the stage for another attack vector.
I would much more strongly favor a mechanism that provides for rapid notification of the voters themselves, rather than something that allows third parties to intervene.
Perhaps this includes both a public and private notification protocol. The public notification could be something like @brianoflondon is already proposing, which you can comment about here.
A private Layer 2 notification system could allow concerned individuals to sign up (in advance) for SMS and/or email notifications under certain conditions (such as a witness 'distress call').
Such notifications could be triggered by some action by third parties (e.g. majority vote by the other top-20 witnesses) because it is merely a notification, and thus would not be a potential attack vector.
While notification is clearly a need, it is obviously not going to result in instant action by the community, and witnesses may be legally unable to flip a switch.
Because of these realities, it seems to me that code should provide a mechanism that disables witnesses under court order. Hive cannot abide such external interference. There are clearly mechanisms external parties could deploy that are fully competent to destroy Hive, and the extant example(s) of such external entities imposing such interference on the same day courts ruled show that awaiting the community response cannot suffice.
Indemnification of witnesses from potential liability for instigating such a mechanism may require some association of witnesses to jurisdictions enabling surveillance, or a blanket surveillance mechanism of all potential jurisdictions presenting a credible threat of court orders that may impact Hive.
In any case, I cannot envision any mechanism that potentially indemnifies witnesses absent surveillance of jurisdictions, whether specified as relevant by witnesses (potentially anonymously?), or a blanket mechanism. Obviously, the latter would be a more monumental undertaking, and require more substantial expense and expertise to effect. However, any such surveillance would require considerable expense, effort, and expertise to successfully achieve.
Yes, but we do need to be careful that we do not create a 'solution' that results in a more dangerous attack vector. Code that responds to a court order would, imho, make it far more easier for a malicious government to wreak havoc, because then all they need to do is identify entities and issue court orders, regardless of their enforceability.
So, automating such a mechanism could be potentially disastrous.
I still default to mechanisms that speed up the actions of the individuals involved rather than those that allows a third party to intervene.
You mean a kill switch?
I note the danger of enabling third parties to trigger impacts on Hive governance, and appreciate your concern. However, I cannot see how to indemnify witnesses from court orders without such a mechanism, because if they themselves act to impede the court's order, at least in US courts I reckon they could be liable for contempt.
Perhaps this is a risk witnesses just have to accept, since enabling external actors to affect Hive governance is indeed unacceptable.
That is my current position.
As @apshamilton stated here, the risk to any witness facing a potential court order seems to be fairly low, because of how slowly the courts operate.
To increase resiliency, it would probably be prudent to assume worse-case scenarios. Best to assume that if a court order is sent to a witness, it orders them to not disclose the order to anyone and not to do anything that interferes with the order (i.e. can't pull a deadman's switch, can't shut down their node).
Also, even better to assume an international coordinated action by police/courts/governments/etc., aimed at changing the Hive network or gaining control over it. Better to assume the police is involved and they find out who the people running the witness nodes are, and can physically reach their homes. What then, if they reach the top 17 or top 20 and can threaten and silence them?
Anything that will make our network “bulletproof” is very much welcome 💪🏼
https://twitter.com/1359604242256953345/status/1635182998357430272
https://twitter.com/1331330355513745413/status/1635452865589248001
https://twitter.com/1415155663131402240/status/1635640571900624897
https://twitter.com/863912546/status/1640075748756054018
The rewards earned on this comment will go directly to the people( @v4vapp, @taskmaster4450le, @rzc24-nftbbg, @celi130 ) sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.
At first I thought 'the solution for this would be simply the witness shutting off his node', but as I kept reading this suggestion made more and more sense.
Hopefully we never need to use it. But better be safe than sorry and have the tools available beforehand.
Great suggestion! Hopefully gets added in teh next Hard Fork/s. Not urgent (for now) but needed eventually.
Reblogged for more exposure. thx!
Yes, if a court order could (conceivably) compel the witness to run specific code then it could also compel the witness to turn the node back on.
And, if they are intent on forcing the witness to run malicious code that the government wrote, then they would likely have a node (with the malicious code) already up and running on a government computer, then simply compel the witness to provide his/her credentials.
Yes, I seriously doubt it would ever be needed. With that said, its existence would make it even more unlikely that a malicious government would attempt such an action.
Also, years ago have had friends websites attacked and shutdown through their hosting company/datacenter. So a court order, heck just even a request from a law enforcement agency to where you have your website or witness node could be another attack vector. I've seen hosts shut down people's sites just for a simple cease and desist letter from a lawyer. Hosting companies want no part of that trouble so it's easier to comply.
So just think if a gov went after hosting/datacenters hosting witnesses.
That's the simplest and most efficient way to proceed (from a government point of view). It is against this kind of threat that we must protect ourselves.
Great discussion, I feel that anonymity is also a good deterrence. How to shut down a node if the identity of the witness is anonymous?
Yes, that is a huge advantage, imho.
I think a majority of the witnesses have actually concealed their identity, so that's already a huge +
Really? Not those currently in the top 20. And not even for the next 20.
well it's definitely not common/open knowledge looking at their profiles, I don't doubt you got more info ;)
It's not just in their profile that you can find this kind of information. The blockchain is a (public) goldmine in this regard.
That is of course true, but I wonder if it is enough to definitively identify someone
Anonymity is not potential in reality when considering the known compromised hardware and software weaknesses extant. While you and I are not availed certain tools, it is known that state actors have hardware backdoors, as well as a plethora of known means of compromising RNG's and other cryptographic devices.
Intel IME has analogs in all commercially available chipsets to my understanding, and it is common practice to lease servers from the cloud, potentiating compromise by state actors. Since we're talking about court orders, we're talking about state actors, not script kiddies.
I simply assume that anonymity does not exist when state actors are a factor. Pseudonmymity and the possibility of thwarting lesser threats is all I consider to be possible in the extant hard and software markets.
I think you are absolutely correct. But I would guess that these "hardcore" intrusive techniques is not something they would apply for a z-rated blockchain. Perhaps it's best for now that Hive is just flying under the radar. Also, maybe it would be a nice challenge to try and design a system that would actually be professionally anonymous
Many folks are working on all the vectors through which anonymity is today compromised, from Beechat, Qortal, and other open source hardware networking devices, to i2p, freenet, and Hive, in it's own way.
yeah, this is something we really need
Love this post, gets me even more confident and excited by the Hive blockchain and it's community, Keep up the good work @trostparadox and ev1 else involved in this. You got my full support and respect, tyvm! :)
Yay! 🤗
Your content has been boosted with Ecency Points, by @mineopoly.
Use Ecency daily to boost your growth on platform!
Support Ecency
Vote for new Proposal
Delegate HP and earn more
I think since the problem with Justin Sun and @darthknight happened a few years ago one has had to start considering all cases where "larger forces" may come and try to force legal measures that may affect us in some way or another.
Anyway, I am absolutely sure that it will be easy to cope with this kind of problems in the future. Ideally they should never happen, but it is always better to be prepared :D
Exactly.
I am convinced of the opposite. Until open source hardware is commonly available and standard practice, I see no route to security from state actors able to compromise commercial chipsets and cloud network services.
I think so far history has shown us that a legal intervention in a blockchain has not been possible, and anyway I feel that due to the current adoption of cryptocurrencies in the world, for a government to try to commit this kind of actions would not be well seen by a large majority.
Anyway, time will tell. For now, we can only prepare in case it should happen.
I note that well laid plans are made by patient actors.
We will indeed see.
The increasing interest of contemporary governments in integrating blockchain technology into their actionable frameworks is raising concerns regarding the security of witness accounts, their networks, and hardware. As these components are vulnerable to attacks, a temporary opt-out mechanism could be implemented as a proactive measure to safeguard witnesses. The presence of such a mechanism can potentially serve as a significant deterrent to potential attackers. It can be compared to a scenario where resources are invested in attacking a person who possesses the ability to teleport, a completely unproductive endeavor, and therefore none will attempt it.
Yes, although the initial thought here was merely to add another tool to further harden Hive’s defenses, I agree that the mere existence of such a tool will also serve as a deterrent.
Wonderful discussion, how are we going to bring down this art without witness of the account is hidden
Not just witnesses, but stakeholders can also be targeted. Let's say the top 20 witnesses AND the top 20 stakeholders are targeted, at the same time, in a sophisticated coordinated action. The rest of the network has to be able to keep the network running.
In a similar vein, datacenters or hosting companies can be targeted in an attempt to shut down or take over many nodes at once. This could end up including top 20 nodes as well as many other nodes. Again, the rest of the network has to be able to keep the network running.
A very sophisticated actor would study the system very well before making a move. They would identify the weakest spots. So they might go for all three vectors described above (witnesses, stakeholders, datacenters), at the same time. And in addition, they might launch a campaign to convince the public that the network is posing a great danger for reasons xyz, and present evidence and negative things that have happened because of the network's activities (some of which may be genuine challenges that the network is working on overcoming - not unsolvable problems). (Capabilities like censorship resistance and immutable content pose challenges and have to be handled carefully and socially responsibly, for sure.)
There are such sophisticated actors that have huge technical capacity and IT personnel at their disposal. See for example this hack on Google: Operation Aurora.
Excellent point. This potentiality certainly warrants analysis and consideration.
Regarding attacks on stakeholders, I think the biggest advantage will be having those stakeholders distributed amongst different jurisdictions. Of course we have no way to coordinate or effectuate that — it is what it is.
As far as hosting services taking nodes offline, having 400 active witnesses should ensure that the blockchain keeps functioning even if a widespread coordinated attack came along that vector.
True. However, even if such actors were able to pull off a wholesale takedown of the blockchain and all its witnesses, Hive can simply be reborn, like a Phoenix from the ashes, as long as at least one node, somewhere, has the pre-attack history of the blockchain stored on it.
It's not about targeting the top 20 stakeholders, but top stakeholders who together hold 51% of the voting power.
That's why I run at least one witness backup node on premise.
And as @trostparadox said, should they take Hive down, we would simply fork it and restart, as we already did.
There are diminishing returns potential to that last ditch mechanism, and I am certain all of us would prefer to prevent losing what resources in infrastructure, stake, and community are endemic to existential forks.
The PoS governance mechanism is entirely vulnerable to nothing more than stake. This was proved by the events that necessitated the creation of Hive. AFAIK, the only security Hive presently has from external stake successfully prosecuting such an attack by no more sophisticated means than buying stake is the 30 day moratorium on stake voting witnesses.
It is utterly facile to buy accounts or tokens through various and myriad cut outs available to state actors and deploy them after that 30 day moratorium has expired. Such stake based attacks could instantly replace a consensus and implement code. No hack required at all.
Absent implementing radical changes in governance, I don't see any route to security from such attack. Only basing governance on other metrics than stake are potentially competent to secure Hive from such vectors.
That is why I advocate promoting other values and deprecating stake. It's also obvious that extant stakeholders will not be willing to do so, and that such attacks represent golden parachute exit strategies to that demographic.
Excelente
If the government became that authoritarian, and you implemented any of these options, couldn’t the government just seize your devices and infiltrate the system secretively? Being you. Or really go communist and shut access to the internet of if it really wanted to? Maybe I am too authoritarian in my head right now. Maybe the decentralized world needs to become its own “country” with rules and notifications to other governments that the decentralized world is protected by hackers who will bleed them dry or expose them to their country should they cross a line to enter ours? That’s basically what every country is doing with weapons , nukes?? It could just be a decentralized nuke of Wikileaks and threats. Hahahaha. There has got to be some Snowden’s and Julian’s on blockchain willing to protect it. Definitely needs EBS and the dead man switch. A consensus pool would mix the funds and supposedly it’s confusing to courts if it’s to one account the court can find that one person to make them turn it over and now 2 people are in trouble… consensus pool, the court has time to go through that many people? I doubt it.
This is not theoretical, and has happened numerous times in the last decades. I haven't bothered to count the number of times, or track the jurisdictions, that have just shut off the internet, or parts of the internet, in order to suppress speech. I believe that is ongoing in several jurisdictions right now, and to some degree or another in all jurisdictions on Earth. I believe Iran basically has shut down social media due to widespread protests at present, and vast areas of potential speech simply aren't practically available in any jurisdictions today.
I2p, Tor, and other such mechanisms seeking to obviate jurisdictional interference in free speech exist for that reason, but I believe are incapable of being implemented successfully to secure Hive from such interference.
What stands in the way of increasing the number of consensus nodes from 20?
I believe that parameter would need to be included in a hard-fork, which requires a consensus vote from 17 of the top 20 witnesses.
@theycallmedan has discussed this at various times on their CTT podcasts (@cttpodcast). As Dan has eloquently stated in the past, the number needs to be small enough that people can vote for witnesses they actually have some knowledge about, but large enough that collusion and/or hostile takeover are difficult to accomplish.
Twenty seems to be a pretty good number at present. As the ecosystem grows, I could see that number being increased to 30, maybe 40. Any more than that and an individual's ability to keep track of witness reputations begins to wane.
Thank you for your answer. That's fair enough. I struggle to have any real idea what the witnesses are up to so I understand completely. More decentralization is better in my humble opinion, but there's obviously limits to what can be realistically achieved