Perpetual Auction Currency

[mav]

@oetyng and @mav combined post

Perpetual Auction Currency - Part 1

This topic explains a new approach to setting the farming reward. Nodes in a section all bid on what they estimate is a reasonable reward per GET. The reward amount is set from those bids. The trick is how to use the bids to correctly establish a meaningful reward amount in a way that cannot be easily manipulated.

This is radically different to prior ideas which were all based around predefining an algorithm using measured parameters.

Background

The network is currently intended to algorithmically calculate the reward based on the relative availability or scarcity of resources; as more storage becomes available the reward decreases, and as storage becomes scarce the reward increases.

However, this idea fails to incorporate other value derived from network activity. This varies widely as a result of many factors other than relative scarcity of storage.

Using storage as the primary economic measure unnecessarily combines unrelated friction points and gives undesired price discovery and economic results. Too much responsibility is packed together, separate concerns entangled.

Our radical deviation from existing ideas has been a very long process. There’s been a lot of research and justification to arrive at perpetual auction currency (PAC), too much research to include in this initial outline of the idea. The details of that research will be presented in the following post.

Summary

Nodes within a section can bid for how much reward should be given for each GET completed. A list of the latest bid for each node in the section is kept by the elders. Any vault may update their bid at any time. Whenever the BLS key changes (ie the elders change), the new BLS key is sent to neighbours and must also include the median of all bids at that time.

When the section receives a new BLS key from a neighbour (and thus also a new neighbour median bid), they use the new neighbour bid (NB) to calculate a new reward amount for each node. The difference between the NB and each node bid is used to set the reward amount for each node (see example below).

Nodes whose bid is close to the neighbour bid get the most reward per GET. Nodes whose bid is far from the neighbour bid get only a small amount of reward per GET. Since nodes cannot know the next NB in advance there is a tension that requires nodes to bid their true desired reward without bidding too far from the expected neighbour bid.

Incentives and considerations

Bidding higher than NB

• chance to increase reward
• don’t bid too much more or penalty for being far away from NB could be painful
• don’t bid too much more or it becomes attractive for competitors to join the network
• don’t bid too much more or inefficient operators may become viable and the network will become slower

Bidding exactly/close to NB

• simple strategy
• best chance of predictable income
• stability in economy hopefully brings stability to other aspects such as client usage etc.

Bidding lower than NB

• chance to reduce reward and make inefficient competitors nonviable
• helps network discover true value, personal sacrifice for the public good
• slows new coin creation so existing farmed coins are more scarce/valuable
• don’t bid too much lower or penalty for being far away from NB could be painful

Details

Neighbour bids

In between exchange of BLS key updates, every vault in a section includes their bid for farming reward as they respond to GET requests. The latest value is kept at Elders. When the section has a BLS key update to send to its neighbours, they include the median value of the current bids from the section. The receiving sections use this value for farming reward, until they get a new BLS key update. We can call this neighbour bid (NB). There is only ever one NB used in a section, and it’s the one included in the most recent BLS key update received from a neighbour. It means it will constantly be updated, from random neighbour section.

There is one more thing that enables this to work securely: In every group, NB is dealt out among the nodes in the section, according to each of their last bids before this NB was received. The closer to the NB the bid was, the higher the reward.

At any given time, it is unknown to bidders when the next BLS key update is. As a result of this, every bid made will have to estimate what everyone else thinks everyone else thinks.

This keeps the bidding pinned to each other’s common knowledge of the value, as there is no advantage in deviating from this strategy. Rather, there is only disadvantage in such deviations.

Due to these characteristics, this system should be very hard to game. Everyone is motivated to guess on what the others would most likely guess. The best information people have on that is (and becomes) the actual market value.

Bid Strategies

Nodes default to some predefined strategy (or set of strategies), which is called passive bidding. Initially it’s proposed that nodes who bid passively will use the last NB for their current bid.

Nodes that try to measure the true market value can set a bid according to their own strategy and are called active bidders. They hope to use any available information to bid closer to the next NB and therefore get a better reward than if they were passive bidders.

Nodes may have some visibility of the current bids, which gives everyone the ability to adjust their bids in real time between NB events, and thus more likely to have an accurate bid at the next NB event. This should keep the reward more responsive to the market valuation. There’s constant information exchange - within the section at least, perhaps even on a larger scale too.

Those who get punished are most likely the active bidders who repeatedly do a bad job or are unlucky.

Bid mobility

The NB is occasionally, at a low rate (for example 5% of NB:s), set to the average bid (NBa) of a section instead of the median (NBm). This is necessary as to always keep the reward responsive to the collective valuation, even when the ratio of active bidders is low. Without it, the median bid of a section, with 50% or more passive bidders, would always be the previous NB, which in turn also was the previous NB - i.e. there would be no bid mobility.

When occasionally sampling the average, the system allows for any deviations to impact the price discovery. The randomness and low rate ensures that this phenomenon is bounded and managed within the limits necessary to maintain the integrity of the system.

NBa is calculated using floor when NBa is below the current NB, and ceiling when NBa is above the current NB. This maintains bid mobility even with as few as one active bidder in a section.

For example, bids of (100, 100, 100, 100, … , 100, 99) using NBm would be 100, using NBa (rounding) would be 100, but using NBa (floor) would be 99, so it potentially requires only one bid to vary for the NB to move, rather than 50% of bids if using median or average-with-rounding.

NBa allows the bid to move higher or lower equally easily without a bias toward having greater or lesser reward over time.

As an additional protective measure, bids are always limited to a maximum absolute deviation of 1% from the current NB. If bids are allowed to be extreme then the bidder may be willing to accept the short term loss of reward for the long term benefit of greatly changing the reward in NBa events.

Reward distribution

The reward may be distributed between the nodes in various ways.

The main way to distribute rewards is to give more reward to nodes with a bid close to the new NB and less to those far away. This encourages vaults to negotiate the tension between the bid that best represents their true costs, the bid that best represents their desired profit, and the bid that best reflects the current market value. Their maximum reward comes by aligning their costs and profits exactly to the current market value.

Other ways of adjusting the reward may be:

• Reward bids lower than the NB slightly more than bids higher than the NB, to provoke a gradual bias toward lessening of reward over time.
• Weight by age, giving more reward to older nodes.
• Give more reward to the fastest nodes.
• Scale the reward (and storecost) depending on the size of the chunk so the economics become per byte rather than per chunk.

Proof of storage may be used to give more reward to the nodes that have the most storage so are therefore the most futureproof.

The exact way to apply weighting is yet to be decided, but the major incentives and protections must come from proximity to the NB.

Example

Nodes bid within their section for the reward they want (occasionally updating their value if needed). In this example, the current list of bids held by the elders is:
(64437, 64451, 64467, 64476, 64503, 64512, 64534, 64551)

At this point of the bidding the section receives a new BLS key from a neighbour. The new BLS key comes with additional data for the median bid in that neighbour section, which is 64500.

The distribution of reward for each vault is updated based on distance between the current bids and the new neighbour bid.

 Bid       Bid   Distance
position          to NB
 #1        64503     +3
 #2        64512    +12
 #3        64476    -24
 #4        64467    -33
 #5        64534    +34
 #6        64451    -49
 #7        64551    +51
 #8        64437    -63

The closest bid is +3 away from NB so gets the most reward

The next closest bid is +12 away from NB so gets slightly less reward

This decrease in reward continues until the furthest away bid of -63 gets the least reward.

Total percentages of reward then becomes as follows (exact way to calculate this breakdown is yet to be decided, this one is based on the sum of the differences, if you have ideas for this it would be great to hear them, we’ve tried a lot but not settled on any one in particular)

Bid     Tot. 
Pos.     %   
 #1      14.2
 #2      13.6
 #3      13.0
 #4      12.5
 #5      12.5
 #6      11.7
 #7      11.6
 #8      10.9

With an example NB of 64500, all GETs are rewarded the following amount per GET until a new NB arrives:

 Bid          Amount
position    received per GET
 #1.            9159
 #2.            8771
 #3             8385
 #4             8063
 #5             8063
 #6             7547
 #7             7482
 #8             7030

Risks / Considerations

One concern is the bids might be too sticky. If the penalty of putting out a true-but-very-different bid is too risky then bids won’t easily change. It’s expected the NBa mechanism will be enough to counteract sticky bids but the question is still subject to further discussion and consideration.

The PA seems pretty robust against collusion since it’s very easy to defect from a colluding group and this would be very costly to those who don’t defect, so the best strategy is simply don’t collude in the first place.

One thing to consider would be if the current reward is 100, it’s not fair to allow bids over 200 since bids cannot go lower than 0. Bids over 200 have an influence on the NBa which can’t be counterbalanced by simply bidding lower. So some boundary on the max/min bids is probably wise. It’s estimated that ±1% of NB is a reasonable bound, depending on the frequency of BLS updates.

Open Questions

1. We could get meta and say why stop at bids on rewards… why not bid on the rules of bidding? We could have a set of different rules, a) use bonuses b) use median/average c) use a weighted curve d) exclude outliers e) weight by age f) weight by speed etc and also bid on the portion/timing factors. Nodes could bid on which rules to use and which portions to use them in. This is moving toward governance… It’s probably too soon to be thinking at this next level deeper and there’s a lot of work to do on the existing reward bidding and nmb idea, but it’s good to have it in the back of our minds. Probably it’s not required but it’s fun to think about.
   It could be making upgrades much less problematic. The infected discussions on directions to take, the stalemates and divisions within the community (like the bitcoin upgrades). Perhaps not all, but some of it could be avoided by not making upgrades so definitive. If they just add options, it is still up to the users to dynamically vote for new or old options, and also change their mind at any time. It becomes a much more democratic implementation, as users will in real time change the system behaviour according to their assessments of real world situations.

2. What about allowing negative values for bids? Negative reward means vaults must pay to survive! That seems untenable but it might be useful for a) increasing scarcity and b) increasing the number of spare coins when close to 100% are issued. There’s a risk that it’s going to be abused for putting pressure on weak vaults, but it’s fun to think about especially with respect to calculating NBa results.

3. Additional markets for bidding. Considering that the bid is a valuation of a GET, future rewardable resources within SAFENetwork would probably have their own bidding. What things other than the reward might benefit from a bidding mechanism? For example, computation would be handled in some minimum unit - in the same way as the GET of a chunk - and network nodes might bid for these. At that point we would have two markets, one for the storage and one for the computation, and they would be traded separately with the native network currency. How separate (or connected) should these markets be?

4. Store cost Although store cost is not necessarily connected to farming reward, a suggested method for deriving it is presented here.
   The store cost most favored in combination with the PA system, is a function of farming reward, weighted by the current read:write ratio, and possibly also unfarmed supply (as we otherwise will not see net farming, and could/would stay at 85% unfarmed, perpetually). The weighting by r:w ratio is motivated by the idea that every PUT has the data chunk’s expected lifetime of GETs infused to it; it needs to pay for all the GETs the chunk is predicted to have. An expected result of this, is balance in unfarmed supply.
   With this design, the store cost would be directly connected to the decentralized valuation that the PA constitutes.

[dirvine]

I need to read this several times. In vault phase III we focus on the farming algorithm implementation. So that will be great to get “eyes on”. I must say though on the first read there are some really excellent points here. I wonder about node age though, it favours paying more to older nodes (most work, most trust etc.). I feel that is still valid, but open to discuss for sure.

Love the PA system and also the potential to bid on the bidding algorithm itself. Really interesting, I know now why @oetyng was looking at median values for BLS updates That did make me wonder.

In many ways, the scheme here proposed would be less work for the network that keeps accounts of data stored/Get requests etc. and maybe faster to run and implement. Really excited to hear what folk think on this one.

[jeremyjpj0916]

@dirvine

I wonder about node age though, it favours paying more to older nodes (most work, most trust etc.). I feel that is still valid, but open to discuss for sure.

Could add that kinda logic into this system where they get a small % shaved off their bid amount for the better. So older node bids 5 coins but since they are respected based on age they get a network “boost” of 3% automatically or something from their bid to better position themselves in the competition. That way being an elder and having that extra age time gives more value. Where that 3% comes from not entirely sure yet.

So they bid 5 in my idea, network shaves it 3% or say cause elder so reality it looks like 4.85 and all the rest had bid 4.95 so older vault wins due to its earned respect and network privilege.

Or simpler the “lowest price” to a person that would be visible post checks would be the elders offer(5 coins) with that privilege factored in(but not necessarily accounted/paid for by the network). So for newer nodes to get the bid they have to go even lower(I like this design better, no wondering where the boost gets made up from).

So 3 nodes:
1 - 4.90 Adult(?)
2 - 4.95 Adult(?)
3 - 5 Elder

Price that won bid was 5 Elder because network priv factored in of the _% puts it at 4.85 but the price paid and visible as lowest win was still 5 by the client and went to the elder.

Situation where Adult wins
1 - 4.85 Adult
2 - 4.75 Adult
3 - 5 Elder
And in this case the 4.75 Adult wins out because it beats the elder even with their network privilege boost(4.85).

And well to add to the incentive in the event of a tie in bid, the elder wins . Pays to be an elder and reliable node yo.

[mav]

@jeremyjpj0916

Could add that kinda logic into this system

Yes the Reward Distribution is an interesting mechanic because it’s really two steps:

1. use the ‘raw material’ of the bids to determine reward distribution
2. adjust rewards for other incentive factors like age or speed or storage capacity etc.

It’s not easy to say how this should look, since we want to keep the bids ‘honest’ but bids will also strategically account for potential adjustments to some degree. It’s a balancing act. Too much adjustment may undermine the bidding process. But not enough adjustment may cause less incentive to ‘do the hard work’ of longevity and trust etc.

Both steps have a lot of room for exploration. For example in step 1, what if the worst bid gets no reward. Is that a good idea? How smooth / harsh should the distribution be? And for step 2, what’s important to reward vs what creates harmful positive feedback loops?

@dirvine

the potential to bid on the bidding algorithm itself

Yes this idea is quite seductive and can become a bit of a rabbit hole but is a lot of fun to think about. It goes into governance and ‘democratic’ control of the network which is a lot more interesting (to me) than fixed-rules-with-emergent-behaviour.

It would be cool to extend the concept beyond proportionality on existing rules and use bids as a way to propose entirely new rules, which is kinda cool but also kinda scary since the future becomes less certain.

[Mendrit]

@mav

One concern is the bids might be too sticky. If the penalty of putting out a true-but-very-different bid is too risky then bids won’t easily change. It’s expected the NBa mechanism will be enough to counteract sticky bids but the question is still subject to further discussion and consideration.

Or if user will not understand how to set it right to make best profit so will leave it there since first set up. With more users they can become majority. There can be some automated system for them to follow NB, but it is than not 100% autonomous but 70%.
And if only 10% vaults will be willing to change a bid will it affect the median enough ?

[mav]

@Mendrit

will it affect the median enough ?

I’ve been contemplating this a lot… the whole Bid Mobility topic is a little tough to reason about. My current feeling is that having the bid become static for a long time is not bad per se. If it’s the ‘correct’ value then great, keep it there, for months if needed. That’s a good result both in my opinion and in the opinion of the bidders!

The periodic use of NBa should allow movement to happen easily if it’s desired, so having lots of passive bidders shouldn’t be any issue. Especially when floor/ceiling is used instead of rounding.

@Mendrit

if user will not understand how to set it right
…

not 100% autonomous but 70%

You raise a good point - it’ll be important to have a robust interface for setting a bidding strategy. It could be really interesting, sorta like trying to build forex trading algorithms etc. And of course sensible defaults for bidding will help a lot for the newcomers.

It wouldn’t surprise me to see a marketplace that sells bidding strategies.

[chrisfostertv]

@mav

governance and ‘democratic’ control of the network

fixed-rules-with-emergent-behaviour is a lot more interesting (to me)

[dirvine]

@chrisfostertv

fixed-rules-with-emergent-behaviour

