Crust Test v2 (concluded)


#203

This is what I was thinking. I agree that the MAID <-> SAFE conversion is not ideal, but it seems like the majority of early adopters will already be in crypto and this mechanism would help decrease the barrier to entry for them. It’s just an idea I wanted to throw out there again for discussion. I am open to being convinced that it is a horrible idea though.

For regular people not already in crypto, who will come later, keeping farming as simple as possible (or automatically baked in as an option to the browser) definitely seems like an easier/better way to introduce them to the (SAFE) new web/internet.


#204

I came in a bit sideways in that discussion, I hadn’t read anything else on the specific topic than jlpells post there actually, missed the whole part about LN etc.

I agree, that is not very far away in such case, and one less transaction on the path.
And also, I agree with an earlier point of yours, that this conversion is the big difficulty.

The point#1 was that there will be a conversion from MAID to Safecoin anyhow, so might just as well let that keep running, which seemed neat. But in light of the above discussion I wouldn’t regard it as the easier, or most capable solution.

My personal main point however, that this is something Maidsafe should do, not wait for the market to fumble with it, I still want to raise. The gateway to the network economy cannot be allowed the high risk of free for all, imo.


#205

I think it might be optimistic to see the burn process and an ongoing exchange gateway as similar technical challenges.

The former can be a scripted, even manual process with latency, and no reliance on a gateway server.

The latter is requires a permanent fully automatic process, that can’t easily be decentralised to protect it from interference, unless somebody has some bright ideas. I think it’s a mega project in its own right, but I’d love to be put right on that. It is an interesting idea, but I don’t see it as achievable in a shortish space of time.


#206

No they are not requiring the same technically, never considered them such (don’t think jlpell did either), think we even alluded to that it indeed is extra work. And not easy thing, on the contrary quite complex. Why is just why I would want MaidSafe to take the rudder on such a thing.

I was basically agreeing with that the additional work could be worth taking for the gains - given that there actually is a good solution for it.

I’m quite well aware of the difficulties with a decentralised transactional feature on SAFENetwork, since it’s been one of my main interests and discussion themes here :slight_smile:


#207

Yes, I’ll agree it may be a bit too optimistic depending on how sophisticated the original burn idea was.

Yes, brainstorming is a pretty low cost endeavor. Probably best left for a separate thread. Cheers.


#208

My preference for BTC<->SafeBTC over Maid<->Safecoin is not only for utility reasons but, as far as I know, for the lack of multisign transactions within Omni layer. If implementing bidirectional transactions, between the BTC blockchain and Safe, are already an extremely difficult task, doing it without multisign transactions seems to my impossible.

More than three years ago I raised, in a Spanish forum, the possibility of the existence of SafeBTC as altcoin in Safe. Since then, I keep thinking about it from time to time, and, truth be told, I still can not find a theoretical solution that meets the required security levels in a decentralized manner.

If the conversion BTC->SafeBTC and SafeBTC->BTC are possible, the critical point is who and how the BTC private keys are stored and managed and how a BTC transaction is signed without the private keys being leaked. If someone solves this points the implementation of a decentralized conversion is perfectly possible.

Among the different solutions that I have thought of, is to divide the private keys into different groups. Encrypt the private keys and keep the private and encryption keys divided into different groups and use a third group to regenerate the private key at the time of signing. Use the Shamir Secret Sharing Scheme to divide this keys between several groups, etc., etc… But in the end they all collide with the fact that one or several strangers, who are not reliable, must sign the transaction which gives them access to, at least, one of the BTC private keys.

Maybe someone intelligent and with extensive knowledge of the BTC comes up with some solution @mav :wink: