Two way peg proposal

Feature proposal:

Make the software do two-way conversions of MAIDSAFECOIN (#3) tokens on the Bitcoin blockchain into SAFE coins on the MAIDSAFE network and back again.

This way, the tokens can be kept off the SAFENet in cold storage using any brain wallet, paper wallet, encrypted wallet.dat or other cold storage technique for the first few years of live action while we wait and see if SAFEnet is as robust as the bitcoin network at preventing thefts and double spends.

Having glanced over the excellent theoretical work that Blockstream is doing re: Sidechains, it is obvious that if Sidechains were implemented into Bitcoin crowdfunding of the type done by Maidsafe would allow this two-way peg with much less coding effort. However, beating them to the punch with an implementation of two-way peg using omni + SAFEnet would a great achievement for both projects.

1 Like

The amount of time it would take to implement something like this for a coin that is merely “oil” and not “fuel” for a software that is fighting really hard just to get to beta seems like a waste to try and “beat them to it.” We’re not ready.

Beyond that, Safecoin isn’t built on omni. Omni is merely the holder until the network is live. I’m not even sure that it would be possible to implement a trustless two way peg into the way that safecoin works. The bitcoin people would never trust it, even if it’s built into the software well because there is no “public record” of it.

Concept seems good on the surface, however, I don’t see if working at all in the long run.

1 Like

Seems like a neat idea. I think @dallyshalla is our man, what do you say?

We would need to have Omni involved. @eblanshey and I checked out Omni work, and it is quite a labyrinth. I’m more than confident that safecoin is sound and safe. I do not readily see the urgency here. You can also just keep your maidsafecoins as maidsafecoins if you are worried.

Though an interesting thought, that you are not alone in. Logically this is what someone would want to do.


So you plan on implementing the ability to exchange MAIDSAFECOIN (#3) tokens on omni for SAFEcoins indefinitely? How will the “traded in” tokens be distinguished from the “unredeemed” tokens? If there is no way to distinguish them, then there will need to be a hard redemption date, after which all exchanges between tokens on omni will not grant rights to redeem to new holders.

You understand the problem? I know I’m not being too careful in stating the problem.

If that problem is solved, seems that the flag could be toggled between “redeemed” and “unredeemed” on the MSC tokens somehow to make it a two-way system.

Safecoin tokens do not exist outside the safe network. The omni tokens are of no use inside the network (unless they specifically know it’s an omni token). There is no possible way for there to be confusion between the two tokens.

To redeem the token, you would send it to an address controlled by maidsafe. They will (most likely) destroy them (unusable address). I see this as a non issue.

The issue: Lack of trust in the safe, continuous operation of the SAFEnet code to safeguard the SAFEcoins of any one particular user account on the network from a long list of potential threats. This is a major issue, and the MAIDSAFE team will have to include a disclaimer listing some of the significant foreseeable risks when redemption code is released (see ethereum frontier, for example). Something like “sending your omni tokens to the exodus address may result in you losing all your coins”.

Easy, centralized solution: Have someone at maidsafe do redemptions and reversals manually. This is problematic, however, as that group, person or their security credentials, entrusted with the authority to perform redemptions and reversals can be compromised, resulting in a hack that could permanently harm trust in SAFEcoin and SAFEnet.

Difficult, decentralized solution: Have the code do it automatically, once the SAFEcoins allotted to the crowdsale participants are locked in to this solution, no person, group, or security credential will be able to access those SAFEcoins except those that send a specially encoded omni protocal message signed with MAIDSAFECOIN (#3) holding private keys.

But with a one-way automated solution, if a bug, hack, or other fixable compromise of SAFEnet is discovered after SAFEcoin live launch, and it seems more likely than not that this will occur, multiple times, there is no way for SAFEnet users to temporarily remove their coins from SAFEnet to the more secure and time-tested bitcoin blockchain using omni protocol.

This is the issue and why a two-way redemption / removal system is critical.

I may be missing something here but it seems like this is a proposal for a SAFEcoin paper wallet. I would think @dallyshalla would be who would address any concerns regarding storing SAFEcoin outside of the network. I do not necessarily see a need to make the SAFEcoins convertible to blockchain storage or protocol, but I can certainly see how offline cold storage would be beneficial.

As for the conversion of the existing MAID, I am unsure what they have planned as a protocol for the exchange to SAFEcoin, but I would agree an off-network storage would be a valuable tool once the conversion takes place.

1 Like

@mvanzyl I’d refer to this doc: by @nicklambert @dirvine and @qi_ma

And if you get to Section number 6: Minting Safecoin

“When Alice wants to mint safecoin, she sends a special request to Transaction Managers to create an open transaction without a designated recipient.”

When Bob receives the minted safecoin and decides he would like to spend them, he reads the
transaction name and the validation signature from the storage device and then sends an acknowledgement to the network.

Then there is a interface for dealing with minted safecoins to worry about, this is something to be addressed with hardware, and software.

Care to list some?

If the safe network works as planned, the coins work as planned. They are a data type. If you don’t trust the safe network to keep the files safe, don’t trust you money to it. However, if you trust it with all your files, the coins are fine.

In short, if the network works, the coin works. If you want to wait a while to transfer your omni token until the network proves itself, I’m pretty sure (needs to be confirmed) you can wait.

Your requests are absurd. Blockstream trying to develop the two way peg in bitcoin more than a year (with a $21 million investment) and you want Maidsafe made the same in a couple of month with the added difficulty of working on two unrelated networks.

And your centralized solution is worse putting in human hands the entire SAFE economy.

If you don’t trust SAFE keep your maidsafecoin but not expect the Devs waste time in your nonsense.

1 Like

As I understand it, to swap MAID for SafeCoins you send them to a particular address on the block-chain. In the event of a network-wide security disaster for SafeCoins, we could reset the network and start over with the initial MAID-to-SafeCoin distribution.


@Seneca that might need some custom engineering, because a reset would erase the on network identities. I guess code could be written to match a newly signed “this SAFE ID should recieve the MAID coins originally sent to burn address” message. Then users would need to send that message, signed to show they owned the original MAID.

So i think you are right, we can recover from a reset, but it would require coin owners to participate to reclaim their original MAID stake, and all on-network balances would be lost (farming earnings etc.)

I think we should test hard before allowing people to transfer MAID to the network because of this.


Good idea, but if people have traded them for other people’s stuff, reverting to initial state isn’t going to be suitable - at least not on a live system (fine for testing though, as long as participants understand this).

1 Like

What would be the alternative if SafeCoin security would turn out to be breached and SafeCoins would start disappearing en masse, completely breaking the system? I think fixing the code and then restarting with the initial distribution would be the least worst option.

Oh well, it’s probably a moot point, I don’t find such a scenario realistic at all.

I am not sure there is a good alternative. It is a situation we need to avoid at all costs once the network is live.

I have every confidence in the team to deliver on this, but confidence is sometimes only something which comes with time.