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

Features
,
1

Origin post:

This proposal is specifically to deal with the remaining tokens (hereafter rDBC’s) after other initial distributions. This proposal has nothing to do with all the other pre-mapped out initial distributions: RFC 0061 — Safe Network Token Distribution

These rDBC’s constitute the BULK of ALL DBC’s – 70% !! It is a huge number and a huge risk for any entity holding them as it will surely be attacked.

The general idea here is to neutralize the bulk of rDBC’s in a way that prevents them from being dumped into the network and used all at once. This isn’t specifically a method to mitigate the theft of tokens (it may help with that but that’s not the main point here) - it is a means to prevent rDBC’s (stolen or not) from being dumped onto the markets all at once and breaking/crashing the price of SNT’s and possibly causing serious damage to the network.

This proposal is something novel - not section lockbox’s, which would still be attacked and would make the network a giant honeypot requiring additional security that would be subject to future SN developers and hence not just potential pre-existing flaws but future flaws as well; but instead:

1.) upon creation of rDBC’s, they would be encrypted in a weak (hackable), yet ASIC and quantum resistant, layers, using multiple (off-the-shelf) encryption algorithms, one wrapped over another with an identifying header attached to the outside of each encrypted layer.

DBC → layer1 + header → layer2 + header → layer3 + header …

2.) encryption bit size can be variable allowing some rDBC’s to be quickly and easily hacked with others being very difficult to hack. In this manner we can adjust the release curve to whatever is desired.

Using multiple layers is important as it increases the time it takes to hack the DBC free and very importantly, using several different algorithms makes hacking resistant to future hacking shortcuts and any potential bugs in a single encryption algorithm.

3.) rDBC’s could be:

  • a secondary (additional) airdrop to MAID and eMAID token holders. E.g. burn the MAID/eMAID and receive both DBC’s and rDBC’s into your specified SN account.
  • Or they could also be held by the network and distributed over time. Less of a honeypot as they would have no value until cracked open so even if sections were able to be hacked, it wouldn’t radically affect the market for SNT’s.
  • Or they could be held by the foundation - but still a point of centralized control.
  • Or some combination of the three above.

Benefits:

1.) rDBC’s can’t be dumped onto the network as payment for data storage immediately, they must first be hacked-open. So the price of SNT’s can’t be manipulated if a large theft occurs.

2.) Reduces the honeypot attack vector of sections holding tokens or of a centralized possibly political body (a foundation) holding rDBC’s as they have no value until cracked open and cracking them open takes a lot of work.

3.) Auto-magically (because of free markets) reduces SNT volatility. As the price of SNT’s go up, there is more market incentive to hack open rDBC’s. As the price of SNT’s goes down, the incentive decreases and less rDBC’s are hacked open.

Drawbacks:

1.) Finding the best methods of encryption would require some amount of R&D - I’m not an encryption guy, so don’t know what that might look like or how long that might take, but alternative proposals will also take time to R&D, so moot issue IMO.

2.) ??

Notes:

  • In the origin post I proposed using a variable strength encryption algo and I now think that was a bad idea as it introduces a lot of complexity. The idea in general was that it would make it more difficult for tech innovation to hack rDBC’s open, but I think it’s unworkable. Better to have specific layers/wrappers of encryption. So hacking can happen in an orderly fashion.
  • There can’t really be a secondary market for these encrypted rDBC’s because no means of proving the backing (what’s inside) without unwrapping it first.
  • I may update this OP as the thread progresses.

POLL

Where do you stand on this proposal? (You can change your vote - remains open indefinitely)
  • Love it - just do it!
  • Interested, but need to know more
  • Too many issues, questions, problems to work - just don’t do it.
0 voters
4 Likes
2

How layered encryption might work:

DBC → layer1 (add unencrypted header) → layer2 (add unencrypted header) → layer3 (add unencrypted header) → layer4 (add unencrypted header)

The header is needed so that a successful layer hack can be verified.

EDIT: critical info related to method for cracking the layer can be added into the header.