Do you mean fixed goals here? It is an interesting area that if we can set fixed goals with great clarity and avoidance of side effects then allowing the algorithm to work towards that is very interesting. This is where I have been looking at neuroevolution or just plain genetic algorithms. I believe there is scope as we move forward (much post launch) to have the network test parameters for itself and remove all static numbers.

[neo]

@mav

The trick is how to use the bids to correctly establish a meaningful reward amount in a way that cannot be easily manipulated.

This premise does seem a little shaky. What is to stop the people promoting a modified vault software that increases the bids. Then when enough vault owners install the modified vault then the price increases a lot. And since reward amounts has a lot of incentives to be manipulated then it is quite possible this will happen.

Thus no matter what safeguards you install when enough very good people not abusing install the patch to increase the bidding then it can escalate to the equivalent to printing money.

Obviously relying enough people to install the patch, but earning rewards is a very strong incentive to do that.

The other scenario is that vaults want to be chosen so they drop their price and all others have to follow in order to be favoured.

[oetyng]

@neo

This premise does seem a little shaky. What is to stop the people promoting a modified vault software that increases the bids. Then when enough vault owners install the modified vault then the price increases a lot. And since reward amounts has a lot of incentives to be manipulated then it is quite possible this will happen.

It is protected by parsec. It requires the same level of honest nodes as any other thing in the network. If that level is broken, everything in the network is broken.

Nodes change their bid any time, but it is the elders that determine their reward.

For the system to be manipulated the way you describe, the section has to be controlled. So it is no different than any other Sybil attack with any other motives.

[neo]

@oetyng

It is protected by parsec. It requires the same level of honest nodes as any other thing in the network. If that level is broken, everything in the network is broken.

But that is the point

Malicious nodes are run by attackers

Nodes bidding high are run by (maybe) attackers and by all those who want maximum reward payouts. It has the potential for some sections to easily have 70+% of these modified vaults because good non-abusing people have applied the patch to gain better rewards.

It is a different demographic that the patch will appeal to. Hell I would do it too and I do not wish to abuse the network.

But if the standard s/w allows the node owner to set their desired amount then its even more likely to happen that the reward rate dramatically increase over time.

[oetyng]

You don’t need a patch to change the bid. You can bid any number at any time, that is how it is supposed to work. But that is not a high reward strategy. You gain less by deviating from neighbouring median bids.

The modified vault software you need, has to take over the specific section you are in, so that you control Elder decisions. Or you need to have enough vaults to be moving it in all neighbor sections, and their neighbours, and theirs and so on.

So what you are talking about is collusion.
It’s an interesting topic. So far it seems it is very risky to be colluding since it is easy to defect from such a group and penalty is high for them all then.
The exact number needed for effective collusion is something we deemed necessary to determine, but it was out of scope for this post.

We have tested different reward distributions and I prefer a much more drastic drop in rewards, where it is halved for every position. The last two will have basically zero reward, but it could also explicitly be set to zero or some other value.

[neo]

@oetyng

You don’t need a patch to change the bid. You can bid any number at any time, that is how it is supposed to work. But that is not a high reward strategy. You gain less by deviating from neighbouring median bids.

Then the undesired desire will be to create an APP that allows you to compare with others within your section and coordinate a rise in bid price. The APP takes your section number and compares with others in your section and if enough then allows all those in that section to up their bids.

Then once the idea catches on (through social media) then it spreads across the network and the APP becomes universal.

The problems extend beyond the bids increasing and increasing, but also encourages an APP to investigate the section details and share them.

[oetyng]

@neo

Then the undesired desire will be to create an APP that allows you to compare with others within your section and coordinate a rise in bid price.

It is expected and desired that active bidders will put effort in analyzing any data they can attain, automate decisions and output into the bid input of the software. This is the price discovery service they provide, for which they are rewarded if they do it well, and penalised if they don’t do it well. This idea expects and wants this information shared between sections.

The coordination you talk about is collusion, and that is the threat that has been the main focus to design protection for. So, the deeper analysis of the feasibility of such collusion was out of scope for the post, but the initial analysis points towards a large number needed during a sustained period of time, which translates to expensive.

@Antifragile

No it is not. Parsec does not solve problem of slightly modified software.

