RE: Soliciting feedback on pre-emptive methods to protect Hive against a malicious court order ...
You are viewing a single comment's thread:
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.
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.