I’m pleased to be able to announce the Nu client version 1.1 beta release. The follow upgrade is NOT mandatory and contains no protocol changes. Here is what is included:
Prevent wallets from adding transactions in other units
libcurl upgraded to 7.41
Private keys now have unique prefixes for each unit (exported keys cannot be imported into previous wallet versions, but older keys can be imported into the latest version)
getparkvotes no longer crashes the client
hotkey button for shares menu changed to “a”
“burn” rpc call added to burn NBT or NSR as transaction fees.
It’s a new RPC command called “burn”. Users can find the syntax by typing “help burn” into the debug console or with the nud. There’s quite a bit of change happening with the documentation, so we’ll try and update it once that’s finished.
Is there a way to “burn to an address”, i.e. to send 0 NBT with X NBT tx fee to a specific address such that the X NBT get burned and the transaction is recorded on the blockchain? This, or any other way to categorize burns publicly, could be very useful in future.
That’s what it does but you don’t set the address ahead of time. The transaction is a “burn by fees”.
Any NBT or NSR burned this way can be viewed in the block chain as a tiny output with a fee for the amount to be burned. It will be visible in the block explorer.
Am I missing a use case where you would require the address to be known ahead of time?
But I have no influence on where the empty transactions ends, right? I didn’t check the code, but I assume its a transaction to myself. So yes, you can detect burns by scanning the blockchain for transactions with large fees and which end in the sending address.
However, there is only one “kind” of burn. But burning allows for many many different applications in our case, which requires to color / mark the burns somehow. If we could “burn to an address” like described above, then we could create the public keys of unknown addresses (like Counterparty did with BTC) and categorize burns according to their destination address.
For example we could create to burn destination addresses A and B. If you burn to A, then then next block creates NBT at your address at a shareholder defined rate. If you burn to B, then the next block also creates NBT at your address (much less), and if you burn the same NBT + some fees within 2 weeks then the following block will recreate your NSR. So with burning we can make financial market offers to the shareholders which they can take at any time by initiating a corresponding burn of their NSR. These are just examples of course.
I just think that burning is one of the most important tools for us, because it allows to give money to the whole DAO and not to an individual, just as grants are paid by the whole DAO and not a single entity.
The problem with this solution is the client cannot know its a burn address. So the money supply cannot be updated automatically. The only way to make it work would be to hard code some special addresses in the client (or at least some prefixes). We chose another solution in the motion (and this particular issue was discussed there). But implementing that feature is low priority right now because we can already burn as fee.
I see, thanks for the clarification. And writing something behind the OP_RETURN also won’t work as mentioned in your post - at least not without another protocol change that considers coins as burned when the script after OP_RETURN satisfies particular constraints. Anyway, I think we already can do a lot of great things with the current implementation.