Project to massively increase SCRT value

Hi Everyone! Now that I have your attention, this post is not short, but neither is the title misleading. I genuinely believe there is enormous potential here. Please give it a read and let me/us know what you think.


Background
I’m leading a project with others in the community, and we want to gather feedback on a future SCRT community spend proposal. Over that past few months, we’ve finalized details and are looking forward to building in earnest. We feel that the success of this product will have a huge impact on both the Enigma community and the value of SCRT tokens.


Proposal
Enigma is creating the framework for private blockchain transactions, but the community will not grow until apps are using that framework. What better place to start than private key management? There are many private key storage options available today, but they all share one problem - a single point of failure. Private key distribution is a revolutionary way to store crypto assets across multiple devices, even untrusted devices. It is more secure and more convenient than any other option.

How many stories have you heard about someone losing millions worth of crypto? Securely storing a private key is complicated and tedious, even for the most technically savvy people. There are numerous backup options, but even the most advanced options still have a single point of failure. The wrong mistake might mean the loss of everything. Take the mnemonic phrase backup strategy. This tool is useful if you lose access to a personal wallet and want to recreate it, but it is still a single point of failure, not to mention a large vulnerability. What happens if you lose your backup phrase? What happens if it’s stolen? No matter how you store crypto, there are critical points of failure with each option.

Maybe you’ve decided to go a different route and store your assets on a cryptocurrency exchange instead. Surely they have better security practices. They must be better than they were in the past, right? Probably, but let’s not forget one important point. When Mt. Gox was hacked, the first thing they did was stop withdrawals. Even though funds were still available, owners got nothing because Mt. Gox “said so”. Hacks still happen all the time. Exchanges make mistakes too. When that day comes, don’t act surprised when the exchanges take care of themselves first.

Regardless of where you store your cryptocurrency, all solutions have problems. You can manage the crypto storage yourself, or you can give up control and put your trust in an exchange. Either way, if your choice fails, you’ve lost everything.

The answer is to split and distribute a private key across multiple hosts. By storing private keys with multiple parties, we can ensure they are never lost, never stolen, and most importantly, always in your control. We can split a private key into shares and distribute a single share to each host. A single share or even multiple shares does nothing until a minimum number of key shares are combined. This framework means keys are never lost, and never stolen unless the entire network is compromised (even then there are safeguards). You can have the benefit of truly secure key management while retaining control of your assets at all times. You’ll never have to trust a third-party again.

A solution like this benefits everyone since it works for every cryptocurrency. It’s a universal solution! It is as easy as the best options available today and more secure than any of them. It embodies the culture of the crypto community by returning control back to the owner and eliminating the centralization of wealth that plagues all modern financial institutions, including cryptocurrency exchanges.

Specifically for SCRT token holders, this product will bring astronomical growth to the community. By using Enigma to store the wealth of Bitcoin and other cryptocurrencies, we will increase network usage and valuation by many orders of magnitude. Enigma’s protocol is making the next generation of blockchain applications possible; we are making that possibility a reality.


What’s next?
Currently, there is more than 550,000 SCRT in the community spend pool. These funds are set aside for “improvements to the community” in whatever way the community deems appropriate. Some of the funds are earmarked for the ENG-to-SCRT conversion, and we can all agree that is the most important task by far. However, there are still funds available, and we feel this project is an excellent use of those funds.

Many of us are working on this, but we have full-time jobs that take the majority of our time. We want to put 100% of our efforts into this, so we are here asking the community to make that possible. If approved by the community, we calculate that this will require 400k SCRT and six months to complete. It is important to note that this request is a grant-like proposal with SCRT paid upfront rather than a bounty-like proposal with SCRT paid upon completion. This option allows us to incentivize the right people and is similar to other grant-like funding where funds are given upfront with the expectation of future returns. The returns, in this case, are the growth of both Enigma and SCRT. All code developed with these funds will be open source and available to the community.

We are looking forward to hearing everyone’s thoughts and are excited to be here, at the beginning of the SCRT era, just waiting to take off. :rocket::rocket::rocket:


TL:DR - We have a plan. Vote to invest 400k SCRT in that plan, and we will not only build a product that benefits everyone in crypto but will also move the decimal point of SCRT a few places to the right. Please join the discussion and provide your thoughts! :rocket:

6 Likes
  1. I don’t like paying anyone upfront for something that is just and idea at this point. It is not guaranteed to work.

  2. First build an MVP, have the community test it out, and then the community can vote on whether or not to fund the project

  3. How are you going to prevent the host who holds a portion of the key from holding the keys hostage? These hosts will possibly hold a portion of keys that are worth billions of dollars. Even if they don’t know who’s keys they are, they will still be able to hold those keys hostage. How do you prevent that?

2 Likes

Hi Joe,

Thank you for the well thought out responses, I’ll respond to each one individually.

  1. I assure you this is more than an idea at this point, but I understand it’s hard to take the word of someone on the forum. I’m happy to provide more information and any specifics that the community wants.

  2. The problem with a security-centric application like this is that the MVP must often be a robust product. We’re happy to build out functionality to test it out and earn the trust of the community but what specifically would that product be? You see the problem?

  3. We can get around the problem of non-participating (or actively refusing) actors by distributing the key further. The algorithm we are using (threshold signatures) is an m-of-n signature scheme which allows for a variable threshold of actors needed to sign a transaction. For example we can lean toward high-avaialbility and only require 1-of-5 key shares to sign a transaction or we can add more security with 3-of-5 or 4-of-5. The problem with a non-participanting actor is only a problem with 5-of-5.

1 Like

Hi Derek,
It is very good that the collective members already have their own projects.

About the idea:
With the growth of crypto users, the number of cybercrimes and theft of cryptocurrency will increase. Therefore, such solutions are very necessary and will be relevant.
Project focus on 100% relevant user group (all crypto-holders). These users are already in crypto. This is a very important point. This could potentially create a huge influx of users into the Enigma ecosystem;

Implementation:
I would like to see a detailed plan, developers and those responsible for implementation /stages/deadlines, etc.

Ready to support after I see more information.

2 Likes

If you want money from community pot start out by:

  1. Start a github with open source code and show Verifiable and auditable progress

  2. Start a roadmap and annotate the amount of money that you will need at each milestone. Once those milestones have been reached and audited by the community, you will get a portion of the amount you are requesting upon vote by the validators.

  3. Also Provide a monthly detailed and transparent p&L to the community.

  4. Definitely should not get all the tokens up front. That is a bad precedent for the future.

5 Likes

Agree 100%

Only thing I would add is, if it’s community money, we need a detailed And transparent p&l on monthly basis to track where the money is being spent.

2 Likes

@Derek,

This is exciting. I would like to echo the feedback around clear timelines / milestones and some progress in a github repo.

I have some questions / feedback about the idea:

  • How do you envision the data flow? I upload my private key to a secret contract and the secret contract takes care of sharding the key across the network with some redundancy?
  • Currently there’s one encryption key that’s shared by the network. This means if someone is able to hack into one of the SGX devices, then the attacker can have access to keys. While SGX attacks are mostly theoretical, depending on the amount at stake may become more relevant.
  • The best way to do this would be to implement a MPC scheme that can run and shared the keys before they are in the secret contract (Reduces vulnerability raised in the point above). However that may be an off-chain computation network. If you are doing that approach, then I am not sure if you need the Enigma blockchain

@guy curious to hear your opinion

1 Like

@anon60841010 @Cryptojoe @CryptoGrizzly

Open code and auditable progress

Diving into coding and putting in github is our next step, especially now that we’ve worked through the high-level architecture. Some are eager to get started and I don’t blame them, but I’m focused on project planning so we have a clear direction and achievable/accountable goals.

I agree with Moonstash that a project of this complexity doesn’t have enough legs with hobbyist coders. When choosing between tangible code and a delivered product, I lean towards the product. The code is useless by itself if there’s no product behind it, and I believe the primary motivation for SCRT holders is the increase in SCRT value. Funding up front is essential to build a core team that is capable of delivering and maintaining that product.

With that said, I’m not coming to the community hat in hand, asking for a handout. Moonstash and others can affirm that we’ve always planned on having a group of trusted community members overseeing the project and controlling the allocation of community funds. This helps streamline discussions and funding plans, especially when parts of the project do not go as expected. It also has the added benefit of unbiased communication from a non-invested party. Working with this oversight committee, we can meet the communication requirements and expected milestones of the community. If we don’t satisfy expectations, the oversight committee can return funds to the community pool, burn them, etc. I think this is the best middle ground that meet the needs of the community while also allowing this project to thrive.