All algo’s are public (should be well tested and known standard encryption algos) and the order of encryption-method used in each layer is public. So the hacker knows how to hack each layer. All they need is hacking algos, time and energy and we can pre-estimate how much time/energy this will take at launch, although it will get cheaper to do so over time.

For those who prefer the increase in tokens from the rDBC pile over time, then this is a plus. Some would like an invert of that release curve with more released in the beginning - so this is a negative. I’d personally prefer a linear release over time, so this is a negative IMO … but you can’t have it all I suppose.

Edit: with variable bit level, release curve can be adjusted to whatever is desired. So you CAN have it all after all!

3

Many crypto projects hold huge centralized bags without issue. Most losses of such bags are an inside job. For me personally, there is no evidence that the Safe Foundation is a riskier option than the proposed option.

20220704_103353
20220704_1033531920×3669 550 KB

Privacy. Security. Freedom

3 Likes
4

… and yet some have had major issues. The longer the pile exists and the greater the value of that pile, the more the risk.

At this stage it’s theoretical. If SNT’s don’t have much value over time, then the risk remains low.

This proposal aims and reducing attack surface area only. If there is no motive or incentive in the future, then there is no reason to do such. On the other hand, if you think SNT’s will have a lot of value in the future, then reducing the attack surface area is important.

If I stack my bricks in my front yard for use later, not a problem. If I stack gold bricks in my front yard for future use … could be a problem.

@Dimitar - I have modified the OP now to include other options and to further explain.

1 Like
5

Bravo for putting forward an idea to reduce a significant risk and explaining in detail the key points as well as starting to look at the pros and cons. I think it’s worth digging into so we can compare it with alternatives, so first digging in a bit.

pros

I think if this worked as hoped you’re right that it could reduce the chances of a big hack, which would be the main reason to favour of over alternatives, though they may have other benefits to be considered such s flexibility to deal with unanticipated issues.

cons

The drawbacks I see are more extensive than listed. Here are my first thought concerns:

  • It may fail in its goal. Success hinges on it not being broken, either due to a bug, or innovation by a well funded, it just plain lucky group of individual. Whether using ASICs or other costly approaches such as massed cloud algorithms, we would need to be very sure that those risks were unlikely because once something like that occurs it becomes easy for someone to milk the entire supply, not just that held by one section (of many). The all or nothing aspect of this risk may be enough to eliminate it unless it can be designed in a way that prevents this. As if that’s not enough, once this is deployed there will be no way to bugfix it - the DBCs will be out there and can’t be taken back - so you have to be very sure it has been implemented correctly and that the design itself is guaranteed to do what is intended.

  • Insider risk. As with a Foundation, this is vulnerable to insider risk. A small weakness deliberately introduced in the implementation, or spotted but not fixed during development by an unscrupulous person could be exploited later and little if anything could be done to stop this even if it was detected. The same applies to all the code in theory, but is much more critical here because of the all or nothing risk of this solution. It’s much harder to do something like this in any other part of the code because it is decentralised, and distributed to minimise the kinds of risk. With a Foundation, there would be mechanisms to deal with insider risk, so this a point to compare with that, and with any other alternatives. We may have an inherent distrust of humans in positions of power, but that’s about systems not just the people in them. We also have a proven bias towards trusting computers so everyone should be aware of that when judging those two approaches.

(I could point out more technical concerns but they’re essentially of the same nature, such as effectively inventing an encryption algorithm (layers) rather than using something off the shelf, but perhaps these all or nothing risks could be mitigated. For example, by combining with a section based mechanism that means that farmers can only find DBCs according to their current section? I don’t immediately see a way to do that, but use it as an illustration of mitigating this risk by reducing the size of the ‘prize’.)

  • This is a proof of work approach. Just the label is a problem since even if we could argue that it’s different in this or that way to Blockchain PoW it undermines one of the most important differentiators we have with Blockchain: energy efficiency. It would be hard to convince anyone who thinks badly of PoW that this is different. There are more issues with this such as convincing people that it won’t be subject to the other drawbacks with PoW such as centralisation of distribution that is determined by power/money.

  • It’s hard to create a better PoW distribution mechanism. I think it will be a high bar to improve in existing PoW mechanisms, ensuring widespread distribution without giving advantage to those who already have disproportionate capability and resources. That’s what this requires. Many people have been thinking about ways to improve PoW or get rid of it because of its drawbacks so I think it’s very ambitious and so would require significant technical innovation. If it was achieved, I think the applications would go far beyond SN.

