I think using the excess fees as the burned amount will makes the code complex and error prone. It will be even more complex when the fee becomes dynamic. I’d rather use the standard burning mechanism we already use: provably unspendable output with OP_RETURN. And it would allow us to add meta-data.
Right now the unit (NBT or NSR) of a transaction is recorded at transaction level, not at output level. That means that we cannot take NBT and output the change in NBT and the shares in NSR in the same transaction. That was a design choice and I’d rather not change that just to allow this burning process.
Instead we could use 2 transactions: 1 to burn NBT and 1 to generate NSR. The 1st one would make the network accept the 2nd one.
A burning transaction would take some NBT inputs and output the burned NBT to an unspendable script that also provides the NSR address that will be allowed to generate the NSR. The change would be sent to another output as usual and the same fees as in other transactions would be required.
The NSR generation transaction would take the burned NBT as input (without any signature) and output the generated NSR. The network would verify that:
- the input is a burning transaction (and it’s the only input)
- the input has not already been used to generate NSR
- the output address is the one recorded in the burning transaction (split outputs would be allowed, but all to the same address)
- the total output amount is equal or less than the NSR rate multiplied by the amount burnt (the NSR rate being the vote result in the 60th block before the one that confirmed the burning transaction)
This would be the only situation where a cross unit transaction is allowed (input in (burnt) NBT and output in NSR).
I think both transactions could be confirmed inside the same block, but I’d have to verify that.
All the amounts are expressed as signed or unsigned 64 bits integer so the theoretical limit is 9 223 372 036 854 775 807 satoshis (9e18). But there’s an extra MAX_MONEY constant used at many places that limits most amounts used in the protocol. I think it exists to avoid mistakes and overflow errors. This limit is 2 billion coins right now (20 trillion satoshis). That means you cannot sent or receive more than 2 billions in a transaction. That applies to both NBT and NSR. We can change this value easily (although it’s still a protocol change).
But these limits only apply to individual or transactional amount, not to the total supply. The total supply is not recorded as a value in the blockchain, it’s just the sum of the generated units. The client does record that data in an int64 but it’s only used to display it in the getinfo RPC. Having a total supply above the int64 limit would not break the network, it would just make getinfo return a negative supply.
If we plan to use the total supply as protocol data (to change the reward for example) and expect it to overflow then we can store it in a BigNum (an integer of arbitrary size). But we would also have to do that with many other values (the wallet balance for example). But I think the current limit (9e18) is large enough.
One way to do that would be to vote for a burnable amount with an identifier like we vote for custodians with an address. Once a burn amount has been granted people would be allowed to burn NBT with this identifier until the burned amount on this identifier reach the voted amount.
For example a shareholder could vote to burn 1 million NBT at rate 0.003 with identifier “1”. If the majority of shareholders vote for the same amount and rate on this identifier, then this burn vote passes and is recorded in the blockchain.
The network would then allow burning transactions that mention the identifier “1”, but only until the total burned amount on this identifier reach 1 million. After that any burn with this identifier would be rejected by the network.
There may be multiple burn identifiers allowed at the same time.
