Yes we could have the rate voted separately with a median. The other vote would only allow a certain quantity to be converted.
My proposal was based on the premise that the currency marker was at the output level, not the transaction level, which means some modifications are needed.
I am hesitant to use two separate transactions because the two actions (currency burning and NSR creation) should either both fail or both succeed. Using separate transactions introduces an opportunity for one to succeed and the other to fail. We can be certain many efforts will be made to attempt to make the burning transaction fail while permiting the NSR creation to succeed. Having NSR created based on a separate zero confirmation burn transaction seems particularly open to exploit.
One option would be to define a special type of transaction specific to burning where it is understood that the currency marker applies to inputs but that the outputs are always NSR. This would mean the outputs would be restricted to NSR, and would not be permitted to be a mixture of NSR and currency as previously proposed. This transaction type would be just like the popular Pay to PubKey Hash except that the outputs would be handled as NSR instead of the currency specified at the transaction level and it would have the special validation described in my draft motion content.
The protocol provides a mechanism for currency placed in an OP_RETURN to be restored via unparking. Using the same approach for burning brings with it a risk that someone will figure out a way to unpark a currency burning transaction. In contrast, there is no mechanism to restore transaction fees.
I’m not only hesitant, I consider it unthinkable, after having read what you wrote about using two transactions. If this process isn’t atomic it is easier to exploit it - just like you pointed out.
I don’t see important technical drawbacks by doing it that way. Does anyone see any?
One needs to use a proper input value, sure. That is made easier by coin control, because you’re able to split transactions so that there is the right amount that shall be burned available in a single transaction. As far as I got it, integrating coin control in the wallet (for both NBT and NSR?) is on the road map. So it is only a matter of time until it is available.
And it is matter of education to explain what preparations need to be done to avoid accidentally burning “wrong” (read: way too large) amounts of NBT.
So the drawbacks might be mainly in the fields of human error.
As long as coin control is not available you can use different wallets to make sure you have the right amount of NBT in the transaction you want to use for burning. That is not very comfortable, but very safe, because you can’t burn more NBT than you have in your wallet 
The option that you described sounds like a perfect way to make it as hard as possible to abuse this mechanism.
I understand that it’s expected to use the burn mechanism only in (hopefully!) very rare cases and that in “normal” times you receive 0 NSR for any amount of burned NBT.
But as a vote for burning is an action of last resort, it’s important that the shareholders can rely on the burning to not be exploited easily.
1 Like
masterOfDisaster helped me realize that not permitting change in currency is indeed less than user friendly, especially without coin control, which is currently planned for inclusion in version 0.5.1.
There is quite a bit we can do with the user interface to protect them from currency loss or converting a larger amount than intended to NSR. It might also be reasonable to use an ordinary transaction to create outputs of the perfect size to complete the user’s currency burning transaction. For instance, a user may wish to burn 100 NBT but he has an output of 140 NBT. An ordinary transaction could create an output of 100 NBT and place the rest in a change address. Then the 100 NBT output is used as the input for the currency burning transaction. From the user perspective, they are able to burn whatever quantity they want and the result is NBT in a change address and NSR in a specified address.
We would include a separate dialog for burning where the user can enter a quantity of currency to be converted, an NSR address and an optional currency change address (if not specified use one from the wallet). The interface would tell the user how many NSR they would receive and what their transaction fee would be.
In the background a preparatory transaction would be performed to create an output exactly the size the user specified for conversion. While this needs some verification, I believe the network would accept both transactions, but confirm them in different blocks.
@JordanLee Should voters consider the estimated cost to shareholders to have this feature implemented? The protocol and UI changes will take significant work that (I assume) will be paid out of the shareholder resources. Please correct me if this is not the case.
Thank you in advance for any details you can provide on this.
As is typical with software development, estimates of cost are difficult and subject to considerable inaccuracy. However, an uncertain estimate provides a better basis for decision making than not having any idea about the cost.
I’ll put forward an estimate of 8000 NBT for development and 12000 NBT for testing, which I will insist is quite extensive. So, I would estimate a total cost of 20,000 NBT.
Only vote for exchange rate is enough. When NBT works fine, we can vote for a very high rate to prevent exchange. But if sb. would like to exchange, these NBT could be profit immediately.
When NBT is over supplied, shareholders vote for a lower price to incentive NBT exchange to NSR.
1 Like
Only voting for exchange rate should be good enough. This rate would be variable and when shareholders are well-informed the rate would be adjusted when there are indicators that the money supply need to be decreased and large NBT bagholders are still interested in buying NSR.
Maybe it should also be possible to burn NSR and get NBT against that same rate, that way it would be easier to maintain a balance as unintended transfers can be easily reversed. Although unlikely to happen a minimum number of shares (e.g. 0.5b) should be hardcoded otherwise the network might fail to create enough blocks.
Did we just invent a decentralised exchange for NSR<>NBT (or any future coins we may list) here?
No. Only burning NBT can exchange NSR, never burning NSR for NBT. Because this system’s value is NBT equal to 1 USD for ever. All effort we make aim to this goal. We mustn’t make anything else which give risk on this goal.
1 Like
The goal is right. But since the share owners are already capable of creating NBT by offering parking interest, so letting them allow NSR->NBT exchange isn’t a big impact on principle. But I do realize it’s a slippery slope. The solution should be well thought out and critically reviewed on system level.
If it’s an end-of-currency problem we are going to solve, we still have time – Nu is only one month old. If the problem is that not having a burn mechanism is hurting adoption evidently, then we should start to work out a solution right away. From what I understand, Jordan thinks that offering a solution to questions one is a solution to question two. I am having difficulty knowing all the factors for an end-of-currency scenario. A convincing profit/revenue model seems easier to think about at this point as a long-term solution to the NBT over-supply concern.
When the price of NSR going down, shareholder will exchange to NBT and sell NBT on market for NSR. This can impact the buy wall.
How is that different from creating NBT through custodians by shareholders?
I agree that this needs more thoughts, but might have some advantages.
But I don’t see shareholders selling NSR for NBT as a problem given they already have capability to create NBT.
But I’m digressing, I think we should focus on the scenarios for an end game as that might be a marketing/trust issue when not addressed somehow.
We can make sure that the NSR creation transaction is not possible without the currency burning transaction. That’s how everything works already (you can’t spend coins you haven’t received).
We can’t make sure there will be an NSR creation after a currency burning though, but we can’t prevent it either (unless the majority of minters makes the efforts to prevent it).
So the minimum requirement is filled: people will not be able to generate NSR without burning a currency.
It’s not based on a zero confirmation transaction. It’s based on a transaction confirmed either in the same block or in a previous one. To be accepted in a block a NSR creation transaction needs a corresponding NBT transaction in the same block or a previous one. So if the NBT burning transaction gets unconfirmed for any reason, the NSR transaction also becomes unconfirmed and cannot be put inside another block until the new chain also includes the NBT burning transaction. Like any spend.
But you also need the change in NBT.
Also, having an exception about the currency of an output means we have to change all the code for which the currency of an output matters. It introduces complexity and we can forget to change some code or introduce mistakes. The design choice to use units at transaction level was to keep things simple and to strongly reduce the risk of a bug allowing unit fungibility. If we’re going to leave this paradigm we’d probably better just move the unit to the output instead of adding an exception, to at least keep simplicity.
And note that adding an exception to the output unit makes it possible to be exploited too. If we make a mistake in the code someone may be able to convert some NBT to NSR outside the burning process.
The code allowing an OP_RETURN output to be spent is clearly isolated and has very strong requirements. Adding another exception with requirements that do not overlap is easy.
The transaction fees system is complex and involves a lot of code split in many places (from the blockchain to the GUI).
I feel much more confident the unparking mechanism can’t be exploited to restore other OP_RETURN outputs than our ability to add this new complexity without bugs inside the already complex fees system.
This seems overly complex to me. To avoid creating 2 almost standard transactions in 2 different units we would create a first transaction to split the coins and then another one with a exceptionally different input and output unit.
I think they should. But as Jordan said it’s hard to estimate. In general the simple designs cost less in coding, testing and maintenance.
I may be able to estimate the time I need to code some of the designs that were discussed here, but it also takes time to work on these estimates. And when the design is complex it may be hard or impossible to estimate. And I can’t estimate the time required in testing and maintenance.
1 Like
Actually we can certainly force the 2 transactions to be in the same block. The block would be rejected if it doesn’t include the 2 transactions. We would have to change the way memory pool transactions are included in a newly generated block but it shouldn’t be too hard.
I haven’t forgotten about this but it has been deprioritized just a bit. At the moment there is not agreement between sigmike and I on how to proceed. I suspect we can come to an agreement by researching the code and then discussing the advantages and disadvantages of each approach further, but that will need to wait.
Makes sense to me. Even after this motion is passed, it will take time to implement. To me, this motion belongs in the “Important, but not urgent” category.
Different relative fees can be charged for different volumes of transactions, yes i will gladly pay 1NBT if i want to transfer USD $1000 abroad immediately and anonymously, and i would pay it also if want to use Nubits in arbitrage trading, and i would definitely do it if i can trust the sustainability of it, so i wouldn’t risk being the last fool and i wouldn’t have a hard time convincing others to accept them, especially those who have no bank accounts and no alternative cryptocurrencies.
I totally agree and wish it to be the future of Nubits.
After a long silence on this matter as a result of attending to other priorities, I’m pleased to announce good progress on currency burning. Sigmike, Giannis and myself have engaged in extended discussions and have arrived at a comfortable consensus regarding the best way to architect this important protocol change. The agreed upon solution looks more like sigmike’s proposal than mine, so sigmike will be presenting a finalized motion soon.
4 Likes
What do you mean exactly by obsoletion? sorry for bumping the topic
That quote was from over ten months ago and the network has changed considerably. The sustainability of NuBits has been strengthened because of all the reasons listed on the Price Stability page of nubits.com. I expect NBT to be a competitive decentralized digital currency for many decades to come.
2 Likes