6 Likes
6

This is addressed by using different encryption methods for each layer. Of course something could always go wrong, but the same is true for the network as a whole and this proposal is a much simpler than SN as a whole.

FPGA’s and ASIC’s that perform one decryption method can’t be easily developed (costly) and complex one’s would have to emerge to break multiple levels of different encryption algo’s – so super costly to develop. Having multiple layers really hardens it against this method of ‘mining’. I imagine that in 20-30 years and with the value of SNT’s is high enough, then they will exist, but just as with bitcoin mining, it’s not the end of the world - even less of a trauma for SN as people mining SNT’s can only reduce the price for SNT’s in the market - they are not actually running the network as bitcoin miners do with the bitcoin network.

I’m not sure how this applies specifically as it’s a risk for any solution. And what is proposed adds to the hardness of the problem for any insiders.

Also, this idea doesn’t preclude the Foundation from holding and mining these themselves (or distributing them unmined) – so this proposal actually IS such a mechanism to deal with insider risks by making it more difficult for them.

The layers are very simple and no encryption algorithms have to be invented - in fact they should be off-the-shelf algo’s as that is the most secure way … This layering is simply stacking them on top of each other.

Yes and no. It certainly requires work to earn these particular SNT, but the network doesn’t need any of this to function. Bitcoin miners do the real work of the bitcoin network, but mining SNT is not directly related to the network operation. SNT miners aren’t being rewarded for running the network, they are being rewarded for arbitraging the price of SNT and perhaps simply being a part of it.

All good thoughts though and an opportunity for clarifications! :wink:

edit: I’ve modified the OP a bit for more clarification.

7

I don’t think you’ve answered my concerns though I take your points. Just focussing on two:

  • all or nothing risks - the fact is that a problem with this mechanism, as it stands, is that the entire supply can become compromised by a single issue, some of which I’ve suggested. Perhaps that can be mitigated.
  • proof of work - it doesn’t matter that it isn’t part of the data storage mechanism or double spend, it will be part of the Safe Network project so the taint will remain. For me personally wasting resources cracking things is very undesirable and I think many will share that view whether it is “just for token distribution” or not.

I also think it is worthwhile considering that while this aims to be a better PoW than hashpower. Many bright people and resources have been looking at that problem and this solution hasn’t been adopted (i.e. a genesis DBC split into many), nor have many significantly better ideas so this is a hard problem IMO. There might be good reasons for why SN is the first to consider this particular approach, though it’s not the first DBC based solution. It might be worth comparing with David Chaum’s project, the inventor of DBCs. (I don’t recall the name but he has something which I think is blockchain based).

5 Likes
8

Perhaps we disagree on the risks here. The biggest risk in my mind is that the tokens get released all in one go and this risk is largest if this proposal isn’t adopted - as once they’ve been stolen, then problem can’t be mitigated after-the-fact.

So I’m guessing that you view theft as the biggest issue? – I say this because the only other possibility that I’ve thought of here is that they might be irretrievably lost, but since we can test the method in advance, that can’t be an issue.

So if theft is the biggest concern, then giving the bulk of the rDBC’s to MAID/eMAID holders is the best way to mitigate that.

Perhaps you could detail out what you think the specific risk is here.

But isn’t that ‘taint’ as you call it, just personal? I know a lot of people have come to see it as bad … but it’s all relative right? Bitcoin as a prime example uses far less energy than the existing banking networks and many mining farms are turning to waste heat and solar in any case.

The banking establishment doesn’t want to be challenged by any competitive network, so it comes up with twisted logic and spreads it via the media they own to give people a bad impression of it’s competitors … if we allow them to take an inch, they will take a mile, then they will take it all and destroy the ideas of any and all projects.

So I have to reject the sacrifice of the idea of PoW because I don’t see the sense in it truly being a bad idea - I only see it being used to attack a good idea - bitcoin and crypto in general.

