**Draft** motion for currency burning

NuShares Motions
#5

I agree that in theory it would be useful to permit shareholders to specify a quantity of currency to be burned. While it can be done, I have been unable to devise a method that is sufficiently simple and elegant, as complexity in the protocol compromises security and reliability.

Let’s examine what the above proposal by @dongshan would look like in some detail. Shareholders could place a vote to permit a certain quantity of currency at a certain address to be burned in exchange for a certain quantity of NuShares. The vote contains these pieces of data: 1) a currency address, 2) a currency quantity, 3) a NuShare quantity and 4) a NuShare address. If the majority of blocks and share days in a 10,000 block period contained the same value for these four elements it would be considered passed, meaning the exchange of currency for NuShares would occur.

One problem with this is that you are allowing shareholders to destroy someone’s currency, which is not necessarily the will of the currency holder. It could be used to destroy currency at a particular address in exchange for zero NuShares. This is undesirable. To avoid this, we could say the vote doesn’t force the exchange but just permits the owner of the currency to choose the exchange by signing the transaction. In that case, the currency address private key is used to sign a transaction much like I have proposed except that the protocol only permits the exchange if the addresses and amounts have been previously approved by shareholders.

This solution requires that the entity signing the exchange have sufficient funds available to purchase the currency to be burned, whereas my proposal permits an unlimited number of people who already possess currency to exchange it. It also requires a much longer latency between when the exchange rate is chosen and when the exchange is effected (maybe three times as long), which means the exchange rate is likely to be further from the present market rate. Imagine the common scenario where the market value of NuShares declines between the time a proposal is submitted by an entity willing to burn currency and the time that proposal is passed by shareholders. The entity will lose value by signing the exchange, and is therefore likely to decline to do so and submit a new proposal at an updated price.

I have described what I understand as the details of dongshan’s proposal to highlight the deficiencies in hopes that someone can devise a modification that removes them. As presently described, I believe the problems introduced by the proposal are greater than the problems solved.

Burning a specific amount of currency
#6

Here is @dongshan’s objective:

Perhaps a max quantity could somehow be included with the burn rate vote?

Burning a specific amount of currency
#7

Because NSR are created in different transactions in different blocks, there isn’t really a limit to the number the blockchain can support. There might, however, be limits on what can be returned by the getinfo RPC that calculates the total money supply. @sigmike, can you verify that the calculation of the total money supply, which this proposal would depend on for determining the minting reward, is not limited by an int32, which would limit it to 2 billion? This is worth looking in to because I have heard it said that Peercoin imposed a limit of 2 billion on its money supply. If this is true, it is likely we have inherited the same limit. This number is consistent with the use of an int32 as the cause, which could be remedied by using an int64 instead.

#8

Initially, I really hated the idea of creating additional NSR through any means other than minting. I believe that serious investors will desire predictable supply growth.

After having thought about it for a while, I realize that there is not much harm that could be done because it’s simply not likely that there will be a burn rate greater than zero unless the peg became quite unstable. No rational investor would ever vote for a burn rate greater than zero unless the risk of NSR value loss due to a failing peg was greater than the risk of NSR value loss due to creation of additional NSR.

I believe that Jordan has outlined a good approach.

#9

If we use an unsigned int64, we could support up to 18,446,744,073,709,551,615 NSR. That would probably be enough for now. :laughing:

#10

First of all, I agree that this is the only state where shareholders are likely to offer burn rates. Voting for rates that dilute shares while they are profitable goes against the economic self-interest of a shareholder.

I still struggle a bit with how this burn proposal will work in practice. For the purposes of simplicity I’m imagining a single-currency system like the one that currently exists. When this retirement scenario is reached, it implies that the demand peak of the individual currency has definitively passed. In a scenario where demand is decreasing and is forecasted to never again reach a new peak, the value of NuShares should be equal to its intangible assets (whatever the intrinsic value of its branding elements, the number of existing users as defined by Metcalfe’s Law, etc.). There shouldn’t be any additional value present in the price because future dividends would be expected to be zero.

In that scenario, it should already be very easy for a speculator to buy a large amount of NuShares on the open market for cheap. In a situation with very cheap market-rates for NSR, this would lead to very large NSR/NBT burn exchange rates being offered, to the point that very few NBT would be purchased. This is the same final outcome that is present in our current design.

(I shared this with Jordan privately but want to include it publicly just in case anyone has any thoughts):

In my view the current weakness of NuBits is that the network is attempting to monetize ownership of a permanent asset that unfortunately has an eventual obsoletion date. This is at odds with traditional views of the permanency of money. A different approach to structuring should be to monetize not the asset itself, but the value the network provides (convenience, speed, privacy) by charging variable transaction fees. It looks like this feature might be included in Nu in the future, which is great.

