The section wallet contains any unissued safecoins and is intended for paying rewards to nodes. It’s controlled by the elders and can only be spent from when elders agree. I’m wondering if there are any other legitimate uses for those funds besides just rewards?
One example I feel is a pretty good idea: the section history is a really useful thing to know (ie how the section membership has changed over time to get to where it is right now) since it allows anyone to verify the section has come from the original network and is not an impostor network.
It seems really useful to be able to store the section history on the safe network so anyone can download and verify it. This data could potentially be saved by the network itself using the funds in the section wallet (which so far have only been earmarked for paying rewards). Every time the section membership changes the change is appended to a global record of all sections, paid for by the section wallet.
Do you think this idea could work and could be useful? Are there any other ways the section coins might be used?
Yes, maybe. A while back I asked dirvine where all the metadata and parsec/datachain data is stored. Whether it too got chunked and saved to the network forever…iirc I think he stated it was not stored in the vaults like other data so had no cost to the network. This was still unclear to me though…
I think it would be neat if the network saved all of its own internal data logs to itself as immutable chunks that could be reviewed in perpetuity. It seems like this would be the most logical and self consistent practice.
In general I think the section coins could be used to good effect for all kinds of rewards that are determined algorithmically (PtP, PtC, PtD, etc.) in order to stimulate the health and growth of the network.
But do we want to permanently record the history of every node. Does this not defeat a lot of privacy and anonymity since the nodes can be traced from when they joined to present. What about rewards earned, would you be recording this as part of that history.
I would have thought that as much info as possible would be scrubbed so it is not kept.
I would imagine the public names of the node (ie how they are located on the network) and the section key generated by dkg would be extremely helpful when verifying if the section being joined really has come from the original genesis.
IP, rewards etc, no, I don’t see any reason for that to be stored in this verifiable history, and I would discourage it since it affects privacy, but there’s nothing to stop that info being stored elsewhere if elders decide they want to (but for what reason I could not guess).
The problem I see is if I join the network how can I verify the current section members are valid or from a different spoofed network? The only way I can see to verify it (should I want to do that, not every node will want to) would be if the full history was available and the current section can be tracked all the way back. Maybe storing this info on the network is a bad way to solve that problem of verification? Maybe it’s not even a problem at all? I appreciate that fetching my account map would be enough to verify if the network was real or fake, but this doesn’t cover all use cases, eg anonymous browsing.
There’s another idea that ties into the membership history too, although it’s getting a little off topic. If every upload has a receipt signed by the elders, the uploader (or anyone) can keep that receipt and use it in the future to show the upload was paid for. This makes it possible to restore a crashed network, but only if we have the history of membership (so the signatures on the receipt can be verified). If there’s no history then the signatures could not be verified. Starting to get into ways to enable network restore, possibly also airdrops on other networks; seems to me the history of node membership will be fairly important for network restore. Maybe there are alternatives, I don’t know, but seems to me like a pretty ok reason to keep the membership history. Open to further thoughts on this.
I would think its possible for pruning of history to be done as has been said or suggested by David and so the storage has to be able to be deleted.
So the data could be stored as private data (to the section) which would allow the pruning of unnecessary data as time goes on. The access to the data has to be requested from the section anyhow so being private is not going to change things. But it does allow the removal of unnecessary data.
Remember the leakage of information about nodes that is not needed adds to the attack profile of the network. Its every little bit that adds up. Not to mention it might make some reluctant to run a node if they know the ABCs can find a complete history of the node and its activities on the Safe network. Many things can be inferred from this sort of information. Like if a node is on for 3 weeks/3 months then rewards are expected to be minimal, but if 3 years then expected to be a lot more. This is just one of the inferred pieces of information.
So while some information has to be kept for longer periods, other pieces of information is more short lived. Also pruning means that the need for long term history is done away with and so no need to store permanently and actually a leakage of information that just adds to overall information that can be gleamed.
Yeah, it’s a fine balance to be had and could be easy for future devs to cause info spills if not careful. Seems like the signing history that proves certain data is valid data and certain vaults/nodes were valid nodes from the present back to network origin would be nice to have as a public immutable… A log of network/section metrics such as the farming rate… Other items that reflect network state but don’t diminish individual privacy might be nice too.
It’s a balance though I think. So just to clarify a sectionchain is from genesis key all the way through to latest. It’s a simple affair, so each key signs the next key. We know that was done by the quorum, whoever they were.
When we communicate with other sections, we tell them our current key (and can prove to them it’s current, even from genesis, but from their last known key for our section) plus current Elders who make up that key.
So folk could and might harvest those Elder names, but right now we forget them as we move on.
This has to be done, I think that we can create a special blob type that needs sections signed, but not paid for? (farming algo should handle extra unpaid data OK, but leaving the door open there) either way, for sure section chain from genesis for every branch of the tree should be available to anyone at any time. The “current” parts likely will not be. It’s not done right now, but we should after X keys store it where the last entry is a pointer to the previous chunk of keys. It’s not in place right now, but should be.
An interesting idea? If section wallets were only valid if we see their whole history. So all transactions from those wallets have to exist in perpetuity. Brainstorming here, but broken/took over sections is always gonna be a thing, regardless of quorum etc. it’s always a threat. Now there’s not too much it can do, but it could steal section coins, pay them to a bad dude. However the network could perhaps be made aware of a “glitch in the matrix” where a bigger than expected payment was made.
As I say brainstorming, this is not a fix, but just a thought there may be a way section wallets are absolutely transparent. We can see current network unspent coins on the whole network or on each section. It could open doors to network auditing sections? I am not thinking about recovering stolen coins here, just identifying it happened, which is step 1. Identifying them and stopping them is v tricky as it exposes other wallets and we don’t want that as it would remove privacy from people.
Shouldn’t be a problem (not in those relatively small volumes at least), since nodes are paid for their time up at relocation. In essence, the network and other uploaders pay for this section data. (If nodes get filled up to a higher extent, store costs rise = the other uploaders have paid for the section uploads)
Generally on the OP: I have long thought the same, that the sections should be able to make good use of the network storage itself, in one way or another.
(not in those relatively small volumes at least), since nodes are paid for their time up at relocation. In essence, the network and other uploaders pay for this section data. (If nodes get filled up to a higher extent, store costs rise = the other uploaders have paid for the section uploads)