Crypto DBC’s are unique to SN as far as I know, so bright minds or not, this proposal isn’t something other project community members, leaders, or devs would even conceive of as it’s not in their purview. And I don’t see how this would be useful for blockchain people.

Frankly, if this 70% of rDBC’s didn’t exist, that would be fine IMO. This proposal is simply a means of dealing with them as they were part of the original plan that people effectively signed up to when they bought at the ICO and I think Maidsafe is just trying to keep their bargain. If these 70% would just go away, it wouldn’t break the network as it stands.

– Just to be clear you understand that I’m only proposing this layered encryption for these 70% of rDBC’s correct? The other 30% would just be normal SNT.

9

Probably theft, sorry not to have time to go right into this but I’ll give quick responses. The point is that a single failure (whether theft or not) puts the whole 70% distribution and the project at risk. Hence wise to mitigate, unwise to bet the network without.

It doesn’t matter what our opinions are. The point is that you lose a big plus point in a lot of people’s eyes, you lose supporters and evangelists, and add a PR vulnerability that could be used to attack the image of the network by, for example those banks.

That’s not correct, I gave an example. There may be others. I expect many people working in this area will have looked at them and tried to figure out ways to use them to overcome issues with Blockchain and cryptocurrency, electronic money etc. Even if that’s not the case, an essential part of validating this idea would be to look for related work on PoW, DBC distribution etc.

An interesting point, but probably only acceptable to distribute to holders rather than not distribute at all. Personally my preference is still between that and a Foundation pending final method, with the caveat that I’d like to understand the details of the Foundation before casting a vote.

(And yes I understand you’re talking about 70% but it’s such a large percentage of total supply I’ve just said supply.)

1 Like
10

I dont think i fully grasp this proposal, so need to ask.

In your scenarios.

Who is responsible for cracking the rDBC’s , who gets to keep the funds?

1 Like
11

Whoever owns them. There is no responsibility here though - you can park them, delete them, or crack them. I expect open-source cracking tools would be developed near the start, so that won’t be a problem.

The point is that they can’t be all cracked at once - should take decades for 100,000 (a million?) powerful machines to do that and thousands of years if just one entity. - I haven’t done the calcs here as we’d need to have a guess at the best timeframe for distribution (10,20,50,100 years?), Of course the further into the future you go the less able you are to know what computing horsepower there will be and hence the less accurate your predictions could be … anyway this is something to guess at if this proposal is accepted by Maidsafe.

12

… sure, but my counterpoint is that even if we make ourselves all clean and shiny to the current view, the bankers will just make up new ploys to go after us … so it doesn’t matter. You have to stand up for what is right, not just follow the herd - as the bankers lead that herd and they’ll take us right over the cliff if we act according to the opinions of others and not with reason.

Chalmers DBC’s used centralized mints though right? I don’t think it’s the same. Also this proposal is to deal with a specialized circumstance of SN DBC issuance, so as I said, I don’t think such a specialized solution would be in the purview of other projects.

I don’t really understand … I am proposing a mitigation … so I’m not understanding the issue here. If theft is the issue, then this proposal doesn’t do much for that - except make it a less attractive proposition. This proposal isn’t really to deal with theft, which is an issue regardless.

13

My points aren’t negate by these responses. I don’t want to spend more time though unless this is being seriously considered.

14

It’s an interesting idea.

One of the key innovations of Bitcoin’s POW is the difficulty adjustment mechanism which ensures a generally smooth distribution of tokens over a long period of time. This dynamic mechanism continues to work regardless of advances in chip speed as well as increase/decrease in network participation.

This proposal does not appear to have any dynamic adjustment facility, but rather everything is created with a given static “difficulty” from the start.

It seems that a random-ish distribution could be created so that each lockbox has its own difficulty, eg using different number of encryption bits.

Still though, we have no idea at what rate hardware/software will advance. Perhaps in 10 years, a plateau is reached such that no further decryptions can be achieved, or the rate of unlocking diminishes drastically.

Or the opposite could happen, with breakthroughs that allow many lockboxes to be unlocked faster than intended.

