Burning a specific amount of currency

GreatLogic 2015-01-12 17:51:59 UTC #41

Now imagine how a similar scenario would unfold if my proposal were implemented:

The burn rate offered at any given time would be very close to the actual NuBit cost of NuShares on markets. It would converge to the rate at which shareholders choose to burn roughly 50% of the time. Additionally, this burn rate could be utilized for other valuable functions that require access to a highly reliable NuShare market price.
Under normal circumstances, the quantity of NuBits allowed to be burned for NuShares may be extremely low if shareholders prefer lower rates of inflation. An equilibrium could form, balanced between the desire to have low inflation and the desire to protect the NuBit/USD peg. If the price changes rapidly, the burn rate would also change rapidly due to an acceleration variable that comes into play when several minting shareholders choose to burn or not burn in a short period of time.
The burn rate might fluctuate around a slight discount to market price, although it could potentially be available at a slight premium if enough shareholders are interested in acquiring additional shares without having to utilize exchanges.
It would be quicker to respond to unfavorable events, such as a serious threat to the NuBit/USD peg. Although the magnitude of the response would initially be low (as it would take time for Shareholders to increase the quantity of NuBits allowed to be burned per solved block), the rate itself would rapidly adjust to the actual rate required to incentivize NuBit burning. Rather than requiring shareholders to make future price predictions of a volatile market, shareholders would just have to recognize that a response is necessary and that they should increase the quantity of NuBits able to be burned per block.
Attacks that combine leveraged shorts with NuShare price manipulation would be far less effective. Attackers would be unable to capture most of the burning opportunities; those would only be available to NuShareholders. Shocks would be far less severe as NuBits would be burned for NuShares over a greater period of time.
If the peg is secured more rapidly, NuShare price is more likely to stabilize and recover.

GreatLogic 2015-01-12 18:03:27 UTC #42

I agree with your reasoning, and also agree that it would be wise to consider the implementation of a burning mechanism. It is vitally important to inspire confidence in the NuBit / USD peg, and perfect solutions are often infeasible to implement in reality. I also think that implementing a seriously vulnerable burning mechanism would be unwise at this time, despite the fact that it would probably be unnecessary for a very long time. Opponents of Nu (or simply honest writers) would likely recognize the vulnerabilities in a flawed burning mechanism and they may write articles about these flaws. This would reduce the attractiveness of NuShares and NuBits, and would render such a burning mechanism counter productive.

woodstockmerkle 2015-01-12 18:31:11 UTC #43

I interpreted Option #2 (vote for an amount of currency to be burned at a fixed rate) to be more of an “event” based solution to burning in exigent circumstances, as opposed to a rolling window and an ongoing effort that would bring with it has 24/7 operational expense. Once the motion passes and the we’ve mopped up some NuBits to bring the peg back, crisis over. If the crisis isn’t over, then pass another vote.

This could keep the framing of “burning” as more of a “in case of emergency”, and while not perfect, it may be sufficient, and keep the overall complexity of understanding and operating Nu low.

“Nu has a way to burn NuBits if the peg is threatened” may be the simple message to communicate and keep to.

mhps 2015-01-13 00:59:40 UTC #44

Do I understand right that your proposal is different from #1 because it adds more tune’able parameters to the burn?

GreatLogic 2015-01-13 02:08:57 UTC #45

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.

mhps 2015-01-13 02:33:05 UTC #46

I think burning by minting blocks is the plan from @sigmike’s replies above

sigmike 2015-01-13 06:48:54 UTC #47

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.

sigmike 2015-01-13 06:54:43 UTC #48

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.

sigmike 2015-01-13 07:13:18 UTC #49

I’ve added Benjamin and GreatLogic proposals to the first post.

sigmike 2015-01-13 07:21:29 UTC #50

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.

Ben 2015-01-13 16:18:18 UTC #51

On the surface, for most of the scenarios that I’ve considered, this is a positive side effect.

sigmike 2015-01-14 01:18:10 UTC #52

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.

mhps 2015-01-14 07:08:02 UTC #53

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?

sigmike 2015-01-14 08:13:15 UTC #54

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.

mhps 2015-01-14 08:46:41 UTC #55

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.

dongshan 2015-01-14 11:31:14 UTC #56

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.

sigmike 2015-01-14 11:54:04 UTC #57

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.

mhps 2015-01-14 12:29:54 UTC #58

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?

dongshan 2015-01-14 13:47:19 UTC #59

NBT burning custodian use the NSR granted to buy as much Nubits as he can in the market, and burn them all. No bot involved.

mhps 2015-01-15 02:16:59 UTC #60

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.