Request for comments for the TZIP draft: Testnet admin key.
In this TZIP, we propose a protocol amendment where, for any chain other than Tezos mainnet, a chosen “dictator key” may force a protocol upgrade. The chain automatically upgrades to this protocol at the end of the voting period.
The rendered TZIP text can be found here
Please note that an implementation proposal associated with this TZIP does not exist yet.
This is a wonderful idea and incredibly necessary!
I’ll start a bounty on this out at 200 xtz. I will add to that number as I can.
I suspect the TZIP author have a WIP implementation already, but if not I started a draft implementation (totally untested yet). If it lightens the workload for the TZIP authors, I will be happy to continue working on it, and grab or share the bounty 
Help me get a working perpetual testchain up and I’m happy to pay out the bounty.
Upping my bounty from 200 xtz to 250 xtz or $1000 worth of xtz, whichever is greater at the time.
Please ask publicly or privately for details.
I agree that this proposal will improve the testnets. I would like to make a small suggestion, though, of naming conventions. I don’t think that this feature is limited in use to test networks. I think that a company that deploys a private chain might also use this feature. As such, I would suggest that the “testnet_” prefix should be removed from the parameter name.
Your implementation differs from this part of the specification in the TZIP:
The protocol where this mechanism is injected contains special constant migration code, which sets the dictator key to a key managed by Oxhead Alpha when the chain identifier is
NetXnHfVqm9iesp, the chain id of Ithacanet (or, if this proposal is accepted later, the relevant network at the time). For mainnet and any other chain, this variable remains unset. This special constant migration code can be removed in future protocols.
Instead, you set the dictator key to None in migration. I think this is preferable because on top of checking the chain_id it’s impossible for mainnet to even have a dictator key set. However, it would require restarting a testnet with this protocol and the dictator key in the parameters.json.
@G_B_Fefe there is no other implementation. I am using your implementation as a basis for this proposal.
I had a chance to build and test the most recent commit from your branch and it appears to work. Here is my writeup on the tests that I ran
I have updated the tzip to version 1 with the following changes:
testnet_governance_dictator_source to just governance_dictator_source per @elric1 , since this mechanism may be useful to private chains as well as testnets@sophia wrote:
Your implementation differs from this part of the specification in the TZIP:
Instead, you set the dictator key toNonein migration. I think this is preferable because on top of checking the chain_id it’s impossible for mainnet to even have a dictator key set. However, it would require restarting a testnet with this protocol and the dictator key in theparameters.json.
@sophia you are right, we would have to start a testnet if we don’t write migration code for testnets that already exist. Let’s not forget that we always start the testnet for protocol N with protocol N-1 in order to test migration, so it would be prohibitively long to wait for this permanent testnet to exist in the absence of migration code.
@G_B_Fefe The migration logic is now clearly specified in the new version of the TZIP. May I ask you to implement it? I have specified the public key hash for the ithacanet dictator key. Also, in your implementation, please change the parameter to the new name governance_dictator_source
Regarding the question on whether the “if not mainnet” logic is useful as a second security layer, I am in favor of keeping it (since you already wrote it) hence I left it in the tzip v1.
@G_B_Fefe when the merge is accepted I am happy to pay out the bounty in full, to you. Currently that is 250 Tez.
Thank you for the work you have put in thus far.
My dear @G_B_Fefe I owe you some Tezos. Would you be okay sharing an address publicly so I can prove I honored my bounty? You’re welcome to message me in private with an address if you’d prefer, if so, I would appreciate it if you’d confirm here that I have paid out the bounty.
Thank you for your hard work!!!
@G_B_Fefe it has been brought to my attention that you included the address ‘tz1X81bCXPtMiHu1d4UZF4GPhMPkvkp56ssb’ as an invoice address on one of your merge requests.
I will pay the bounty out to that address.
Done — tz1X81bC..p56ssb on tzkt.io
