Safe transaction details

This was never the intention of my suggestion.

Bingo.

No, anyone shouldn’t take part. It would be for elders only. These hidden tokens are essentially a set of cold wallets for the network. Once found by an elder group, they could send transfers directly from/to those ids. No need for a single section wallet.

I don’t think this is necessarily the case. Authority to access the token could come from an elder group multisig that has a proven lineage back to network genesis. Does the network keep track of this now? Unsure, but iirc it might. Elders would only be allowed to search for tokens within a subspace of xor based on the section prefix (a bit mask).

Hunting for the location could be made easier if contained within one token was a “hint” about the location of the next. Elders would need to agree that it was time to hunt for and access a new location.

Another interestion option would be to allow elders to “save” tokens by hiding them again for a rainy day if there was a surplus of PUT income.

1 Like

Yes it does, each section has a chain from genesis (SectionPublicKey signed by previous key)

3 Likes

This sounds like a treasure hunt game too, as each clue, leads to another clue until the final treasure is found. At least that would be an easy metaphor to explain/understand.

I’m not sure it is necessary for this to be restricted to elders or groups. It may actually add complexity to do so too.

I think we can identify two primary goals:

  1. To reward farmers for their work.
  2. Increasing the money supply as the network/user base grows.

Do they both need to be handled by elders? IMO, no. Do they both need to be handled by farmers? Again, IMO, no.

Groups will receive payments for PUTs to their section. The amount of tokens for the PUTs depends on supply/demand for storage and also the size of the monetary base (tokens in circulation). Therefore, the rewards would also be subject to the same factors.

If there was nothing in the section wallet when a new section is formed (split), then the rewards could build purely from PUT fees. When the section splits again, these rewards could be split and shared out to farmers, emptying the section wallet again. The new section then starts with a fresh wallet. The simplicity of this appeals to me.

Expanding the token supply could be an asynchronous task. It doesn’t need to be performed by network nodes. It is just a way to get more tokens out into the safe network economy in a controlled way. These treasure wallets could be buried at genesis time and then the network can forget about them. They are future supply which can be added when found.

This process of hunting for treasure can be a separate user space app. Whether it is hunting for isolated treasure wallets or whether they need to be found sequentially, is more of a game design issue. Finding the treasure wallet and transferring the funds to their own would be a relatively trivial challenge to implement though.

Once the treasure has been found, it can be spent into the safe network economy. This will have an impact on storage costs for users and reward sizes, as the inflation is digested by the network. In short, storage cost in tokens will go up, as will the reward size. This will happen indirectly, without the farmers being involved in the process.

The advantages of this approach is that we don’t need special section/group oriented logic. It becomes an external process, with all of the dependency issues removed. As anyone can participate, it is also an open process and doesn’t present a barrier to entry that nodes may require (to be useful to the network).

Obviously, the treasure hunt game needs to be well defined. The game may use cracking the keys of the treasure wallets of varying difficulty to meter out supply. Meta data for these treasure wallets could include clues for where others are in xorspace. In fact, there could be different routes through the hunt, depending on which treasure was found and what clues it included (partial private key provided, xorspace range provided, etc). I think the game would take some defining, but it would be a fun challenge and there may be precedence for this sort of thing.

The key thing would be simplicity though. Rewards from PUTs and empty section wallets for new sections is relatively simple. An out-of-band user app to search for treasure is also relatively simple. Burying the treasure in a way which was proven random/unknown by the genesis creator has challenges, but I feel it is possible too.

It depends on how much control you want the network to have in the GET reward and PUT cost determination. With the current thinking about the network it is necessary because the authority to access and spend should come from a multi-sig that can trace its roots back to network origin. See dirvine’s comment above.

What you propose there (previous post above) is a free for all where treasure hunters cause the increase in token supply. This would be disastrous imo, and suffer from the problems you were originally concerned about when I brought up the concept. Unnecessary network load. Proof of work type activity, etc.

Keeping it simple would just mean that elders need to start looking for a new token when their section wallet is below a threshold. Some naive steps:

  1. The location of a new token would be hinted at (or stated explicitly) by data embedded in the current wallet they are using. This gives a finite probability that they will locate the new wallet within a certain amount of (network) time. The hint minimizes the work required to find the token and puts a limit on the induced network load, or keeps this load negligible.

  2. The authority for access to the cold/hidden wallet is automatically theirs (the elder group) because they have a valid section chain based multisig. No one else has this authority by design.

  3. Only tokens hidden within their current section prefix would be accessible. Elders from one section couldn’t grab tokens in another section. This could also be enforced by the section chain and section prefixes.

Maybe the best option:

