After some additional thought my view is the additional complexity of option 3, with its associated heightened risk of unplanned forking or exploit, imposes a hazard greater than the benefit of additional shareholder control over the burning process. Please consider the following scenario to understand why:
Suppose we implement option 3 from the original post, allowing shareholders to specify an amount of currency to be burned, where currency burners specify their burn as fitting within the limits of a specific allotment. Say a specific allotment is 1,000,000 currency units. At a particular block height, 995,000 of these units have been burned, leaving 5,000 currency units available for burning. At the same instant, two burn transactions (we will call burn A and burn B) of 3,000 units each are broadcast to the network. The protocol does not permit both of these transaction using option 3, although each transaction by itself does meet the protocol specification (but they are both permitted under option 1). In other words, option 3 creates a scenario where whether a transaction is valid depends on other transactions. This situation is not unknown in blockchain implementations and is comparable to double spends in some ways. In a double spend the existence of the first spend makes the second invalid, just as in our scenario the existence of the first burn makes the second invalid.
Let’s continue observing how this ‘double burn’ plays out in our network. Part of the network sees burn A first and rejects burn B as invalid. Another part of the network sees burn B first and rejects burn A as invalid. A block is found by a client that accepted burn B. Within a second a block is found by a client that accepted burn A.A fork one block high, such as is seen many times per day is now under way. But this fork has a different cause and will require a different resolution than an ordinary fork where all transactions are valid. It is also different in nature than a fork caused by a double spend and requires special code to resolve (to expunge a burn transaction and its associated NSR creation transaction from the memory pool based on the presentation of a conflicting transaction presented in a broadcast block).
What if this arcane, unlikely but clearly possible scenario were overlooked during coding? What if some variant of the scenario is not understood and not handled by the protocol? What if three years from now developers not involved in the project now implement a protocol change that alters the handling of this unusual situation, being unaware of the details of the scenario? The flaw would be unlikely to be uncovered in testing. The protocol flaw could be introduced without any problems initially, only to have a disastrous fork occurs two years later, resulting in many double spends and an emergency protocol change.
Our 0.5.0 release featured a protocol flaw that caused a permanent network fork long after the protocol change date, so these things do happen. An unplanned network fork due to a subtle and latent protocol flaw may be the biggest risk to decentralized networks forging consensus based blockchains such as Nu, Bitcoin and Peercoin.
As a result, I believe the protocol simplicity permitted by option 1 is of greater benefit than the additional control offered by option 3.
