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.
