I like the first option. It is simple and compatible with “creation of NBT via parking rates”.
With parking, Nu creates additional NBT corresponding to n% of parket NBT (could be the whole supply in theory); With burning, Nu destroys m% of whole supply of NBT.
EDIT: additional information.
I like this better because I have little idea how the rate can be determined but I think burning is critical to have. So I want to have it in two separate processed. “Having a burning mechanism” or “Will burn 300m NBT” itself is a huge stablizer.
I imagine once shareholders figure it out the rate, the rate will be calculated from some data feeds. An adjustable rate could allow either be set by hand or by decentralized data feeds (less human factor).
For me I would accept nubits prices to fluctuate by a couple of percent if in return significant existential risks of Nu can be removed. Especially such fluctuation is slow, in a time scale of months.
You understand this would be intended to be used in emergencies, right?. It could be used when the peg was at risk of failing. Perhaps the shareholders deserve to have their shares decrease in price if they allowed NBT amount increase to a point that a currency burn was needed.
I would vote for 5 , shareholders votes for a specific amount of NuBits needed to be burnt and the protocol run a NuShares auction, burning NuBits is for emergencies and it should be successful whatever it takes, so leaving the rate to the auction is the best option.
Even if this option adds a significant amount of complexity in the code, but it would facilitate the future transition to a more automated mechanism where the protocol itself start the auction depending on the Shares holders Schelling price feed.
Options 1 and 3 are the only ones that have appeal to me. Option 1 is simpler but option 3 allows for more shareholder control. The question of whether the extra control is worth additional protocol complexity is a difficult question. I need to think more about the risks of the protocol behaving in unexpected ways with this extra complexity, and weigh that against the risk of not having control over the exact amount of currency to burn. The rate, because it uses a median value, can be changed rather quickly, but there is no guarantee that a large amount of currency won’t be burned in a single moment, just when shareholders wish to stop it. Even if that did occur, additional currency could be created to compensate.
I’m still thinking about how the additional complexity of option 3 might be exploited or lead to a fork.
Instead of allowing a potential attacker or privileged person to capture all or most profitable burning opportunities, limit the amount each person can burn by making it proportional to the number of NuShares they control. This aligns the interests of shareholders in protecting the Nu network with the reward of burning NuBits in order to buy NuShares at a discount when stimulating demand for NuBits. In addition to the increased safety, it is also more fair to shareholders.
Additionally, establishing a set rate to properly stimulate the desired amount of demand is extremely difficult to determine precisely. If the rate is too low relative to expected market conditions, not enough people will opt to burn NuBits. If the rate is too high then NuShareholders end up paying a greater dilution cost than was necessary. Therefore, I recommend a NuBit burning rate that changes over time.
Add a function to NuWallet that enables or disables NuBit burning. Ideally, it would allow you to customize conditions for when you would like it to be enabled, and a total number of NuBits that you are willing to burn.
Allow shareholders to vote for the following terms:
Quantity of NuBits that can be burned per solved block. (N)
Initial NuShare reward that can be earned when burning N NuBits per solved block. (S)
Rate at which the NuShare reward (S) changes per solved block. ®
Total number of NuShares that can be awarded in this manner. (T)
If NuBit burning is available, a minting shareholder may choose to burn NuBits (N) in order to receive an additional S NuShares each time they solve a block. Each time a solved block burned NuBits, the NuShare reward (S) decreases by R. Each time a solved block did not burn NuBits, the NuShare reward increases by R. This can be conceptualized by thinking of a solved block that burned NuBits as a vote for “The current rate is a good deal; perhaps slightly too good; therefore I should take it!” whereas a solved block that chose not to burn NuBits is a vote for “The current rate isn’t good enough”. This allows the rate to adjust based upon actual beliefs of individual shareholders, and it also allows it to change more quickly and naturally with respect to market conditions.
A few more thoughts:
Another reason it would be advantageous to require NuShares to burn NuBits is that the dilution cost to NuShareholders would be lower than if the burn rate were available to anyone. This is because NuShareholders probably value NuShares more than non-NuShareholders on average, and therefore would require a lower discount rate to be willing to purchase additional NuShares. Non-NuShareholders would be more likely to be interested in acquiring NuShares at a discount for the sake of arbitrage, whereas NuShareholders would likely keep more of the NuShares they acquire through this method.
An additional “acceleration” variable could be voted upon which affects the rate at which the rate ® changes (as described above). This would allow the NuBit/NuShare burn rate to respond more rapidly to changing market conditions. If several blocks in a row opt to either burn or not burn, it makes sense to change the rate more rapidly.
A system like this is a potential source of decentralized buy side liquidity. The current system involving custodians is expensive and vulnerable to certain kinds of attacks. This NuBit for NuShare burning system could incentivize shareholders to provide significant buy-side NuBit support. For those who believe strongly in future NuShare growth, competition for NuBits could be sufficient to replace most of the buy-side demands required of custodians. It may only require a very small discount to stimulate this demand, perhaps less than the current NuShare cost of achieving the same amount of demand from custodians.
After some additional thought my view is the additional complexity of option 3, with its associated heightened risk of unplanned forking or exploit, imposes a hazard greater than the benefit of additional shareholder control over the burning process. Please consider the following scenario to understand why:
Suppose we implement option 3 from the original post, allowing shareholders to specify an amount of currency to be burned, where currency burners specify their burn as fitting within the limits of a specific allotment. Say a specific allotment is 1,000,000 currency units. At a particular block height, 995,000 of these units have been burned, leaving 5,000 currency units available for burning. At the same instant, two burn transactions (we will call burn A and burn B) of 3,000 units each are broadcast to the network. The protocol does not permit both of these transaction using option 3, although each transaction by itself does meet the protocol specification (but they are both permitted under option 1). In other words, option 3 creates a scenario where whether a transaction is valid depends on other transactions. This situation is not unknown in blockchain implementations and is comparable to double spends in some ways. In a double spend the existence of the first spend makes the second invalid, just as in our scenario the existence of the first burn makes the second invalid.
Let’s continue observing how this ‘double burn’ plays out in our network. Part of the network sees burn A first and rejects burn B as invalid. Another part of the network sees burn B first and rejects burn A as invalid. A block is found by a client that accepted burn B. Within a second a block is found by a client that accepted burn A.A fork one block high, such as is seen many times per day is now under way. But this fork has a different cause and will require a different resolution than an ordinary fork where all transactions are valid. It is also different in nature than a fork caused by a double spend and requires special code to resolve (to expunge a burn transaction and its associated NSR creation transaction from the memory pool based on the presentation of a conflicting transaction presented in a broadcast block).
What if this arcane, unlikely but clearly possible scenario were overlooked during coding? What if some variant of the scenario is not understood and not handled by the protocol? What if three years from now developers not involved in the project now implement a protocol change that alters the handling of this unusual situation, being unaware of the details of the scenario? The flaw would be unlikely to be uncovered in testing. The protocol flaw could be introduced without any problems initially, only to have a disastrous fork occurs two years later, resulting in many double spends and an emergency protocol change.
Our 0.5.0 release featured a protocol flaw that caused a permanent network fork long after the protocol change date, so these things do happen. An unplanned network fork due to a subtle and latent protocol flaw may be the biggest risk to decentralized networks forging consensus based blockchains such as Nu, Bitcoin and Peercoin.
As a result, I believe the protocol simplicity permitted by option 1 is of greater benefit than the additional control offered by option 3.
This one appeals to me the most. The decision, amount, and rate are all atomic. Per JordanLee’s concern about forking, I would think that a binary pass/no pass would mitigate that to some degree.
If multiple proposals could be voted on concurrently, then I think this could approximate the fluidness of continual adjustments. This could easily be adapted to feeds – “burn proposal #1 … #2 … #3” etc
Edit: interesting. When quoting a list, Discuss renumbers starting at #1. This was idea #2 from the above
I agree option 1 is the most simple to implement and thus reduces the risk of introducing bugs.
But the scenario you describe with option 3 would not be a problem. There will be code to prevent too much currency to be burned, and it’s the same code that will solve the fork you describe. There’s nothing special here, except maybe we will have to clean up the memory pool transactions that became invalid because enough currency have been burned. But that’s something we will have to in option 1 too (for example when the rate changes and some already accepted transactions become invalid), and also with the upcoming dynamic fee system. We don’t need special code to resolve the fork. All the proposed alternatives require some new checks before a transaction is added to a block to make sure the block won’t be rejected. But that’s not consensus code: a bug here would just make some blocks rejected by every nodes (including the node producing it), it would not produce a fork.
So options 2, 3 and 4 don’t bring more risk of forking besides the fact they require somewhat more complex code.
They could. That’s what I tried to express here:
I’m all for simplicity to start with 
Option 1 please.
Can someone describe an expected list of steps for burning. For example
That’s not what is planned. Burning currency would generate new shares.
I planned to propose we introduce a maximum burning amount per block, to prevent a single shareholder from burning all the available currency. This maximum could be voted too.
If it’s sent before (with the correct rate) the transaction may eventually be confirmed, but most likely it will be rejected by the nodes because it’s not valid yet, so you’d have to send it again when it becomes valid.
If it’s sent after the maximum allowed has been burned, it will never get confirmed. So it’s like a return, because the coins will not be spent.
It’s probably feasible. If there’s an interest for it I can think about a possible implementation.
About option 1 and all the alternatives where the rate is adjusted, note that even if all the shareholders vote for the NSR market price as burning rate there will always be a lag behind the market. If the median is calculated from the 10,000 previous blocks as planned in Jordan’s initial motion, the burning rate would always be the NSR market price about 3.5 days earlier.
A possible way to fix that would be to elect one (or more) person to decide the actual price. Shareholders would only decide whether burning is allowed, and who is responsible to decide the price.
While that would solve the problem with the lag, it would introduce a new dependency from a person (or persons).
Could you imagine a solution that would be based on a kind of feed, a feed that provides market information form several exchanges to make it hard to game the market price.
The share holders would then decide whether burning is allowed based on price from feed x, y, z.
The motion that allows burning would need to tie the burn rate to the information provided by the feed(s). I for one prefer a dependency from a feed to a dependency from a person.
The problem I see with that approach is that it introduces an attack vector by manipulating the exchange rates or the feeds.
If someone would plummet the price by selling large amounts of NSR, the burning of NBT would create even more NSR compared to the price before the big selling.
So it would be incentivized to sell large amounts of NSR (for NBT), burn those NBT and maybe get more NSR back than have been burned before.
That could create a race to the bottom or it could stabilize the price, because the dropped price could trigger buy orders.
This is one of the problems that need to be thought of, because it basically applies to burning in general. It might just be easier to game with that by burning based on rates by feeds.
The problem is we need an exact consensus on the price. We can’t achieve that from external sources. What if some nodes have trouble contacting feed y, while the others don’t? The network could split. The price must be determined from the blockchain.
I understand.
If the motion deals with burning based on rates from a feed (or feeds) I could imagine that this rate information is written into the block chain together with the vote for the motion.
But once the motion has passed there’s no need to continue voting on that motion and there’s not necessarily the rate written into the block chain.
And even while voting it would need to be guaranteed that the rate is really the rate from the feed.
It seems I’m out; doesn’t sound feasible.
The risk of splitting the network by writing feed information into the block chain while voting and the scenario that some clients can contract the feed while others can’t, remains.
Please allow me to ask one more question:
how would those trusted persons put the information into the block chain in a reliable way?