As JordanLee pointed out in some post I cannot find right now, you can avoid this risk. The burner simply makes a proposal to burn a specific amount of NBT and when the proposal is granted he/she first burns the NBT and then receives the compensation.
The proposed text of the motion is excellent as is, in my opinion. I agree the burn RPC should work with any unit in our network.
I calculate the RIPEMD-160 hash that needs to be entered in the Nu client in the motions dialog as:
Can someone else confirm this please?
This is a very important protocol change, and the fact that both jordan and mike consider it excellent makes me feel very confident.
For the sake of clarity, could you write down a couple of concrete scenarios involving currency burning and its consequent NSR reward issuing? ELI5, just to be sure I am getting it correctly.
If this motion passes I would like to see it implemented in our next protocol change, client version 0.6.0.
Here is one scenario:
Another is the recent NSR bonuses given to new LPCs. With this change there would be no need for human intervention as there has been until now. The protocol itself would award the NSR to these LPCs upon shareholder approval.
Slightly off-topic: I hope that people asking for NSR in proposals realise that it can go up and can go down. No crying allowed when the shares are declining from an earlier peak when it takes a bit longer for your proposal to pass. Ask for NBT and you know what you get as your reward, you can always buy NuShares with them afterwards.
So, in a step-by-step order (best-case scenario):
- A need to burn currency arises.
- One person (Mr Burn) proposes a motion specifying an amount of NuBits to burn and how many NSR he wants to receive in exchange.
- Shareholders vote
- The motion passes
- Mr Burn burns some NuBits using the new RPC (and proves it?)
- Mr Burn submit a NSR custodial grant
- Shareholders vote
- Grant passes, Mr Burn receive its shares.
What if(s) :
There are N persons submitting a proposal in step 2? I can think several different scenarios of things that can happen. I guess we just created a competition/market, where the fastest/best proposal can pass fast(er). Unless N persons get together under a single motion.
I want to invite everybody to reflect about worst-case-scenarios.
I am glad this proposal enables the scenario Jordan described to happen. Were not for this proposal I was going to make a proposal to create a custodian of NSR (from existing undistributed NSRs) just for rewarding LPCs. Without easily rewarding with NSR, LPCs are rewarded with printed nubits which is not good.
So if someone makes a motion to burn x nbts for y nsrs and passes it, and if that person actually burns the x nbts, there is no guarantee that he or she will get the y nsrs although it is highly likely that he or she will according to
The issue that i see is that once the motion is passed, the nsr custodian grant could take a long time to pass and the burner might have to wait a long time but it is probably tolerable since such a need for burning would not arise often times, only under an emergency situation.
However under an emergency situation, we need to act quick…
So perhaps we would need to amend quickly the protocol in order to make automatic the process of burning nbt for nsr by combining the motion with the custodial proposal into one step.
LPCs rewarded with printed NBT may not sound great, but they provide a service to the network. The created NBT are collective assets Jordan mentions in another thread. I also think that we should use NBT by default if we believe in our own stable coin as a token to exchange value. When we think there are too many NBT we can always burn some NBT for NSR. That is where this motion comes in in my opinion.
NBTs in circulation are liabilities, not assets. More printed NBTs just push the burning day (supposed to be emergency meansure) closer.
Paying out NSR is good in that it gives more transparent pain to shareholders. The shareholders will be more disciplined.
NBT can be used to create new value for the network. So it is a kind of potential collective asset when it is created for a purpose, but indeed a liability if it is not used as such. NSR are shares not a primary means to transfer value.
I’m with you with the transparent pain when there is no value for the network created. I don’t see a problem when there is adequate value created.
These NSR are just not spendable. It’s enforced by the protocol: nobody can sell them. They are burned.
If he does all the operation under the same username and nobody else claims the burning it’s not really needed unless there’s a possibility his forum account may have been compromised.
He can prove it by signing a specific message (for example something containing his username and his NSR custodian address) with the private key of one of the inputs of the burning transaction(s).
Shareholders are responsible for not allowing too much burning. When new proposals appear they can adjust their vote if that changed their mind.
I have been thinking the “NuShares” in the “Burned NuShares will not be counted …” clause is a typo for “NuBits”, because it is the currency (NuBits) that is going to be destroyed (burnt), not the share. The shares involved are going to be created by the protocol to dilute the share base. Am I totally wrong?
It’s not a typo but indeed this is confusing.
While writing the motion I had to consider whether the new burn RPC (which is intended to burn NBT) would also be allowed to burn NSR. Since burning NSR is already allowed by the protocol (even if there’s no easy way to do it), I assumed the RPC should allow it. And it can be useful tool for shareholders too if they ever want to reduce the total NSR supply. The fact the NSR supply can be reduced has some implications though, that I formalized in the motion. One of them was making explicit the fact that burned NSR would not count in dividend distributions.
Oh OK. You are only asking technical protocol questions to enable currency burning in general.
i vote for bda115840291067ba0814032f0c93d4d5900a5cf
The mint reward will be adjusted according to the total number of NuShares in the network. Specifically, each time the supply of NuShares reaches 50% and 100% of its original base (1 billion), the mint reward will also increase by 50% and 100%. For example, when NSR supply reaches 1.5 billion, the reward should be 60 NSR. At 2 billion, 80 NSR, at 3 billion, 120 NSR, at 4 billion, 160 NSR, and so on.
If the total supply goes below one of these thresholds (because of burning for example) the reward will be reduced accordingly.
The Number of total share is inflated - How will it impact price (or perceived value) per share?
This passed in less than 8400 blocks, indicating that shareholders are quickly responding to newly proposed motions and grants. Passage in this short window also indicates there is broad support for the action.
Let’s implement this motion in the 0.6.0 version of the client.