Proposal for Encrypted Distributed DBC's (now with poll)

Features
,
42

yes, it is certainly a different mechanism than farming, with different incentives.

Perhaps it could somehow be combined with farming, eg the decryption key must match hash of a data chunk that a farmer can prove it is storing. (So only farmers can participate)

Though possibly this just creates an incentive to store (spam) random data on the network in order to generate more “lottery tickets”. Which would be limited to an extent by PUT fees.

4 Likes
43

This is along the idea of mine to have the adults do the calcs. I would think though doing it according to the hash might be hard to engineer into the algorithm. The adults ID have the beginning bits the same as the section ID.

Maybe using what you said (and trusting the foundation) the box is locked with the hash of a certain data chunk. The foundation simply stores that chunk and the farmers will check if they can unlock a box for the section to add to the section’s pool.

Of course one has to trust the foundation to keep these chunks secret (security issue). But even if they are uncovered they can only benefit the section it was destined for.

Thus the encryption key could be Section ID & chunk hash. Thus only the DBCs destined for that section can be unlocked when chunk is stored.

To solve the chunk being stored early (chunk for lower level section), since its possible someone may store that chunk before the foundation (by chance) the foundation simply stores the chunk again and this triggers another check even though the chunk is not actually stored.

This also solves the compute problem since its only checking if a box can be unlocked.

So upon genesis the DBCs are created according to the pre-encoded DBCs encrypted with SectionID&chunk Hash.

  • estimate how large the section ID will be in 5 years, no need to be accurate just a good estimate
  • DBCs for sections with longer IDs contain less SNT each level till almost nothing at the section ID length after 5 years of splits.
    • for security the low number section IDs do not have locked boxes to open. The network should be at level 3 or 4 very quickly, so maybe start the encoded DBCs for section ID size of 5 and up (around the 32 sections)
  • the reducing SNT means the effects of the additional SNT will be almost non-existent in year 5
  • No real compute power needed for cracking as its not cracking really, but measured release without any entity holding large bags of DBCs
    • exception is when the network is small, but it can be monitored and canned if a problem and the SNT cancelled on the markets. But if only start the DBCs at level 5 then this should not be such an issue. Major issue still to relist a new SNT but since SNT can only live on the actual Safe Network running, a complete new start of the network automatically makes the previous DBCs useless.

Problems

  • Foundation will have the chunks to upload (or HD algo to create them) and possible problems.
    • this is mitigated by the fact that the network cannot unlock a DBC that is not destined for that section
    • This is no more an issue than an insider steals some of the 70% held if no locked boxes.
  • Involvement of the foundation which seems something some people are not comfortable with. But I counter that with the foundation can cause problems through many mechanisms including cheating on genesis, fiddling the dev rewards, having core code cheat on rewards and amount given to foundation for dev rewards etc. And done in a way that is not easy to find in the code and say oops if found.
  • ???

Benefits

  • not mining in any possible definition.
  • simple checking if the hash of stored chunk against DBCs for that section ID. No mining/cracking encryption without associated problematic government/power/type-of-network issues.
  • timing of the release can be under human oversight based on how well the network is doing
    • alternative simply on a timed basis set by policy to be adhered to by the foundation (legally enforceable)
  • Very even distribution specified by foundation or everybody prior to launch
  • Even if chunks used is exposed the DBCs can only be unlocked once the section is created by the splitting of the previous level section.
    • this may require the encryption of the DBCs to include a 3rd factor that only can be found by decoding the previous section DBCs
    • maybe the most difficult thing to work out. and a possible negative.
    • one solution would be that the whole chunk (for each chunk) is not held by one person, but held by a few different people. Rather like a n of m situation where these people would have to agree to store the chunk.

Well if it only means the section gets a bigger pool sooner, then the algo for release would mean it doesn’t get released much faster, just a little earlier.

EDIT: One thing that may help security wise is that the DBCs are additionally encrypted at genesis by the genesis section elders with n of m key and when splitting the collection of DBCs for one branch is re- encrypted with that branch section elders keys, and same for other branch. This is done on each split.
Thus the adults do not actually test decoding the DBC box(es) but the elders who use their n of m key to first get the locked box(es) for the section to check. This prevents any adult splitting the DBC before the elders can.

1 Like
44

How would the numbers be set? I mean it as a genuine question. Would there be some initial benchmarking and extrapolation?

1 Like
45

In general for this proposal, yes. Before that new target(s) have to be identified - e.g. idealized mining release schedule.

47

I think you make good points here but they’d be better in the RFC topic as this one is about a specific alternative.

48

Good point - I reposted on the other thread - thx.

1 Like
49

This prop isn’t really an alternative to the RFC … more of an add-on, or just something separate altogether.

1 Like