I would say the minter. With data-feeds this won’t be too hard. Ideally you would need different sources though. I suppose you wonder about the sources. The exchange feeds and CMC would be good for that I suppose.
Yes it was more a thought about the sources. Everyone would need to use the same feed or amalgam of feeds. That would indicate some sort of central Oracle which provides the “truth” of the NBT price. It’s doable, just seems to be a weak link.
You could have a datafeed for each exchange + CMC. Each minter chooses their own feed. Or even better have a random option in the client to choose which feed you use for the price.
The only feed is the series of binary POS votes indicating whether the external market price of nubits is greater than or less than 1 USD.
The price of NSR in terms of NBT is based on the revealed market price in each auction. This price is only used to determine the qty of seeded NSR equivalent in value to 1% of the outstanding NBT supply in subsequent auctions. This price doesn’t need to be accurate. Even a very large margin of error would be fine.
tl;dr no price feeds are used, feeds from exchanges = centralization = bad
But yes, it would make things easier for miners if they could obtain prices from an exchange’s API. Things are very slow to change in this system, so the API isn’t really a point of failure. As long as someone notices it’s screwy eventually, everything would be fine.
The miner records a binary vote when the block is minted. If a majority of miners over the past 24 h vote yay the price is greater than 1 USD, then nubits are seeded. If a majority vote nay, then NSR are seeded.
Brilliant. Your method is a very robust to capture the external signal (NBT price) through shareholders. Reminds me of the RPROP optimization algorithm.
What it would require is “burning to an address”, i.e. that you can send coins to an address which are afterwards are not considered to be part of the supply anymore. Since we cannot “send coins” from an unknown address (how to sign it), the only way is to destroy the coins and to recreate new coins at the recipients address.
Unfortunately this will not be possible anytime soon. Burning was not implemented this way, but through a special output which script only contains OP_RETURN and nothing else. @sigmike can tell you more about this.
Interesting. If one restricted sent amounts to discrete units, say powers of ten: 0.1, 1, 10, …, then this could serve as an effective means for coin mixing.
The guarantee of liquidity would ensure a pool large enough to obfuscate identities, at least after multiple passes.
Not necessarily advocating this though. Just a possibility.
@Benjamin there was a discussion about a similar feature where the shareholders post NBT/NSR auction rates and a user could burn their NBT to get new NSR and vice versa.
Unfortunately to do this on blockchain is not trivial with the current system. The reason is that we cannot mix NSR and NBT transactions. Some proposals were made like to use 2 transactions with OP_RETURNs or the creation of a new transaction type that can mix the native assets (the new transaction type is more robust but complex to implement).
Having an automatic auction system in place can justify the cost of implementing the new transaction type. The additional bonus is the possibility to exchange NBT<->NSR<->NEW-FUTURE-ASSET in an atomic and 100% trust-less fashion.
What about a ternary value: higher, lower, unchanged. The neutral value is needed for the feedback loop to stabilize, otherwise it would oscillate.
In this case Alice would create the new transaction type that will have an NSR input and an NBT output (or vise versa). Because there is no NSR outputs the NSR she spent are burned as fees and because there are no NBT inputs the NBT are newly created. The minter will check those transactions to verify that the correct auction rate was used and that the total amount of sold coins does not exceed the protocol defined values (1% as you proposed).
Could you expand the a bit the gaming part a bit?
Check also the “Hayek Money: the Cryptocurrency Price Stability Solution” paper, if you haven’t done already.
This is not true anymore. In the last release we developed a new RPC call “burn” that burns coins as fees that in effect removes the coins from the total supply (the fees are burned, not collected by the miners like in Bitcoin).
I am a little confused by erasmospunk’s comments. For now, I’ll respond to the issues that I think are most important. Let me know if this fails to clear things up.
First and foremost, I do not think that voting on auction prices is a good idea. The problems are as follows:
You cannot allow individual votes to be highly influential. Otherwise, individual sellers can game the system using strategic voting (even if the majority of voters are honest).
Due to (1), adjustments to auction rates are necessarily much slower than movements in external market prices. Slow adjustment implies a spread between the internal blockchain price and external market prices. Speculators will arbitrage this spread to capture shareholder value.
By contrast, In the system I am proposing:
internal blockchain prices (“burn rates”) are determined directly within an auction market.
Voting only affects the direction of supply changes. This does not open up arbitrage opportunities, even if voting outcomes are inaccurate.
In theory, voting outcomes only need to be marginally more accurate than random chance for the system to maintain a stable peg. That is, if votes are temporarily inaccurate (i.e. 51% of miners vote the wrong way several days in a row), this would not compromise the peg. As long as the NBT supply tends to move in the correct direction in the long-term, the NBT price should remain stable at 1 USD.
Note: I don’t want to discuss gaming yet. It is a very minor issue. I would like to make sure everyone is clear on the above points before discussing refinements.
Note 2: Oscillation is innocuous. A third voting category introduces some significant issues. There is no need to go there. However, if you insist, please first explain why you think oscillation is undesirable.
Oscillation is a sign an unstable system. Quoting a wikipedia article:
Making a change that is too large when the error is small will lead to overshoot. If the controller were to repeatedly make changes that were too large and repeatedly overshoot the target, the output would oscillate around the setpoint in either a constant, growing, or decaying sinusoid. If the amplitude of the oscillations increase with time, the system is unstable. If they decrease, the system is stable. If the oscillations remain at a constant magnitude, the system is marginally stable.
Another way of thinking about the neutral value is the no vote situation that could be caused for other reasons, like API errors.
What issues a third voting category can cause?
Some other questions.
- How is the NBT/NSR burn rate defined?
- Does each user choose their own rate and the best wins?
- What if there is low participation or competition, would the price go down i.e. they burn less coins than necessary?
I would like a detailed description of the algorithm.
edit: clarification and typos
This is the part of your quote that caught my eye. It seems to contradict the generality of your assertion. So again, unless you can come up with a more specific reason for concern, I don’t think discussion of a third type of vote is a good use time at this point.
Briefly, though, I would suggest creating a rule that requires the existence of a 1 or 0 vote for a block to be valid. (i.e. miners should not be allowed to abstain)
- The “burn price,” as you call it, is defined as the market clearing price in each auction.
A market-clearing price is the price of a good or service at which quantity supplied is equal to quantity demanded, also called the equilibrium price.
As stated clearly in the original post, the price of NSR denominated in NBT is simply the total amount of NBT sold+burnt divided by the total amount of NSR sold+burnt.
Users do not know the market clearing price until the auction closes. Prior to this point, participants simply send NBT and/or NSR they want to sell to the auction address. This represents a binding commitment to sell at the market clearing price, whatever that may turn out to be.
A high level of participation is guaranteed to exist at all times. lf no one participates, the first participant to commit to an auction sale would pick up the entire pot of seeded NSR or NBT at zero cost, i.e. he would get 1% of the NBT market cap for a nominal fee. The presence of this prize provides a powerful incentive to participate. You can think of it like a gambling game.
As far as a detailed description of the algorithm, 90% of the information necessary to implement it is in the original post. The only important missing piece is a discussion of gaming and timing issues. Your questions suggest that we are talking past each other, i.e. all of your questions were answered in the OP. It makes sense to wait until we are on the same page before discussing gaming and timing issues (which are closely connected).
Note: I am aware that I can be a little unpleasant when answering (or refusing to answer) questions. Sorry about that. I really do appreciate your interest.
I like this so much, it can be the missing step to a full decentralized cheap and automatic long term pegging scheme, which is necessary before thinking of developing Nu’s business model and the various profitable services that can be developed on the top of the first decentralized convenient stable currency.
I wonder if we can write a code that test how could this mechanism goes to demonstrate its efficiency over various periods of operation !
I am wondering how @JordanLee thinks about this idea.
Having a pegging mechanism that gets rid of liquidity pools completely while preserving the core component of Nu, which is the voting trust-less decentralized mechanism to make Human beings intervene and collaborate would be ideal and still in accordance with the original spirit of Nu, I am feeling.
This looks like a brilliantly simple and robust method on protocol level available to pave the ground for eliminating peg maintenance expenditures by automatic NBT/NSR burning.
I’ve stumbled upon an article about “Hayek-Style Cybercurrency” and that article describes a lot of what Nu already has implemented and the article carries out a method to automatically keep a peg in a way that is close to what @Benjamin proposed here.
If you read only the following quote, you might lack some definitions. I recommend to read the article anyway.
Bumping as this idea offers a way how to balance liquidity and keep the peg on a protocol level.
This idea is just too good not to be discussed.
What do we need to do to get going on this? Does someone need to propose a motion? I think we do need to wait for nsr grants, but that’s coming out soon. Other than that, what do we need as a precursor?
Who wants to take responsibility for hashing this motion? I would do it, but I’ve proposed a lot of votes recently and the last time I proposed a burn motion it didn’t go so well.
I see several potential problems that perhaps you can answer or clarify.
What happens when demand for NuBits decreases by more than 1% in a 24 hour period? Unless I’m mistaken we could see NuBits lose its peg by a large percentage for days or weeks at a time in the event of a demand collapse like we saw in February with the exchange hackings. This would ruin our perceived product quality, and negate one of our primary competitive advantages over competitors like BitUSD. This approach also reduces the flexibility of the network to quickly respond to serious demand shocks because of the 1% limitation. An automated auction solution should be able to respond flexibly to varying degrees of demand variance.
What happens to users who are working or unavailable to participate during the auction period because of the time zone they live in?
More broadly speaking, do shareholders have the attention span to monitor daily auctions? What happens on holidays or periods of lower shareholder participation? This requirement to be at your computer every single day would be a negative utility for NuShareholders, and would negatively impact share price. Yes, users would not have to participate in the auctions, but most would realize that their share of equity will tend to decrease over time if they are not acquiring NuShares on days where the auction price is below the market value.
What does “1% of the outstanding NuBits supply” mean? How is this reliably measured? Would this be all NuBits in existence, minus those held by custodians? Wouldn’t there be a serious possibility that custodians could game the auction by reporting their totals inaccurately?
I’m concerned this approach turns NuBits into an inflexible derivative of NuShares that will damage the perceived quality of our product by allowing long periods of time with no peg maintained. I’m also concerned that it would damage the value of NuShares.
I’m still in favor of an automated burning auction solution, but I don’t think this is the correct approach. Burning as designed within our network is a last line of defense against the collapse of a currency, not a daily tool for us to use in liquidity operations.
Slightly off-topic but relevant: I would love to see us design tools and programs that monetize Metcalfe’s Law, such as the network being paid for advertising. For example, if nubits.com or this forum ran commercial advertisements in the future, that revenue could be placed directly into liquidity support. The more users we have on our websites, the higher the liquidity subsidization that could occur. A perfect future would be one where the collective attention span of our users is monetized in ways that continually support our liquidity operations. YouTube and Facebook have realized that free products attract users, and the attention of those users is immensely valuable to advertisers. It’s only a matter of time before a cryptocurrency project figures that out.
Many powerful concerns, now we’re talking.
per week? The auction period takes place over the entire week so timezone and weekly flows are irrelevant (Just send whatever funds you want to participate to a certain address, could even be a burn address honestly).
If no one submits anything to the auction, everything gets burned.
Burning is now a weekly thing we do, we already passed that motion.
Keep tllp’s. I see this as a way to balance the market, not provide liquidity. However, interesting point about attention spans, we clearly need projects like @henry’s at this stage.
We can just use “in existance” and decrease the percentage (like 0.1%?)
The interesting point here is that the NSR auction seed is determined by the previous auction. The first auction we would have to set the price, but that’s a triviality in my opinion. The 1% limit prevents the NSR price from moving quickly in a demand shock, so I agree we should be careful about getting zealous with it.
0.1% of NBT is: $889.096
We would auction off $889.096 of NBT or NSR per week (+user funds). That seems reasonable to me.
Okay, here is a response to at least this question. I think I’ll need a new post for the other ones.
First, let’s describe the mathematics behind the system. Assuming that supply fully responds to demand eventually, market incentives will set a floor on the Nubits price.
To show how this works, let’s first break down demand for Nubits into two components.
Demand for Nubits = Demand for Txn Purposes + Investment Demand
In the long-run, we would like to achieve:
Supply of Nubits = Demand for Txn Purposes
Investment Demand = 0
In the medium-term, investment demand comes in to absorb excess nubits supply. The interest parity condition describes an equilibrium price, where investment demand = investment supply.
To set up the interest parity equation, let’s assume the following:
a) speculators demand a risk-adjusted return of R% per month for holding Nubits
b) park rates are I% per month (where I < R)
c) Supply exceeds txn demand. It will take approximately T months of daily nubits burning to reach the long-run supply necessary for exact parity.
Under these assumptions, if the current market price of nubits is P, the expected rate of Nubits appreciation will be (1/P)^(1/T)-1. This is a source of returns for investors.
Investors will also get a monthly return I from the park rate, so that the total rate of return from investing in Nubits will be I + (1/P)^(1/T)-1
(Note: This is actually an approximation.)
The current equilibrium price, P, sets the sum of these two returns equal to R and is given by the following equation:
R = I + (1/P)^(1/T) - 1
Solving for P yields:
P = (1+ R - I)^(-T)
So P is decreasing in T. All else equal, the longer it takes to adjust supply, the lower the current market price will be.
P is also decreasing in R. All else equal, the larger the risk premium on Nubits, the slower investors will be to respond to a deviation from parity.
P is increasing in I. Note that the park rate, I, compensates investors for risk. The system achieves an better and better parity as I approaches R and perfect parity if I = R.
Okay, now let’s think about some implications of this:
We don’t necessarily need to respond immediately to demand fluctuations immediately to maintain parity. There is always have some floor on the equilibrium price.
If deviations from parity are unacceptably large, we can address this by adjusting the park rate.
1% a day is quite an extreme change in demand. If we see changes like this, I think it indicates excess other problems that we should try an address directly (e.g. hacked exchange risk is a consequence of the existing custodial system, volatile demand from BTC speculators is due to a costly attempt to maintain BTC liquidity). If we were actually serving a demand for consumer txns and payments, we would almost never see demand movements in excess of 1% day.
The design is compatible with ongoing use of liquidity custodians should they prove necessary. That is, one could still intervene using existing mechanisms in the event of a large deviation from parity. The effectiveness of the design increases as R falls and is accordingly likely to improve as Nubits gains more traction.