Here is a high-level Gantt chart that gives some insight on timing and potential deliverables.

In summary, yes, we’re asking the community to take a chance on this because we believe the risk is worth the reward. We’re not asking for all funds paid upfront, we’re asking for the allocation of funds and some funds paid upfront to get the project started.


Technical questions
@can

These are my type of questions!

I envision the data flow using threshold signatures where each actor in the system generates their portion of the key, and we generate a full key from participant shares. In this scenario, the user must transfer funds to the new key, but it’s a safer option since the entire key is never available in its entirety. We could theoretically split an existing key, but that invites a whole set of problems with secret sharing and isn’t the best option.

The security of SGX is a concern that is not going away anytime soon. Modern-day thieves can still crack the top-of-the-line safes with enough determination. The security of the system will always be in question until enough redundancy/separation is acheived such that a broken SGX enclave is not a problem. Even then, the network is itself a single point of failure due to potential problems in the communication layer, storage layer, etc. We can protect against all possible failure points by building in additional redundancies beyond just the network by utilizing other actors like client computers, trusted key store services, or even other networks.

I agree that never having a full key inside a secret contract is the way to go, which is why we would utilize threshold signatures with distributed key generation. However, a privacy-preserving network like Enigma is still required since we need the security of SGX to protect against collusion.

4 Likes

@Derek,

It’s great to see that you’ve put a lot of thought into this. I am curious to see how the system comes together. Say Alice wants to use this contract,

Does she define the thresholds (k of n)?
Does the entire network participate in the signature generation or only a subset?
What are the crypto-economic incentives in play?

I think it would be interesting if say 10 participants can store certain information out of the network and would combine that information with some threshold keys that are stored in the network such that without Alice’s request the information stored in the SGX cannot be accessed by the participants to collude, also if there’s a network vulnerability Alice’s funds are not directly at risk

I am excited to see an architecture document around this idea

2 Likes

@can,


Does Alice define k of n?
That’s not the plan for the initial product. A more advanced product would allow for a sliding scale of security vs availability, but the first product would need a hard stance on security until the system matures.


Does the entire network participate in signing?
I don’t see a need for this. It would be a rare case where a node does not sign a transaction or maliciously signs one. In those situations, other non-network actors can provide their signature share and achieve the required k threshold.


What are the crypto-economic incentives in play?
Keep it simple. I see a need and demand for this security and usability. I believe users are willing to pay for their peace of mind and will happily pay a small service fee to cover the cost of operations.


It would be interesting if say 10 participants can store certain information out of the network…I am excited to see an architecture document.
I’m glad you asked. This document covers 3-of-5 network architecture that can survive the permanent loss or corruption of two key shares. I see this as a solid base level of security. We can build on top of this base (i.e. add more actors) for enhanced security or availability.

3 Likes

This architecture looks interesting because Enigma network hack alone doesn’t jeopardize the funds (assuming we have a 3/5 scenario). It’s exciting for us to support his development / ideation process because:

  • we can come up with a good solution to expand the scope of access control (from digital content to keys)
  • usage / utility on Enigma from users of other chains
  • potential to scope a milestone based grant approach (testing) for further empowering community based projects

Also sharing some feedback from Guy:
This is really cool. So essentially, use secret sharing, and then use Enigma as a safekeep of one of these shares. Even if it’s somehow hacked, it doesn’t increase the attack surface by much, and the liveness guarantees are incredible.

One potential improvement/concern is Proactive Secret Sharing, which basically means refreshing the shares of the key every once in a while. This is important for to reasons:
1. If one or more shares are lost, then you want to be able to generate new shares, and potentially share these lost shares with others. For example, say Bob is no longer a trusted party and his share is gone. We may want to be able to re-share such that everyone ends up with a new share + Charlie (a new party) receives the new share instead of Bob
2. Higher security - harder to compromise all shares because there’s a time duration in which you have to do it.

This might be more complicated (but I still believe is very doable) with Enigma as opposed to an off-chain protocol

4 Likes

Great feedback @can and @guy!

The idea of Proactive Secret Sharing is really great and addresses a significant scenario that’s likely to happen.

I’m super excited you guys want to participate in the development / ideation process too–that’s critical to the success of the Gridlock project.