Mm it does, to the same extent as for any other feature of the network.
What modification do you refer to? Changing bids is part of the UI and expected and wanted behaviour. Building software to do this is also expected and wanted behaviour.

Deciding rewards is done by elders, and any decisions you want to influence there you need to beat the Sybil resistance of parsec, like with any other thing in the network.

[neo]

@oetyng

It is expected and desired that active bidders will put effort in analyzing any data they can attain, automate decisions and output into the bid input of the software. This is the price discovery service they provide, for which they are rewarded if they do it well, and penalised if they don’t do it well.

And someone will do an APP that would go viral to maximise their bid and once enough are using it then it will allow bids to be made to any value. If you do not think this would happen then history has not been good to you

@oetyng

Deciding rewards is done by elders, and any decisions you want to influence there you need to beat the Sybil resistance of parsec, like with any other thing in the network.

Perhaps you are missing the point. For attackers then the 33/66% figures are good protection. But for changes to benefit EVERY user then its a different equation when some sections will have over 70% making the changes. This applies to user decided bids too.

[oetyng]

@neo

And someone will do an APP that would go viral to maximise their bid and once enough are using it

Maximising bid means you don’t get rewards.
So, you need everyone to accept not having rewards, for all the time it takes to get enough people on board.
Deviating is expensive (especially when using a logarithmic reward distribution, which is why I prefer that).
You are arguing that enough people can be convinced for long enough time to not make the rewards others make, as to later maybe earn massive amounts. It’s absolutely a valid argument, but it is not so simple to do as you make it sound I would say.

@neo

Perhaps you are missing the point.

No I’m not missing the point, you’re still talking about collusion, which is one out of the two ways I described and how it needs to be done.

You need a majority of sections for collusion bids to stick. If you don’t have the majority, the NB of the majority will seep into all corners of the network.

[neo]

@oetyng

Maximising bid means you don’t get rewards.

You are ignoring the collusion. No good discussing unless you can show me that it cannot happen. BTW I explained how it can and 99.9% sure it will.

And before you say oh the majority will not. It won’t be presented as collusion, but just a way to ensure you get what your rewards are worth.

[oetyng]

@neo

You are ignoring the collusion.

I’m pretty much talking about collusion with you, how it can manifest, prerequisites etc. I wouldn’t call that ‘ignore’

As I said, you need everyone to accept not having rewards, for all the time it takes to get enough people on board.

You seem to be assuming there is no time element, or maybe that it is negligible. One moment network starts, the next everyone (of the number needed) is in collusion.

The time element is quite important. If we can make anything happen instantly, then any running costs are made irrelevant.

The faster you can reach the critical value (number of nodes needed for successful collusion) the lower the costs for it were.

I’m not saying that it cannot happen, because it can always happen. I’m not going to say entire network cannot be overtaken either, because it can. Given enough resources.

I say that it is expensive, it seems to be prohibitively expensive, but that the analysis around exact numbers were left for part II.

@neo

BTW I explained how it can and 99.9% sure it will.

OK, you say so here. I don’t agree that your arguments show that it is 99.9% (or any number, or likely). The premise in your argument seems to be there is no time component, so the build up of the successful collusion has no costs.

[neo]

@oetyng

The premise in your argument seems to be there is no time component

No. That’s implied from the beginning. What does when enough are using the APP mean?

Anyhow this has happened before. And honestly general population who will run a vault will also run the APP. Hell they may even start running a vault because they heard about the APP.

Anyhow I’ll leave it there since its pretty easy to see how this will happen. Why do you think laws are made to outlaw collusion.

[oetyng]

@neo

No. That’s implied from the beginning. What does when enough are using the APP mean?

Well, either the time element, the fact that there are costs to the attempt as a function of time, or the idea of rational agents.
When the argument about two of these had been rejected by you it seemed you rested on the third.

But it seems more incoherent now. The main argument now seems to be simply ‘it will happen’ and ‘it’s easy to see’.
OK, let’s leave it at that then.

The details of the mechanisms are very interesting IMO, you seem to be more interested in proclaiming the absolute certainty than talking about how the things work towards or against that outcome.

Let’s look closer at that in part II.