Initial price for upload

[mav]

@jlpell

have a two tiered system for protecting data. Token balances get a different security model than actual user data. If this extra complexity is warranted for tokens, then why not alldata?

All data would be equally secure. The solve-puzzle-to-spend idea came from considering if whale wallets might one day be more valuable than section wallets. Similarly the google-equivalent NRS entry could arguably a bigger target than any wallet. This consideration emphasized the already-accepted idea of ‘all data must be as secure as any other data’. Section wallets (or any kind of reward wallet) being somehow ‘special’ or ‘most at risk’ is not an acceptable place to be thinking from. We must design to keep all data safe. So from the start this idea aims for fungibility of data security (rewards, whales, nrs… all data).

The way this equal security is achieved is that reward wallets are the same data type as user wallets which are the same data type as the generic map type. The permissions / rules for valid mutation is the same for all those data objects. Under the proposed changes, all maps could be mutated by solving a puzzle (the puzzle will usually be of the form ‘check the signature’ but maybe the owner will choose to use a more complex puzzle like the reward wallets puzzle).

Instead of forcing the transaction verification to be only signature-based, it’s expanded to be puzzle based (or to use a more technical term, script based). By far the most popular script will be ‘check the signature’.

Maybe this is a good way to think of it: we could spend from any wallet by brute forcing the secret key. But that (deliberately) takes a very very long time. How about if we had a way to set the secret key in a way that could be a bit weaker, so we could choose how long it takes to brute force the key? This way we could have reward wallets where nobody knows the secret key and the brute-force time has been chosen to be possible rather than impossible (like a weakened burn wallet). Varying the difficulty of brute forcing the key for each reward wallet would allow rewards to be slowly issued as the brute force progresses.

The solve-puzzle-to-spend idea is this same idea of customisable weak-but-not-too-weak spending conditions. But instead of brute forcing a relatively weak secret key, which is just a kind of useless guessing game, we make the brute force depend on network activity. This means instead of brute force guessing we are brute force working.

The way to implement this type of brute force working is to change from simply ‘check the signature’ to ‘evaluate a puzzle solution’.

Normal wallets (and maps) will be able to set special spend conditions (ie mutation permissions) beyond just ‘check the signature’ too. And normal wallets won’t be restricted to just the reward wallet type of puzzles, they will be able to create any type of puzzle (within the constraints of the scripting language).

@jlpell

Imo some of the recent talk has shifted to assuming that closegroup consensus will be broken and section elders compromised, so mechanisms need to be in place to work without cgc. This is a little confusing/concerning. If the emergent behavior of the network cannot be trusted, then how can any operation be relied on?

A section cannot spend from a whale wallet because they don’t have the key for it, only the whale does. This is the crux of what counts as a ‘reliable operation’. If we had section wallets the close group could spend from it, since the elders are the owners. If there is no section wallet, instead having only ‘reward wallets with unknown owners’ the section cannot modify the reward wallets, even if the elders are colluding or hacked. It’s not about close group consensus working or not, it’s about what close group consensus can do or not do. Allowing a close group to spend from a large section wallet is probably allowing them to do too much. If we change to no-owner puzzle-based reward wallets we know the section cannot steal them (for the same reason they can’t steal a whale wallet). The elders will ideally only ever approve actions, but hopefully never initiate actions (perhaps some exceptions to this around node membership).

@happybeing

So to be valid, a data mutation or token issue ‘event’ needs to have been signed by a section, and any node ignoring that will be detected and punished.

This is a nice way to put it. If the section owns the reward wallet we can’t detect the difference between a valid and an invalid transaction so we can’t easily punish naughty elders. But if the section doesn’t own the reward wallet we can easily see if they are trying to steal it because they will have to provide an invalid claim for that wallet (same as anyone else trying to steal it).

@dirvine

We need to consider it much deeper

One thing that comes to mind is replay attacks via signature malleability. Too nitty gritty to get into just here.

[bones]

What could stop someone creating a fpga / asic that could brute force these puzzles faster?

[mav]

The solution depends on some network activity. So the only way to get more opportunities to solve the puzzle is to do more network activity.

By including the section signature as one of the parts needed to create a solution there’s no way to get that part from an fpga or asic or to know it in advance.

[mav]

Ethereum virtual machine opcodes also match the script concept well (ethervm.io):

Smart contracts are just like regular accounts, except they run EVM bytecode when receiving a transaction, allowing them to perform calculations and further transactions.

[tfa]

@mav

By including the section signature as one of the parts needed to create a solution there’s no way to get that part from an fpga or asic or to know it in advance.

Except if the elders collude, then they could provide the signature part and use fpga or asic to find the solution.

But independently of the section wallet control, if elders collude and gain the majority in a section then the network can be considered as dead. They can accept only their own joining nodes, inhibit their own relocations and when they have more nodes than necessary relocate some of them to the next section they want to target.