3 Likes

I’ll second @Laura having the technical backing from the core Enigma team is valuable beyond measure. We certainly have our work cut out for us, but we are excited to get started!

Right now, we are working on architecting the details of the product and underlying protocol. Once that is done and it has been vetted by community experts, we will proceed with a request for community funding in whatever form makes sense at the time.

If anyone has thoughts, concerns, or suggestions, please post them here or DM me if you want to have a more detailed discussion. I’m always available to chat.

3 Likes

Hi Everyone,

We’ve put together a draft proposal for community funding. Please review and provide feedback here or in the chatroom.

Draft Proposal
Chat Room
Whitepaper

4 Likes

@Derek, I am excited by the idea of Gridlock. this is a good product idea and I appreciate that you provide a budget with numbers to be discussed on the forum! I like the fact that Gridlock enables Enigma protocol to be used for other crypto networks. Please refer to this post to see my general feedback. This will be useful before a governance proposal submission.

Specifically about Gridlock:

  • Milestones and more clear timelines will help
  • This sounds like a for-profit idea. See my comment about seed-funding vs. what’s required to get teams going
  • While you’ve identified a good pain point, how you’ll execute on this is missing. What’s success for Gridlock, how do you plan to get there, what milestones will you achieve to de-risk the success of Gridlock over time?
  • We should welcome more feedback on crypto side of things. cc @guy I think it would be very helpful to see a PoC or a demo that uses secret contracts (when they are ready) and show that the team will be able to pull this through before the network grants you the funds
  • Is the team expected to be full-time on this?
6 Likes

Hi @can ,

Thank you for the detailed feedback. I did not realize that you had posted your new thread when I added my last comment but interestingly enough many of the ideas fall in line with your post.

You laid out two primary ways in which to acquire funds. My proposal fell into the second bucket, which was the inclusion of a neutral third-party. The obvious candidate is the Secret Foundation, which is purpose-built to benefit of the community and is assumed to be a responsive partner for community spend projects. The incubator of the Secret community, if you will.

However, it appears that the foundation does not yet exist and therefore cannot act as a neutral intermediary. With that in mind, I think it makes sense to follow your second suggestion of smaller funding amounts with an upfront payment.

I’ve addressed some of your points in-line below:

Milestones and more clear timelines will help

The Gantt chart has milestone targets but they are somewhat buried in the details. The proposal’s deliverables do not necessarily match to the milestones in the Gantt chart. This was not meant to confuse but rather the effort required to match the two lists was not necessary if we were working with a neutral third party. Put simply, the community cares about the deliverables, the foundation cares about the milestones (for accountability). With a switch to the alternative non-Foundation funding option, I presenting the following milestones.

The proposed timeline spans six months from the beginning of the project with the following milestones.

  1. Project approval by the community
  2. PoC client, communication router, and secret node infrastructure
    2a. The purpose of this task is to build a framework that makes the entire project possible. It is very likely that we will work on additional, more complex components in parallel, but this framework will take priority and be the first to complete, demonstrating a representative sample of the work to come
  3. Key distribution algorithm, Advanced router for key generation and signing, completed secret contracts with key generation functionality
    3a. This is the meat and potatoes of the project. The deliverable from this milestone is a working alpha
  4. Integration and testing, finalizing minimal functionality, and setup documentation/infrastructure for additional network devices
    4a. The deliverable for this milestone is a product ready for public use

Expanding on your suggested division of funding, I think the following distribution should be used. 25% of funds are issued up front, 25% after project completion, and the remaining 50% is split into milestones. With 4 milestones (counting the proposal) funding is split into quarter increments.

I suggest the total funding for this proposal is 320k SCRT, divided into 4 equal distributions of 80k SCRT each.*

*Let’s not forget that at current community pool funding rates, 80k SCRT is accumulated in just over 5 days. It takes longer to pass a funding vote than it takes to recoup that expenditure.

This sounds like a for-profit.

There are ideas for future revenue streams but that is outside this project. There is clear value to the community in terms of SCRT usage and external attention. We ALL benefit from a larger community. Additionally, the proposed deliverables will be open-sourced and available for use by anyone. This is especially important because this project directly improves the security of Enigma and having open-source code will have exponential benefits as the core framework is adopted.

What’s success for Gridlock, how do you plan to get there?

