On the surface, for most of the scenarios that I’ve considered, this is a positive side effect.
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.
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?
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.
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.
To mitigate the need of trust, the custodian could be asked to park NuBits (?)
There would still be no guarantee he will actually burn the coins when they are unparked.
We can make a special process that burns the parked coins when the grant passes, but then the solution is very similar to the one described here:
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.
What if the unpark address is the burn address ?
EDIT: just read your answer, I think you already replied.
I agree it’s a good initial solution. But I think a solution that doesn’t require a trusted party would be better. It can come later though. Among these solutions I think the auction is the best one. It doesn’t require market tracking and it allows shareholders to burn a specific amount of currency. It would even take in consideration the fact it’s an easier way to get a lot of NSR than using exchanges, so the price may actually be lower than the market.
So for now should I just propose a motion to permit custodial grants of NSR?
It’s not a protocol change but I guess we will implement an RPC to burn (otherwise one would have to generate a raw transaction). A GUI is probably not necessary. Using the transaction fee is probably the easiest solution, unless we want to easily identify burning transactions as such (an excessive fee may not be an intentional burn, even if the result is the same).
I’ve edited the first post to add your proposal as option #5.
This is a simple and consistent solution and as long as the long term vision is to decentralize this process further (e.g. through an auction system) then this might really be the best thing to do right now. [5-7] are all very interesting proposals, but require a lot of testing in order to eliminate possible attack vectors.
That would be a very useful piece of information to see.
I would like to point out that it is possible to burn currency without trusting the burner. When a need arises to burn currency someone could propose a motion that states they will burn x amount of currency first, to be followed by a custodial grant of NSR of equivalent value. If the motion passed, even shareholders who were opposed to the motion (which would necessarily be a minority) would vote to approve the custodial grant of NSR to preserve the credibility of the network.
NSR custodial grants have use cases outside the context of burning and are an easy way to get a burning solution implemented quickly. I agree further improvements have value.
I am in favour of that. I think we can get this change in the 0.6 release due to the solution’s simplicity, though timing should probably be excluded from the motion.
I agree an RPC implementation would to make it easier to burn, and should be included in the motion. I also agree adding it into the UI is undesirable because of the risk of unskilled users burning currency unintentionally.