It’s true that my proposal involves more parameters than option #1, but the primary difference is that it requires a person to successfully mint a block in order to earn the right to burn a set amount of NuBits for NuShares. NuShareholders would determine the amount of NuBits that could be burned per solved block as well as the number of NuShares that would result from burning that amount of NuBits. Under non-emergency situations, the amount of NuBits able to be burned per block would likely be very low (including 0). This aligns the interests of NuBit burners with NuShareholders, and also allows all minting NuShareholders to recapture a proportional amount of value that they lose to the dilution cost from the creation of additional NuShares.
The other difference is that the burn rate would adjust according to whether or not minting NuShareholders choose to burn NuBits for NuShares at a given rate. If someone chooses to burn NuBits for NuShares at the current rate, we know that the rate is at least high enough for one person to think it’s a good deal. Each time someone chooses to burn NuBits, the rate would be decreased by some percentage (since the current deal might be too good). Each time someone chooses not to burn NuBits, the rate would be increased by some percentage (since the current deal might not be good enough to be worthwhile). The end result is that the burn rate would converge to point where minting NuShareholders choose to burn NuBits for Nushares roughly 50% of the time, which would hopefully be a very fair rate according to current market conditions (accounting for future predictions of minting NuShareholders).
For example:
Lets say that something like my proposal were implemented. Shareholders would vote for how many NuBits (N) can be burned for NuShares per solved block, how many NuShares (S) would be earned by burning that quantity of NuBits, and the rate ® at which the number of NuShares earned (S) changes when a block is solved. There could also be an acceleration (A), that could allow the burn rate to adjust more rapidly to turbulent market conditions.
Shareholders might initially set N and S to 0, or they might set N to some small number (so a fair burn rate could be established) such as $0.10 and S to some amount that is likely less than the number of NuShares that can be purchased with $0.10. Since the burn rate is low (in this case), no one would opt to burn NuBits for NuShares because they could purchase a greater number of NuShares for the same amount of NuBits (unless they wanted to test the system). However, each time a block is minted and NuBits aren’t burned, the quantity of NuShares (S) earned from burning N NuBits would increase by R (and R may increase by an acceleration rate if several blocks in a row opt not to burn NuBits). This would continue until S is high enough to convince a minting shareholder to burn NuBits for NuShares (in this case, they would only be able to create a very small number of NuShares; perhaps roughly 10 if NuShares can be purchased for $0.01). At this point, the quantity of NuShares earned by burning N Nubits would be decreased by R and acceleration of R would end. In subsequent blocks, now that the burn rate is closer to being a fair rate, it would tend to converge to something close to market value (either at a slight premium or discount depending on NuShareholders). If roughly 50% of minting blocks choose to burn NuBits, it would increase NuShare inflation by a fairly small, but not insignificant amount (40 NuShares rewarded per block to 45 on average). This inflation would be controlled by NuShareholders voting to change N. An additional benefit is that NuShareholders would have an incentive to purchase NuBits in order to take advantage of good burn rates (which ultimately helps account for the inflation cost). A potential flaw is that minting NuShareholders would have an incentive to increase N, especially if only a minority of NuShares are minting. However, this also means that there would be an additional incentive to mint, which could help account for this flaw.
The primary benefit of an automatically adjusting burn rate is that it would be better able to adjust to a volatile market in an emergency. NuShareholders (or any group of people for that matter!) would struggle to choose the correct burn rate in order to stabilize NuBit value in an emergency situation. They are very likely to either underestimate the burn rate, and lose precious time when prompt action is required. Or they will overestimate the burn rate and pay a far greater dilution cost than was necessary to stabilize the price.
There’s a problem with option #1 and all the options with adjustable rate through median: Some shareholders can vote for a very small rate and this rate will become effective for a very short period of time when the median moves. Some people can take advantage of this situation to burn a lot of NBT at a ridiculous NSR price. It only takes one shareholder to create this situation.
Not really. My intent in this quote was to prevent a single shareholder from burning all or too much NBT. In GreatLogic’s proposal the burning process is only available to the shareholders finding blocks.
That makes me think of a similar solution that may have a better flow:
Someone wants to burn some NBT. He creates a transaction sending X NBT to a special output that puts them on hold with some informations like the number of shares he wants in return and the duration his proposal is valid. The shareholders can vote to allow it. If they do, the NBT are definitively lost and the NSR are created. If after the duration they haven’t approved the burning then the NBT are released.
It removes the risk on the shareholders’ side but it requires the person who wants to burn NBT to already have them.
The end result would probably be similar to an auction, so I’ve thought more about the auction process.
Here’s how it could work:
Shareholders vote to burn a specific amount of currency after a certain duration. When the vote passes people can start bidding. To do that they send some NBT to a special output indicating the amount of NSR they want in return.
Anyone can bid any amount of currency for any amount of shares until the total amount offered for burning has reached the maximum. After that, a bid is accepted only if there’s another bid with a higher rate. When that happens the NBT of the other bid are released.
When the auction duration has passed, all the NBT in an active bid are definitively burned and the NSR are generated.
Shareholders could also define a maximum rate to avoid absurd rates at the beginning.
And we may need to add some rules on the amount of currency to prevent a small bid from releasing a much larger bid. For example the shareholders could decide that each bid output must have a specific amount of currency, so large bids would split the outputs.
Let’s get the terms consistent. The “rate” here is as the Y in 1 NSR (earned) = Y NBT (burnt),
right? It is different from the X in my post above, “where X NSR will be generated for 1 NBT burnt”. The shareholders want a higher rate so more NBT is burnt with less NSR generated.
But here,
You seem to mean that shareholders want a lower rate. Can you clarift?
In my previous post the rate is the amount of shares obtained per currency burned.
So you have to bid at a lower rate to win (= there must be an existing bid with a higher rate).
And shareholders want a lower rate (less NSR generated for each NBT burned).
The final motion will have to be clear about that if we go to this way. Maybe we can just talk about amounts instead or rates, especially if each bid has a fixed amount burned.
I got it. Your rate is the same as the X I was talking about.
That is a cap to the rate. The problem I see is that there is no guarantee the amount of NBT pledged will reach the amount to burn, if there is a set maximum rate. The burner may not be incentivized enough. If we allow the shareholder to adjust the maximum rate, then we may be back to the voting-for-rate route again.
If we don’t set a maximum rate, the burners will set high rate to reward themselves. This may not be as bad as it initially sounds, as I said in #34. It is similar to Proof of Burn, one of the better ways to distribute new shares/coins.
I would like to explain a little bit more why I like @benjamin ‘s suggestion most.
It is the simplest one. Shareholders vote to grant some NSR to an NSR address. That is it. Actions afterwards (purchase and burning) take place off-protocol.
It doesn’t introduce additional role and risk. Because of the need of dividend payout custodian, we have to and already have a group of people who can be trusted with sharholder’s fund, Just like KTM and jmiller. They can play this NBT burning custodian in the same way as they act as dividend payout custodian.
Just as I once submitted a LPC server first and paid later proposal, a NBT burning custordian surely can submitted a burn first and paid NSR later proposal.
4 . The NSR grant is a very useful tool in many other aspects. For example, many potential LPCs expressed they prefer awarded with NSR instead of NBT. We also can pay some Core developers with NSR.
It is indeed a very simple solution. So simple that it can be implemented in a few hours because the custodian system is already in place (we just have to allow NSR custodians and a way to burn currency that would affect the supply returned by getinfo). Also, as you said this is a generic solution that may serve other purposes, and implementing a more complex burning mechanism later would still be possible.
It just adds even more human factors. Well maybe not. The bots coould be made to also have a “burn mode” – sell nushares for nubits to burn. So when needed, the bots get shares from blockchain-generated shares and get burning going automatically.
Still the burn amount and burn rate have to be voted. Are we back to where we started?
Then you have to require such custodians to be also good at trading. The idea with LPCs was that there will be many LPCs competing for an eventually simple bot-tending job. Requiring trading skills to trade on the market is quite different. More and more dependence and requirement on human factors just creep in.
The custodian could also just burn some NBT he already owns. For example he posts a proposal asking for X NSR while proving he owns Y NBT. As soon as the NSR are granted he burns the NBT.
It requires trust, but the simplicity of the solution makes it possible to have a burning mechanisms in the next release.
As a result of the discussion of the last couple days, I have come to believe the best solution is extremely simple: merely permit custodial grants of NSR. That’s all, on the protocol level. Currency burning is already possible via excess transaction fees or OP_RETURN.
Our network currently permits anyone to burn currency or shares if and only if they possess the private key. With this minor change, anyone can could create currency or shares if and only if approved by shareholders via custodial grant. It is elegant and very flexible, as the protocol should be.
There are quite a few scenarios where shareholders may wish to create NSR, and each requires different actions surrounding the NSR creation. I don’t have time to right now to articulate the details of different use cases, but it may be that NSR is to be given as compensation, or that NuBits need to be burned where that is our only currency product. It may be that burning is necessary because one of the many national currencies we peg to is hyperinflating and being abandoned or replaced by a different currency. We may require a trustless solution in one situation, while in another scenario extending trust makes sense.
There are many questions regarding the circumstances that will exist around the need to tap the value in the NuShare market cap, but one thing we do know is that the shareholders of the future will have much more information than we have today. So we ought to give them the most flexible tools we can and let them decide what to do.