I raise these points because I think the proposal could be made stronger if it addresses dynamic difficulty adjustment – even if just to explain why it is not needed and how these scenarios can be avoided.

3 Likes
15

Frankly, I doubt you have anything to worry about there. This is likely all just an academic exercise. I don’t know if Maidsafe has ever adopted a community members proposal. Certainly none of mine! :upside_down_face: :rofl: :cry:

16

Ok, well, i can see what your trying to achieve, but if this happens

I can see many being put of farming and seeing it as a 100% premined coin.
And many ppl may not want to spend funds doing so as it may not be worth it.

If this happen

If they were used as rewards the same issue applies, a lot of work to crack, would it even be worthwhile to attempt the crack.

If this happens

Same issue , is it worthwhile.

It seems all options or a mixture will just end up costing alot in energy / equipment.
We dont know the future price, or if it would even be worthwhile cracking them.
Seems a very costly way of doing things.

3 Likes
17

A strictly smooth distribution doesn’t satisfy any clear market requirement and as an algo facility it can be manipulated by powerful interests for profit via leverage and shorting at the appropriate time. What is hidden in this proposal is that the market gets to decide how to release the SNT’s as the SNT price indicates it to be a good value proposition (without an algo to counter the market demand) - setarus parabus. Is this better or worse than bitcoin? I don’t think anyone can know as markets don’t move as any cluster of supercomputers can predict.

I thought about that in the beginning, but it seemed like it might introduce problems in decryption. Perhaps if the header of the layer informs what the bit number is, then that is a viable solution … as you can skip over the tough ones. The other issue is how do you insure a fair distribution, what if some get really tough to crack ones, while others get easy ones? Maybe it’s random enough with so many, that this is a ridiculous concern on my part.

Definitely worth considering if the proposal is taken up.

That’s always going to be the $64,000 question. The further out we try to guess these things the more wrong we are going to be. Not sure if there is anything for it.

18

Yep … well, I’m not really in favor of their being a 70% in any case as none of the options look great to me. But I guess if I had to choose I’d go for a combo of the network holding 65% and MAID/eMAID people getting an additional 5%.

In that manner, the early hodlers get a bonus and jumpstart the process of developing software/hardware solutions for cracking.

Edit: maybe give the foundation another 5% also, they might help with the cracking dev. too. Probably that’s way too much for hodlers and foundation … I don’t know.

Okay, wait a minute … what am I writing here! I don’t think the software dev for cracking is going to be hard really at all … that’s going to be there from the start … I’m getting too tired to think about all this now … time for some zzzzzz’s :sleeping:

19

Splitting the 70% raises another possibility with or without your proposal. So some is held by and distributed by the Foundation, some goes to the best automatic solution we can create, the rest to MAID holders and shareholders. The benefit of doing that is it reduces the maximum downside of each and spreads any risk a bit thinner. Downside is extra complexity.

8 Likes
20

Who decides who owns them and how will they be distributed.

That sounds like a potentially worse situation than just letting the foundation look after it till an automated process is in place which would be so much better all around.

Its so much better that the 70% goes to existing and NEW farmers alike. We end up with a much more robust system and less chance of the few controlling economics.

Also seems a complex system while adding steps that may never be completed in some cases. Many lost tokens that will never go to rewarding farmers.

And it opens up so many scamming possibilities.

  • farmers with little compute resources but plenty enough for farming (eg phone owner who buys a RPi to farm)
  • scammers arrive and say we can crack those locked boxes and give you the tokens for a 5% (or whatever fee)
  • scammers crack the locked box and returns 5 % keeping 95% and tell the poor person that is all there was in the box.
  • scammers may just run too with 100%
  • scammers smart and say its taking a couple of months, while 100s or thousands take up their offer and without knowledge of actual scamming there is no alarm bells.
  • once the person takes up the scammer on their offer then its too late since the scammer and person are now in a race to crack the box.

This locked box sounds like a huge risk to me. In complexity, bugs, scamming, energy wastage, just because you don’t like the suggestion given. Keep it simple and @mav has been suggesting some ideas to progress from the RFI. Like lets create procedures that can be automated thus making it quicker to progress from human process quicker.

3 Likes