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.
Can someone describe an expected list of steps for burning. For example
Someone perceives the need to burn 1M NBT
She puts forward a motion to burn 1M NBT using one of the methods in the OP (may or may not specifying a rate of X NSR = 1 NBT)
Shareholders vote for it and it passes
Then what? How does the burn actually take place? This affects the form of motion in step 2. Are the sharehlders expected to sell their own shares to buy nubits to burn? If burning is profitable to the burner, would the market expect the motion to pass and buy up NBT before passing, and try to dump these NBT to the burn address all at once right when the last voting block comes in? What happens to the NBT sent to the burn address before passing and after 1M NBT is sent? Will they be returned or burnt? I see great possibility of chaos and incentive for gaming-the-last-voting-block here. When the NBT buyers get their SNR (at a favorable rate) after burning they probably will dump them to pay for the cost of buying those burnt NBT, probably causing volativity in NSR prices. In light of these, maybe burning should be executed in a throtlle way. Auction does seem to be conceptually nice but I guess it’s hard to implement it on the blockchain. Or is it? It’s just voting with pledged shares in an auction period, right?
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?
Compared with all these alternatives, I like what @benjamin suggested most.
It is an effective and the simplest way to convert NBT to NSR.
Since we will need dividend payout custodians anyway, It actually doesn’t introduce additional role and risk to the system.
There are multiple possible ways. The first that comes to my mind is allowing special transactions signed by an allowed person and providing the price in an output (the transaction would not move any amount).
The problem is we can’t achieve consensus from external data. Also, we need to be able to get the price in the past (when you download the initial blockchain). We could record the price in the blockchain, but that’s the same as allowing shareholder to vote for a rate.
Wouldn’t that be possible with a feed as well?
Could those (administrators of the) feeds that were part of the motion not be provided with the keys to sign these transactions?
That would still require people to initialize the whole setup, but then it would provide the rates automatically by signing the transactions and writing them into the block chain.
Ah I got confused there. I mentioned shareholders above because I thought shareholders are probably most interested in selling their shares to buy NBT in order to get more shares back.
At the moment I agree #1 seems to be the best option because it is simple and good enough.
There is a conflict of interest in this vote-burn scheme which should be studied. Currently we think that the shareholders collectively want a low conversion rate X where X NSR will be generated for 1 NBT burnt, because shareholders want low inflation; the burners on the other hand want a high rate to generate more return. If the voted rate is too low there won’t be enough NBT getting burnt. We assume this conflict can be solved by shareholders’ starting at a low rate and gradually increasing it until there is a healthy burn going.
The interesting part to note is that a high burning rate could cause serious inflation to nushares. This inflation is not exactly equal to all shareholder. It will put those shareholders who don’t or couldn’t burn at disadvatage. So I think the burn voters are incentivized to vote for high rates, basically to reward themselves. If the burn rate is allowed to be far higher than market rates, it could be a powerful deflation mechanism for nubits, and nushares would have a proof-of-burn mechanism to distribute new shares (which doesn’t sound bad). Manipulators will probably get interested in becoming big shareholders, set rates and profit from it. Exchanges with a lot of shares, too.
True.
In the scenario you depicted you should also think that Shareholders are also likely to be NuBits Holders.
And if a burning rate is appealing enough, I imagine shareholders will be among the first to notice, and take the opportunity of buying NuBits (from custodian sell walls), just to burn them and obtain NSR at a better rate. In this scenario, also consequences on custodians walls needs to be taken into the equation. Not a problem as these events .
There is also arbitrage to keep into account : The burn rate is static, isn’t it? I think that the burning rate will make NSR price converge to that value.
If the burn rate offered is higher than NSR price in open markets, even for a limited time, its a window of opportunity for arbitrage. Buy NBT, burn NBT, sell NSR. Repeat until NSR price on open market goes below burn rate.
The main point is that the burn rate setters and NBT burners will be the same people if burning is executed by minting blocks (random arbitrageurs can’t just buy NBT and burn them for NSR). It is basically someone moving higher fraction of nushares wealth to themselves (while increasing NBT reserve ratio). Note that less than 15% of peercoins mint. This will get people to mint, but also push down NSR unit price.