So the only problem to solve is to prevent colluding nodes to control a section. And this has been done with actions like incessant relocations or accepting joining nodes only when needed.

If the network succeeds in doing this, then there is no need to implement supplementary protections for the section wallet. And if the network doesn’t succeed then the network is doomed anyway.

[dirvine]

@mav

One thing that comes to mind is replay attacks via signature malleability.

Quick note on that. For group consensus we use BLS sigs (not malleable), so potentially get away from sig malleability, but in any case it’s a valid check to make for gathering ED|X25519 keys.

[andreruigrok]

I havent had time to read thru all the 126 posts, but here is my take on supply:

1. First I think it is unwise to talk about the potential of hyperinflating the supply at this stage because it might cause people to sell at current prices. Maidsafe needs to pay its bills based on current prices.
2. Aren’t Safe Network tokens divisable units with 8+ digits behind the dot?
3. The fact that 0.01 BTC refers to $170, shows the value of the BTC network and it is the reason why it reaches the headlines. I also believe that BTC would have gotten more media attention earlier if innitialy it would not have inflated the supply so quickly, it supressed the price in the beginning. If done differently, i believe the price would have gone up way faster, attracting more ‘treasure hunters’, growing the network faster.
4. The whole crypto community has its focus on price increase, not on mining/farming rewards. A rising price automaticaly will attract more farmers, than stable or worse decreasing prices with high farming rewards.
5. Taking into account point 2, there really is no point to flood the market with coins.

Therefore I believe hyperinflating the token supply is a bad idea because it most likely will work contrary to adoption.

[mav]

@tfa

Except if the elders collude, then they could provide the signature part and use fpga or asic to find the solution.

If the sections are signing the full request (including the neighbor signature) and not just the client payload then collusion must be between this section and a neighbor (potentially their neighbors neighbor etc). It doesn’t feel to me like a satisfactory answer though, like showing we can climb one more rung on an already unstable ladder. The broader point about elder integrity is still very important.

Let’s look further into why puzzle reward wallets are probably better than section wallets, even under the same degree of potential collusion… Network events are secured by both the inputs/trigger to the event not being easily attacked (eg it’s not easy to forge a signature), and the outputs/result being verifiable and punishable (eg anyone broadcasting an invalid signature can be detected and punished). Section wallets have problems on both sides of the event: the input can being easily manipulated (the signature can be created easily by out of band collusion) and a malicious output is not detectable (honest elders cannot prove if a suspicious-but-valid transaction is due to collusion or not). Puzzle-reward wallets greatly improves the input side (collusion takes much more work for much less reward), and improves the problem of verifying output (rather than being a single doubtful theft event it becomes many theft events which will stand out in statistical analysis).

To add another step up the unstable ladder, with reward wallets we can view the entire reward history. If we see too many rewards being claimed by one section we can say with increasing probability there’s collusion there. So we could set limits on the ‘density’ of rewards going to any single section and if a section violates it the network can flush all the elders in that section. eg if 90% of the last hundred reward wallets were issued to a single section out of a hundred we’d want to boot those elders. Even for a successful attack, there’s a much lower amount of benefit than the section wallet scenario and it comes at a much greater amount of work. Reward wallets require much more malicious work for a successful attack, much less reward per unit of malicious work, and a much greater ability to detect and act on attacks.

In general I agree with the sentiment that security comes from the elders not being compromised, and compromised elders are a disaster. I also feel we can have degrees of improvement to security and that’s worth looking at. Less capabilities means less incentive to collude, even if it’s still not zero incentive.

I feel like collusion is one of those exponentially improvable situations, a little bit less incentive greatly reduces the chance of nodes thinking ‘maybe I’ll collude’, so finding enough nodes willing to collude becomes exponentially harder. So it seems like even apparently small steps are worth investigating.

[jlpell]

@Nigel

Elders get compromised then yes things go bad but malicious actors would only want to control section Elders for the monetary gain, take that away and what would be the incentive

I disagree. If a single section gets compromised, doesn’t it mean the whole network is compromised and will die a very public death? Some jerks just like to tear things down for the sake of destroying the hard work of good people.

@mav

Section wallets have problems on both sides of the event: the input can being easily manipulated (the signature can be created easily by out of band collusion) and a malicious output is not detectable (honest elders cannot prove if a suspicious-but-valid transaction is due to collusion or not). Puzzle-reward wallets greatly improves the input side (collusion takes much more work for much less reward), and improves the problem of verifying output (rather than being a single doubtful theft event it becomes many theft events which will stand out in statistical analysis).

Still sincerely trying to see your solution @mav. But I can’t get past the fact that If a majority of elders are compromised it’s game over. Period. Other thoughts:

1. IIUYC you essentially want a set of 2^32 “cold wallets” for the network. So elders solve puzzles as a group like a mini “mining pool” doing POW to unlock new tokens to issue in the GET rewards. I presume the puzzles cover issuance in 1 token increments. But to get high levels of divisibility, flexibility, and reversibility I think you would still want to have be a hybrid approach that keeps a “hot” section wallet. For example, consider the reverse scenario when the network accepts payment for PUTs from clients? A stable payment system capable high levels of divisibility demands a hot section wallet where the network income and outflow is buffered. Presumably you could limit the size of the section wallet. For example, once the hot section wallet reaches a size of 2 tokens a cold wallet is spawned as a new puzzle and 1 of the hot tokens is transferred there. Regardless, a lot of complexity is introduced imo.

2. Thinking in terms of the “hot” section wallet vs. the “cold” puzzle wallet makes me wonder about alternative “puzzles” that can also achieve the security benefits you are after. IIUYC your main goal is to limit the total balance that is available to possible manipulation by a compromised group of section elders at any one time. Just spitballing here but why not just create 2^32 section wallets at genesis with 1 token each, similiar to classic safecoin but with divisibility built-in. Make the location of the wallets random within a larger dedicated address space. To make a transaction for GET rewards the elders to need to first hunt for and find a particular source wallet id and use their M of N multisig on it. When accepting PUT income they need to randomly select a destination from the wallet ids that they have already found. Each time a section splits the identified wallet addresses split/migrate to opposite daughter sections. I believe this is automatic if the actual xor address is the inverse of the wallet id. Since the wallet ids/locations are queried at network speed, the rate of new wallet identification could be kept under strict control and be asic resistant. And the wallets under transactional control by a group of elders won’t actually be stored in their section. This means there is a second group of elders that could potentially be used to audit the first. In the limit of 2^32 section splits you get 1 wallet per section, which might or might not be ok.

3. Imo the brute force key solving approach you proposed and the wallet hunting alternative are two sides if the same coin. In the first case, you know where the lock is but need to guess the right key. In the second case you know some valid keys, but need to search/hunt for the lock they will open.

@mav

he unstable ladder, with reward wallets we can view the entire reward history. If we see too many rewards being claimed by one section we can say with increasing probability there’s collusion there. So we could set limits on the ‘density’ of rewards going to any single section and if a section violates it the network can flush all the elders in that section. eg if 90% of the last hundred reward wallets were issued to a single section out of a hundred we’d want to boot those elders.

Yeah. I like this idea of using higher level statistics. In general I think anything we can do to detect and eliminate malicious nodes is a good thing.

[Nigel]

@jlpell

If a single section gets compromised, doesn’t it mean the whole network is compromised and will die a very public death? Some jerks just like to tear things down for the sake of destroying the hard work of good people.

I don’t think so as having disjoint sections was part of the scalability and security of localizing any potential harm. Network data is highly redundant also and AFAIK is distributed as globally as possible because of XOR address space so I believe any piece of data lives across multiple sections, am I incorrect here? As to the concern of doing harm for the sake of harm, yes there are people like that but man it sure does seem like they would get bored and then still have limited reward (part of why it might be even better to mitigate any large monetary reward). Why I say bored is because of node ageing and random relocation and needing a decent amount of resources running for quite some time to get the chance. Of course they could coordinate in some marketplace with others and purchase close nodes/elders etc but again maybe it’s getting too troublesome and expensive at that point.

I’m not saying we shouldn’t be worried about these things just that I don’t believe that if one section misbehaves that the whole network dies.

[happybeing]

@Nigel

I’m not saying we shouldn’t be worried about these things just that I don’t believe that if one section misbehaves that the whole network dies.

I agree on that basis that this makes no sense to me. It would be a very poor solution if that’s where we are. If anyone thinks this is the case, let’s see the reasoning because I would then agree it needs dealing with.

[dirvine]

@Nigel

I believe any piece of data lives across multiple sections, am I incorrect here?

At the moment they do all live in one section. There is a trick though we have for duplication (not currently in place). What we do is hash the name again, so store that near the name (another section whp). Then do the same. These are called main, backup and sacrificial. So spread across sections.

What’s nice there is we can remove sacrifical chunks to make more space. so we see nodes can hold more than we need them to currently and so on.

@happybeing

I agree on that basis that this makes no sense to me.

Data can be secured against a malice section (as above) and sections should be able to shrink to quite low numbers etc. However, sections in control of a wallet are a different beast, iff they have the power to mint coins or pay out coins to an address and they are compromised to the extent of a takeover then it would be an issue for sure. This is where we have been looking at section wallets etc. recently, to remove that last wee chink in our armour.

Not necessary right now as it would depend on a pretty big assault on the network (AFAIK), but for safecoin launch as safecoin then it’s best there is no possibility of a single section takeover killing that.

