Part of the beta process could also be to test the MAID → SAFE conversion.
How about a scenario whete the maid block chain is frozen at a certain block prior to launch and the initial conditions of the network are seeded with safecoin purses (“wallets” are soooo last year BTC…) that can only be decrypted with the private maid key. The location where these are stored could be an MD formed from the public MAID address.
This process could be tested during the beta resets. After all tests pass and all systems go, the network launch would then be a final beta reset to commence the 3-day party in Ayr? @zoki already has hotel reservations…
The suggestion by David and the dev team was that the later Betas (release candidates) would be essentially the live system but with the potential that they might need a reset of data if something really bad is found. So the last beta would simply be declared as the release version after a period of time. The timing of that announcement would not be based on humans since that could involve insider knowledge, but on a set of conditions being met.
I would estimate that there would be some limits on the amount of data being uploaded so as to prevent spamming. Maybe giving out a limited number of test safecoins .
@anon86652309 it might even be a good idea to have “version” variable in the coinBalance to allow testsafecoins coinbalance to be reset if one was ever found in the live network. This way we can simply push an update that sets the version to use livesafecoin and all testsafecoin coinbalances will be reset to zero livesafecoin before use in the live system.
That came from when safecoins were actual individual data objects. A spend coin would be recycled by deleting it and thus the term “destroyed” to denote that the data object was deleted and removed from the network rather than shuffled into a “SAFE purse”. Thus destroyed. This then allowed the network code to know if that coin could be created and given as a reward simply by testing existence at that coin address.
Now with Fraser’s method that is correctly no longer the case and “recycled” would be the perfect description and “destroyed” is no longer valid
See above in my post, if they introduce “version” in the coinBalance record then they can nullify any testsafecoin when going live. Yes some details would need to be ironed out for the transition period till MAID is converted into safecoin, but that should be easy enough to work out. Oh I see you mention that yourself below.
Maybe @anon86652309 the version for farmed safecoins in the last beta could have the version set to livesafecoin and remain when the network goes live and safecoin version is set to live V1-0-0
I’m no BTC expert. I just figured that there might be an analogous way to use BTC keys for PGP. @mav probably has some good insight on this.
I think the ability to use BTC keys for PGP might now be possible with this merge…
I’m all for getting versioning in sooner rather than later. However, at the moment without having spent long thinking about details, I’m more in favour of a coarse-grained approach where we version RPCs to the vaults.
The RPCs which vaults handle are effectively the API to the network as far as my blinkered, back-end dev vision is concerned. (Irrespective of whatever API Safe Client Libs presents, people can write their own clients or vaults in whatever language they prefer, and assuming their messages and behaviour is in line with the network’s expectations, they’ll be as much a part of the network as any other node.)
So, for now, it seems simpler to me to handle versioning at the RPC level. Once we have the resources/time to handle more fine-grained differences, we probably should.
Having said that, I’m definitely in favour of putting the building blocks in place for more fine-grained versioning right now, even if the early network disregards those. For example, we could add a version field to things like safecoin, encryption primitives, serialisation format for messages, data types, etc., but if we just ignore those for now and only respect RPC versions, then a change to any one or more of these could all be effectively encompassed in a single change to RPC version. This is something I’ve had in mind for about eight years, but as I say, we’ve never really thrashed out the details, and I’m very open to being pointed in a better direction.
Sounds like a good idea. From my experience doing it up front is best for a couple of reasons.
Its the first stage in actually doing it.
Motivation
always included when calculating sizing requirements of data blocks
I cannot count obviously
So even if its a 4 byte value initialised to the first sub version possible.
Do you have a version in the header of any packets of the SAFE protocols. I have always assumed they are there since in my thinking they are essential because things invariably change and its needed to know that on the receiver’s end.