The tokens don’t necessarily need to be “hunted”. You could just have a linked list structure where the next two token locations are known and only become available after the next section split. The provable mutation of the section key and the section prefix would give the post-split elders the authority to access one of the two locations specified in the location data/hint provided in the parent token. This option couples new token issuance directly to section splits. The network would need to reach 2^32 sections in size or greater in order for all SNT to be on the table. There are a lot of benefits to this option imo.

EDIT: About 4 billion sections may be considered too huge number of nodes at ~128 nodes per section. Nothing says you couldn’t make 4, 8, 16, 32 new tokens accessible after each section split if you want all tokens to be on the table after the network reaches a lower section count and lesser network size.

3 Likes

I’d say this depends on the rules of the treasure hunt.

It doesn’t need to be a scan of xorspace. There could even be a list of treasure wallets provided, which need to be unlocked in some way. It could be that some need to be unlocked sequentially too (based on clues, hash of result or whatever).

If the challenge to unlock the treasure wallets is almost entirely a client side task, then the network would only be put under negligible load. Sure, the client would have to unlock the wallet, which could be CPU intensive (depending on the type of challenge), but that wouldn’t impact on the network.

I haven’t thought deeply enough on what the rules of the hunt could be, but a naive design would be discovering the private key with partial knowledge (to make it easier). I’m sure much cleverer challenges could be formulated, as there is plenty of scope.

It feels like reducing complexity is desirable, so maybe it is worth some thought.

This is essentially what @mav was proposing earlier, except for clients instead of elders.

Yes, pretty much! :slight_smile:

Anything that rewards based on amount of computation/energy, whether it loads the network or not is wasteful and centralising (of rewards), like proof of work. I think that should be avoided if possible, and I feel it probably can.

For example, a mechanism Which allocates an unlocked reward at random or after regular intervals of activity, where the unlocking happens with small probability through normal network tasks. A bit like farming rewards once worked.

For example, a section wallet could have a chance of unlocking a reward every N events, but would submit it’s attempt to unlock the reward to another section, which would validate the reward and credit the wallet.

I think it needs to be a bit more thought through than that, but I hope the above shows that it should be possible to do without loading the network or incentivising client side mining-like operations.

2 Likes

Or could unlock N token rewards after each section split.


source

3 Likes

I wonder whether these facets can be integrated into the treasure hunt rules though?

For example, if the treasure wallet useless until after the network reaches a certain age (number of splits), it could have a similar effect. It could then just be a race to claim the treasure wallet once the oldest section on the network is at least as old or some such. In other words, the treasure wallets could only become spendable once the network had grown to a specific size.

The race could just be the first to transfer the tokens out of the wallet or it could be something more interesting, requiring the client to do something (confirm data at URL, do a calculation, etc). However, the point would be that no amount of brute force on the client side could force the network to allow the treasure wallet to be accessed until the network was mature enough to allow it.

My resistance to putting this onto elders is primarily to reduce complexity and encourage participation. Elders (and Adults) do plenty already and there are barriers to entry. Given the task of increasing the money supply could be detached from these activities, I think it is worthy of consideration.

2 Likes

If it can be done without elders or following the wasteful path of Blockchain that would be great.

1 Like

You keep pushing a client side approach instead of elders. This is a backwards approach imo. A quick summary of the points discussed so far as I see them.

Option 1: Elders are the first to access new tokens. They can be unlocked in the least resource intensive manner through a linked list and/or section split. The cold tokens are now “hot” and can be used to provide network rewards to node operators for new resources, or other rewards like PtD via the farming algorithms in the same way we have always considered. No amount of brute force would allow elders, adults, or clients to access these tokens before the time was right.

Option 2: Adults access new tokens during a treasure hunt. This is wasteful because adults are supposed to be storing data and/or performing useful network computations. The tokens become a bonus rewards for adults to take part in the network. The node operators can then sell the tokens or use them for PUTs. No amount of brute force would allow elders, adults, or clients to access these tokens before the time was right.

Option 3: Clients are the first to access new tokens after a successful hunt. This is likely the most network resource intensive manner. Clients are free to use the tokens for PUTs, hodl them, sell them, or use them for some other payment mechanism. The tokens funnel back into the network only after a client makes a PUT. No amount of brute force would allow elders, adults, or clients to access these tokens before the time was right.

Option 3 is backwards and contrary to the farming algorithm / network economics.
Option 2 is pointless and contrary to the farming algorithm / network economics.
Why is it not obvious that Option 1 is superior in all regards?

1 Like

He’s exploring an idea - that’s good, no need to stop that.

1 Like

I’m just brainstorming. Please don’t get so defensive over who’s idea it is and keep an open mind.