I think the monetary policy that allows for expansion and contraction of NuBits while placing the risk on NuShareholders should come through two mechanisms:

  1. Shareholder adjustment of the transaction fee. I originally thought that distributing transaction fees to shareholders would be ideal, but Jordan correctly pointed out that destroying them achieves the same functional purpose. Larger transaction fees correctly monetize the value the network provides and allows for very flexible expansion and contraction of the currency supply.

  2. Extremely conservative dividend rates. If the system only distributes dividends for NuBits that can confidently be said to have been lost forever or abandoned (1% per year? 5% per year?) it significantly reduces the chances of a mass number of users being left holding the bag. In this design, if an exchange fails and steals the custodial USD funds present on its books, losses would be covered by the dividend funds set aside by custodians. This coverage would lead to a decrease in expected dividends and would negatively impact the price of NuShares. Thus, NuShareholders would be fairly penalized for their poor choice of an exchange.

3 Likes
Speculative Attack on Nubits
Burning a specific amount of currency
Possible solution to custodian loss of value due to BTC exposure
My Economic Analysis of the Nubits System
[Discussion] Tier 7 liquidity: Volume-dependent transaction fees and "Restricted Network Access" status
Fractional reserve security on the Exchanges!
Speculative Attack on Nubits
NuBits vs BitUSD (Bitshares)
#11

There is a very limited power in this mechanism, I think. Transaction fees would have to be prohibitively high in order to have a noticeable effect on NBT supply. $0.01 fee already seems reasonable. Would you use NuBits if the transaction fee were USD $1? I expect not. Of course, this is just a guess.

OK, let’s look at the worst-case scenario: demand for NBT has peaked, and is in a potentially-permanent decline. Expected future dividends are near zero, so the value of NSR is low.

It may be that the total amount of NBT that needs to be burned to save the peg is greater than the total market cap of NSR, which means that even this mechanism fails to save the peg. However, it’s still a step in the right direction.

#12

I think this range may not be optimal, in the case that NuShare supply grows arbitrarily large. I would propose instead a quantity of one thousandths (1/1000), which allows votes between 1NSR for 1000 units of currency, and 4,229,400 NSR for 1 unit of currency. Alternatively, a quantity of ten thousandths (1/10,000) might be best.

However, even if the first motion is passed as it stands, it may be within the discretion of the Nu dev team to make this amendment without a supplementary motion, considering that the functionality is nearly equivalent.

#13

If there is controversy about the range permitted, it may make sense to use uint64. This requires an extra 4 bytes of blockchain space for each vote, but considering that burn rates will rarely be voted for this is probably not very important. It would also provide us additional granularity on the burn rate.

Therefore, I intend to change the draft motion to use uint64 where the quantity will consist of billionths (1/1,000,000,000) of a NuShare satoshi. This will permit shareholders to vote for as little as 1 NuShare for each billion units of currency. I haven’t done the calculation the other direction, but it is safe to say more than a trillion NuShares could be offered per unit of currency.

#14

Pillow at Peercointalk had an interesting idea: timelock the NSR granted by burning. What if the received NSR could not be moved for 7 days (10000 blocks), for example? This would prevent the user from dumping them on the market immediately, helping to protect the value of the network.

#15

I totally agree with you about #1. Here in China, bank transfer fee is set at 1% of the amount of transaction , with the limit of min 2cny and max 50cny,
Only concern about #2 is how to safely hold those dividend if they are not distributed in time.

1 Like
#16

Sorry, the mechanism mentioned in my previous post is not thoughtful. Just as Chronos point out, my objective is find a way to let some exact amounts of NBTs to quit circulation.

#17

Doesn’t this mean it only shifts the dump-risk of one week in the future?

#18

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.

1 Like
Burning a specific amount of currency
#19

That’s much different than using a rolling median. However, it seems that the identifier-quantity feature could be used with the 10000-block median vote outlined by Jordan. Is this correct?

Burning a specific amount of currency
#20

Assuming the cause of the trouble in maintaining the peg is that there are too many NBT in circulation (Nb) compared to the networth of Nunet in dollars (call it V for value), then the amount of NBT burned (x) to restore equilibrium can be calculated. The euqation is Nb - x = V + Rb * x * (V/Ns), where Ns is the total number of Nushares, Rb is the burn rate (Nushares per Nubit), and (V/Ns) the Ns price per net value of Nunet. If we use market price of NSR/USD for (V/Ns), then x can be calculated with a given Rb.

A special solution is Rb=0, which means someone holding NBT burns NBTs without getting any NSR in return, until all excess NBT is gone.

V is a combination of how many USD in NuNet reserve, how much liquade asset NuNet has, and profit earning prospect. The price of NuShares (V/Ns) and the ending of the NuNet is tied to these three factors.

#21

Yes we could have the rate voted separately with a median. The other vote would only allow a certain quantity to be converted.

Burning a specific amount of currency
#22

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.

#23

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 :wink:

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
#24

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.