Short-term success is the completion of the project. We plan to implement the architecture presented in the whitepaper with currently active members @danmarz @laura @Franklin @Avret and new developers, keeping on task with the project plan presented. Future success is outside the scope of this proposal, the community benefits either way.

Is the team expected to be full-time on this?

Yes, I think this is important for continuity of development efforts. At least some developers should be full-time; otherwise, projects can stagnate. This is one of the main reasons why full up-front seed funding is important. Skilled developers are already hard to find, and that only becomes more difficult with when looking for niche developers skilled in distributed systems, Rust, and cryptography. Trying to maintain a cohesive and static dev team with breaks in funding is difficult and trying to convince people to work for the possibility of funding is out of the question.

I think it would be very helpful to see a PoC or a demo that uses secret contracts…

The new milestone-based approach aligns with this sentiment.

We should welcome [Guy’s] feedback on crypto side of things

I am both excited and nervous about Guy’s feedback. @guy call me! :smiling_face_with_three_hearts:

3 Likes

Just so everyone knows: I’m an advisor/protocol helper on the team, y’all know my credentials

7 Likes

Hey guys! I’m a dev on the project. Have ~2 years of full stack (node&react) experience building blockchain PoCs at a consulting company. Really excited at the possibility to work with the community!

6 Likes

I have a few questions:

  1. What is your itemized plan for using the 320k SCRT? Who are you paying and how much?

  2. At current enigma prices, your rate is about $80,000 for the project. Prices are currently at the bottom of the barrel. Your project will take at least 6 months to complete and with the swap coming, it is likely that SCRT prices will hit $1.00. A $320,000 price tag for this project seems excessive. With that in mind, what do you say is the dollar fair market value for this project?

  3. In alignment with what Can said. How are you personally going to general profit from completing this project.

  4. Disclose all your conflicts of interest.

Thank you for your submission and attempt at contributing to the project and community. It looks promising.

1 Like

Hi @Cryptojoe ,

Great questions, thank you for keeping the conversation going. Here are my responses

1) Regarding hours

The only honest thing I can tell you with regards to cost estimate is that it’s too chaotic to tell. https://ask.slashdot.org/story/17/04/26/2040212/ask-slashdot-are-accurate-software-development-time-predictions-a-myth

I could, for example, provide granular hours estimates which will invariably be questioned. What then? We could adjust the delegation of hours to satisfy specific grievances, but at the end of the day, it’s just another estimate that is little more than a guess. If that’s what the community wants, then I guess we can go down that route, but I see it as a futile exercise.

I believe the whitepaper explains the architecture sufficiently such that anyone with an understanding of the Secret network can have a general opinion on the level of effort required. Is this an incorrect assumption?

2) Regarding price
If we took this project to any large organization, the proposed cost would be at least $1M - for a prototype only. My goal is to build the product for half that price which already bakes in a lot of hope that SCRT will increase significantly in value. I would be much more confident with 1M SCRT and thrilled with 2M SCRT. That level of funding does a lot to overcome the risks of price uncertainty and volatility.

What is the correct price target anyway?
Prices are lower, yes. ENG is half of what it was valued at in February but that was based on a completely different tech stack. A lot has changed since then. While we all want the same thing for ENG (and presumably SCRT), we cannot know the value of a coin months or even weeks away.

What is backing your claim that SCRT will likely hit $1.00?
The last time we saw ENG at a dollar was two years ago, coming off an insane high from the previous bull run. If (cross your fingers) SCRT spikes to $10 then you certainly won’t see a second proposal, you’ll see a completed product. If SCRT dropped to ENG prices mere weeks ago ($0.08) then, unfortunately, there will be another zero behind the next proposal.

3) Regarding personal profit
Is it not enough to claim community growth and attention as a driving force? I believe the offer that I’m bringing to the community is transparent, both in what I’m proposing to build and the expected return to the community.

If you are asking for my future business model, I can not speak to the specifics of that because I simply don’t know. The goal for the future is first to develop a user base and then identify avenues for profit, sticking to options that maintain the ideals of the company, which are security and privacy.

4) Regarding conflicts of interest
This is a for-profit venture. That is the only thing I can think of which might be considered a conflict of interest. However, the clear fact that this is a mutually beneficial project and the commitment to open-source code should make that a non-issue. I think there is room for everyone to win here.

2 Likes