Network beta launch --> catastrophic failure token backup

I’ve had a bit of a fear for a number of years that after burning maidsafe tokens to the launched network, the network, for some unforeseen reason, or an attack, catastrophically crashes and all data, including token data is lost.

That fear is most likely completely unwarranted for reasons A,B,C, etc that I’m not clear on. But, precautionary principle in mind and assuming the cost of doing something about this isn’t too high, then maybe there is a way we can protect the community from such an event in the form of a token backup.

For example, I send maidsafe tokens to the burn address and I also give an ethereum address … not only does the app at the burn address create the safe network tokens on the network, but it also sends the same amount of maidsafe v2 tokens (to given ETH address) via an Ethereum contract purposely built for this task as a backup.

These new ethereum-based tokens serve only as a backup - they can’t be sent to the burn address for more safe network tokens (it would only accept omni-tokens anyway).

If something unthinkable happened to the network at some point in the future and all data was lost, including safe network token data, then a new network could be launched (bug/security-vulnerability fixed) and these backup tokens would then become the new source token for burning to become safe network v2 tokens.

known cons: Extra work for devs

Thoughts?

2 Likes

The solution, in my opinion, is to make a snapshot for MAID 1-2-5 years after the network has proven to work stably.

With ERC20 tokens we will not have a problem with the trading of the new Safe tokens in the DEXs.

3 Likes

Tokens on the Safe Network though are anonymous … there won’t be a way to snapshot it I think. Hence copying at the outset would be the only way.

1 Like

yes, but this way you only risk the newly farm tokens…

1 Like

I’d keep MAID and SNT (or whatever it will be called) working in parallel. You convert what you need from MAID when your risk appetite permits.

1 Like

Imo good idea is give part of resources to hacker error bounty program. Is not 100%, but when you give all money to final network, then their motivation to “hack” is bigger.

Another idea is: give extra “farming” tip to people who first give MAID token to final network.

3 Likes

Burning MAID is undesirable IMO

2 Likes

That’s fine … but it doesn’t negate the proposal as a useful safeguard for those who swap maidsafe tokens for safe network tokens.

Subjective, depending on what your goals are. My goals are to use safe network tokens to upload data - and to make the network more attractive for users - hence increasing the value of the network and the tokens. Which benefits you too, even if you don’t convert (burn) your maidsafe tokens.

Not that subjective really. The main benefit of using a snapshot instead of burning is that the information on who holds what tokens can live in the SAFE network natively without the need for someone to custody the unclaimed tokens or feed the network with new info on which coins have been burned.

1 Like

Simply take a shanpshot of Bitcoin network at some block number. use that snapshot for crediting Safe tokens. No need for burning. Such snapshot can be used billion times again and again on any new safe network version. Burning should be avoid. Snapshot is the solution. And in Fat snapshot is superior from tax point of view. If I am credited new anonymous token than I don’t need to report it to the tax office. They have no way how to find out I received it or not. But when I do a burn transaction, I have to pay tax on it, sicne from Tax office point of view it is exchanging a token for token. And You still have an option to tax it if you wish, but you are hidden in case you don’t want to or can’t. Also anonymous coins will be very likely illegal soon. So burning is a proof I exchanged a coin for anonymous one. But snapshot avoids this. Noone can proof I received such coin. And I can just say, I lost my private keys so I couldn’t claim it.

1 Like

These new ethereum-based tokens serve only as a backup - they can’t be sent to the burn address for more safe network tokens (it would only accept omni-tokens anyway).

This makes a lot of sense to me and is really clever. Right now #MAID = 450M. Soon will be #MAID + #MAIDe = 450M (when ERC20 token comes along). When SAFE goes live and people start converting to SN then #MAID + #MAIDe + #MAIDeb (new “backup” ERC20 token) still = 450M. So all that would need to happen if the network is lost would be to allow conversion of all three of these to SN to re-constitute (or allow conversion of both ERC20 tokens back to MAID). The value of MAIDeb would be zero up and until the network failed and when it came back it would be equal to MAID and MAIDe. People could hold their own MAIDeb for as long as they feel they need to.

1 Like

I think the best solution is to expand the use case for MAID so that it can be applied any Safe Network version.

It’s this simple:

MAID is the genesis token of all Safe Networks initialized by MaidSafe or this community. The snapshot of the BTC blockchain that is used to seed the original Safe Network will be accepted for any resurrected Safe Network should a collapse occur.

2 Likes

I now understand that snapshot could be used for backup, so thanks … others said snapshot, but I didn’t know what they meant.

But … I don’t understand how burning from a wallet using a snapshot isn’t needed. How does this work technically. I have keys to access maid on omniwallet using snapshot of blockchain … I still have to send those to a burn address. Or are you suggesting something else? If so, how are omni tokens dropped into my safe account?

1 Like

It’s just like how you can see a list of which addresses hold which MAID coins in an Omni block explorer. This info can be recorded in a snapshot and stored in the SAFE network as genesis token holder information. Then you can claim your SAFE coins by providing cryptographic proof that you own a given address by way of a signature as per the procedure I outlined in the post that I linked above

3 Likes

It could be done entirely within the Safe Network(s).

Example Scenario: The user could upload a request to the Safe Network that contains a MAID address and a signed message by the private key for that address. The network would then credit the user a number of SNTs equal to the MAID. The address would then be added to a list of used up addresses and would be no longer redeemable (unless the current network died as was resurrected into a new one).

2 Likes

Okay.

Doesn’t this method make all maidsafe tokens post-snapshot worthless though?

3 Likes

I’m confused. How can a MAID snapshot exist on the SAFE network when we’re talking about recovering lost SN when the network goes down? Isn’t the creation of a backup token much easier, efficient, safe, and fair? What happens to transactions that occur between the time of the snapshot and the network failing (assuming it doesn’t take said snapshot with it)?

1 Like

It doesn’t have to - a snapshot is really just the a chosen BTC block number I think.

I think so … but still not sure what’s easiest.

1 Like

All MAID transactions would essentially cease at the time of the snapshot.

I don’t see them as worthless if they allow you a second chance should the first Network fail or crash for some reason and needed to be restarted.

Well, we can let the market decide that. Probably yes. If people think that the network will fail and a second snapshot may be required, or a competitor might honor MAID for the launch of their network then maybe the tokens would retain some speculative value. But the idea would mainly be that the value transfers into the SAFE network.

1 Like