Supply does not need to be coupled to rewards, so keeping them decoupled in code would suggest a simpler design which is easier to implement and maintain. They are separate concerns. So, I’m poking around from this angle to see if it could work.

If you have a time (read: age) lock on a wallet, then the this is perhaps one way to stop wasted cpu or network resource. There are probably other ways too.

Of course, Elders could hunt for treasure too, as could adults or other users. Elders aren’t excluded. It would just be open to others too.

Maybe it isn’t the best approach, but just seeing where it goes.

3 Likes

True. He’s giving me some ideas on how to fix PtP gamification.

A non-resource intensive approach is one where the elders have a treasure map and don’t need to hunt blindly. They know exactly where a treasure is, but the treasure can only be opened once they pass a test (the right section prefix length, a valid section key). After they open the treasure, there is another map/hint that tells them the location of the next treasure. (ie. a secure linked list)

3 Likes

With age locked wallets, you could provide a list of treasure wallets to any user at genesis time, so I don’t think that point is exclusive to an elders only approach.

I am not sure how this has anything to do with PtP. PtP is a simple reward which increases payout from 100% of farming reward value to a little over 100%. If the 5% is used then it will be somewhere between 100% and 105% average. Of course not all GETs would be paid PtP and likely much closer to the 100%.

But I do see option 1 as a way to limit the available tokens any section can have in its wallet at any one time.

And by involving another section in order to unlock the tokens in a unit gives the ability to have checks and balances in place to detect a rouge section “stealing” tokens.

And of course there would remain the existing requirement to involve another (in most cases) section for every transaction the section pays out.

Could use a link list or a bit map system. If 128 tokens in each unit then there is only 2^25 bits needed to know if a unit has been claimed by the section and using a lazy update then the other units already claimed can be filled in saving even more time accessing a unused unit. Link lists do have the additional issue of corruption (likely deliberate) by a rouge section to disrupt the chain and perhaps kill off all unused tokens within the network.

1 Like

That’s why I like the idea of limiting a sections access to those tokens with the same section prefix. After every section split the daughter section gets N more tokens. Each of these N token contains the address of 2 other tokens that will only be accessible after the next section split. One of them for daughter section A and one for daughter section B based on how the token address matches up with the daughter section’s prefix.

Seems like you would just need to have the auditor section sign off that the section key had valid lineage. The two daughter sections after a split could audit each other, but that might be less secure.

I think your estimate for 128 tokens per section split is a good ballpark number. Here are a few other thoughts on how big ‘N’ should be that lead to a similar figure.

Assumptions :

  1. (min, max, average) section size = (64, 128, 100)
  2. Year when SN has accessed all 2^32 tokens in its cold storage: 2035
  3. Total number of node operators on SN in 2035: 1 Billion (This is about 25% of all active internet users today.)
  4. Sections split uniformly across the network at a fairly constant rate.
  5. Total number of genesis tokens = 671088640 ( This is estimated at 5/32 of total supply, unsure of exact number.)

Result:

  1. Total sections on Safe in 2035 : 10 million
  2. Number of section splits required to get there: 24 (2^23 = 8,388,608; 2^24 = 16,777,216)
  3. Hidden/Treasury/Cold wallet tokens available to each daughter section to make this happen: (27/32)*2^32 / 2^24 = (27/32)*2^8 = 216

To keep addresses nicely balanced within xor space we want a power of two number for N. We can simply adjust the network size and timeline estimate up or down a bit or fudge another assumption above to get a nice N=128 or N=256.

@jlpell I meant to ask you what the purpose of this is. In one or 2 simple sentences.

I was working with it being adding a second security check and only allowing a section to gain access to one unit of tokens at a time when its token balance is getting below some threshold. The threshold is not super important as long as it lasts longer than the time to get a unit of tokens.

As just a second security check then the simplest method to find a unit to request would seem to be obvious. But since you are taking great lengths in finding a unit, then I suspect you are trying to achieve something more or different.

Just a general comment. Imo, we should be trying to identify what can be app (layer 2?) features vs core features where possible.

The core design is necessarily complex. It must be stable and robust to change. Any unnecessary complexity should be avoided where possible.

Moreover, different devs/teams can more easily develop asynchronously when they are working in different layers. They don’t have to understand the mechanisms of the other layers, just their interfaces. In addition, they aren’t working on the same code, potentially blocking/breaking other changes.

Perhaps we should be asking ‘how can this be pushed to apps’ as the first step, then only considering core changes if impossible/unfeasible. Should we be trying to define where the edges of core reside and what should be on the outside of this?

Whether PtP, token supply, or other areas. I know I’m making unpopular points here, but it would be great if core changed less as we approach release, allowing layer 2 functionality to flourish upon it.

5 Likes