The other thing is network validated data with client signatures for mutations. So the wrapper allows the data to be stored, but the inner sig (the client) is the only valid mutator (not the network).

tl;dr section takeover can still at this moment cause problems with coins. With node age etc. that takeover is extremely difficult and more so as the network grows (like bitcoin etc.). So valid to probe every possible attack, even if it’s unlikely or considered infeasible.

[Sotros25]

@dirvine

These are called main, backup and sacrificial. So spread across sections.

What’s nice there is we can remove sacrifical chunks to make more space.

Would there be a base threshold for how many backup and sacrificial chunks are needed? Similarly, could a person elect to store /pay for more redundancy, or would that be tantamount to storing the same data more than once?

@dirvine

section takeover can still at this moment cause problems with coins. With node age etc. that takeover is extremely difficult and more so as the network grows (like bitcoin etc.)

One more reason to minimize the number of available coins until the Network becomes more distributed, I think. Similarly, the higher the value of MAID/SNT, the better/more costly to attack.

[dirvine]

@Sotros25

One more reason to minimize the number of available coins until the Network becomes more distributed, I think. Similarly, the higher the value of MAID/SNT, the better/more costly to attack.

For sure a good idea. Worth progressing a bit further as well. A few options I suppose, start with say a 2^16 number of safecoins. Then later some other denominations etc. All worth a look, not much code here tbh, but plenty of scope to tweak. (I mean in safecoin in general no just this idea).

@Sotros25

Would there be a base threshold for how many backup and sacrificial chunks are needed?

I see this in line with a fundamental that data can never be lost. So more redundancy should not be required. however maybe there could be other reasons (faster retrieval, i.e. the chunks are stored in many sections you know all the data you need and hashing the name several times until they all exist in the section you are connected to atm. This is possible perhaps?)

[Southside]

@dirvine

faster retrieval, i.e. the chunks are stored in many sections you know all the data you need and hashing the name several times until they all exist in the section you are connected to atm.

I thought we were getting this anyway as sections cache the last used chunks(how many?) - Is this not the basis of the claim that a file becomes more popular, its delivery gets faster - as opposed to what we see now, because it is stored nearer to the user?

[Sotros25]

@dirvine

I see this in line with a fundamental that data can never be lost. So more redundancy should not be required.

Totally makes sense.

@dirvine

however maybe there could be other reasons (faster retrieval…)

This is an interesting thought. From a UX perspective, I wonder what would be the optimal way to communicate the array or menu of choices a person can make (+ the relative benefits) when using the Network. I think being able to chart out the different options would also help to tangibly communicate the value SAFE provides by succinctly articulating what people can do with the tech.

@Southside

Is this not the basis of the claim that a file becomes more popular, its delivery gets faster

My guess is that “faster” is relative. Perhaps for some people and some use cases, “faster” isn’t fast enough, so they’d be willing to pay for even faster retrieval. I think this is one more reason why the economics (and relative price of SNT) needs to be finely tuned to align incentives. If a person wants to (essentially) leverage more Network resources, they should internalize the cost for doing so (in order to be fair to other people).

@Nigel

SNT is actually the ticker of another project which was mentioned in the lexicon thread so it seems SN is best for now.

All good.

[Nigel]

Thanks for the clarification @dirvine. News to me. Is data stored across sections a goal eventually? I’m obviously still confident in the resiliency of section elders from becoming controlled but just curious.
@Southside is referring about opportunistic and maybe deterministic caching and that’s something I wonder about as well. AFAIK it’s not top priority but will come in due course. Also caught you saying “Safecoin”, David.

Not to sound nit picky @Sotros25 but SNT is actually the ticker of another project which was mentioned in the lexicon thread so it seems SN is best for now. Also SN would show up at the top of search’s with anything longer than SN which is quite a lot actually and some known projects, check it out!

[dirvine]

@Nigel

caught you saying “Safecoin”, David.

Yea, Jim’s gonna kill me

[dirvine]

@Nigel

Is data stored across sections a goal eventually?

As we are looking at section takeovers being something we can handle then it becomes more important IMO. It’s not a big one to code, last time it was just a few days and the guys now are way faster (cleaner code). So we could do it in a week easily.

The section wallets are the pig in the poke for me right now. Not client-owned wallets as much, but section wallets. I say pig in a poke as I strive to the absolute separation of the network from mutating anything, probably a holy grail, but it feels close enough to test some thoughts. For data we are probably there, for section wallets then we have some ideas and @mav is also probing around with some interesting angles. So I am pretty confident we can come at least very close. It won’t slow launch etc. but a great experiment.

[Nigel]

If anyone could it, it would be the Maidsafe team with you at the helm David. Best of luck and we’re here to test and attempt to break stuff at your disposal.