You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of a deployment issue than a tinman issue, but I'm putting this here for lack of a better place.
Who are the testnet witnesses?
There are two possible answers:
(a) We (Steemit) run the testnet witnesses. This has advantages of being already implemented, allowing us to test various scenarios of witness behavior, and allows us to quickly and efficiently upgrade the testnet release (or make other changes that require witnesses to do something) without having to coordinate with 20 external individuals.
(b) The testnet witnesses are run by the same people who run the main net witnesses. This has the disadvantage of needing additional coordination with 20 external people, and changes to tinman transaction generation will be needed to give votes to them, and someone will have to operate witness nodes for any witnesses that can't be contacted or choose not to participate in the testnet. But it has the advantage of being most similar to the production environment and allowing current witnesses to test their witness-specific setup with the new code.
My feelings on the above options are as follows:
(a) is better for the immediate short term, since it's a shorter route to MVP.
We should have a long-running type (b) testnet.
It would be good to define a path by which a type (a) testnet can morph into a type (b) testnet.
It would be good to be able to create a type (a) testnet with a minimum amount of developer time.
Maybe we should have an automated script that, over the weekend, launches a new type (a) testnet using the latest develop.
We should probably have a centralized place to track past, current and future testnets (IP addresses of seed nodes, purpose of the testnet, planned duration, commit hash of a steemd version that should be able to connect to it, any API endpoints operated by Steemit, whether it's type (a) or (b), etc.)
The text was updated successfully, but these errors were encountered:
I believe the genesis conversion process covers this question (#17)
All witnesses will be copied over, setting their signing key to initminer's key. Then, we will vote for the top 30 witnesses with initminer. This will allow us to produce blocks as the witnesses. Because their active auth will still be valid (as the copied posting auth), they can change the signing key and take over whenever they want.
By voting for the top 30, it means we only need 2/3 of witnesses to fully participate and allows some of the runner up witnesses to be active on the test net.
This is more of a deployment issue than a
tinman
issue, but I'm putting this here for lack of a better place.Who are the testnet witnesses?
There are two possible answers:
tinman
transaction generation will be needed to give votes to them, and someone will have to operate witness nodes for any witnesses that can't be contacted or choose not to participate in the testnet. But it has the advantage of being most similar to the production environment and allowing current witnesses to test their witness-specific setup with the new code.My feelings on the above options are as follows:
develop
.steemd
version that should be able to connect to it, any API endpoints operated by Steemit, whether it's type (a) or (b), etc.)The text was updated successfully, but these errors were encountered: