**Draft** motion for protocol changes

The following is a draft of a motion I will be advancing for shareholder approval. I am presenting it as a draft to invite comment and suggestions for modification. It contains five protocol changes. The proposed motion only contains action items without presentation of the reasons for the proposed actions. I have presented the reasons for the changes separate from and below the motion itself.

Begin motion*
The following protocol changes are to be implemented by developing and distributing a Nu client release which will be a mandatory upgrade. By voting for this motion a shareholder is promising to upgrade their Nu client in a timely manner when a version is released that contains these protocol changes. Dates for release need to be determined later by the development team as quality and thoroughness need to be prioritized over timing.

  1. Permit shareholders to vote to set transaction fees. Default transaction fees equal to the current transaction fees should be applied if there is no transaction fee vote for a particular currency in the majority of share days for the voting period of 2000 blocks. The share day weighted median vote will be the fee. The vote will consist of an 8 bit currency/share code and an uint32 expressing the fee in satoshis.

  2. Change the maximum interest rate rise from 1% per 1440 blocks to a per block rise of 0.002%. Enforce a maximum per block interest rate decrease of 0.004%.

  3. Remove the proof of stake difficulty floor of 0.000244414. The floor is inconsistent with the protocol specification and represents a bug, not a design change.

  4. Currently only one motion can be voted for per block. Change this to allow as many motion votes within a single block as the user specifies. The only limit will be the 1000 byte maximum size on the coinstake transaction already imposed by the protocol.

  5. Currently parking rate are determined based on the rates published for the block that contains a parking transaction. Instead, use the previous block’s parking rates when paying parking premiums.
    End motion

Reasons for above protocol changes

Vote to set transaction fees
Transaction fees are set quite low in Nu at 0.01 NBT per kB. This may not be the optimal fee to encourage optimal use of scarce network resources. More importantly, the optimal fee is likely to change over time.

Shareholders will be able to choose a more appropriate rate in the future, having information not yet available today, than anyone could choose today. This is in keeping with the model of trusting shareholders to configure the way the system works to adapt to changes. Data feeds would also provide transaction fee votes in the near future. Note that this also permits shareholders to reduce the fee below the default.

Maximum interest rate changes
At times interest rates have sihfted from 4% to 5% to 4% to 5% again all in space of minutes. There are a number of advantage to smoothly changing Interest rates. The solution is to set a maximum interest rate increase of 0.002% and a maximum interest rate decrease of 0.004% for each block. This way any change in rate would be very minor. This per block rate equates to 3% total increase per day and 6% total decrease per day, giving shareholders the ability to change rates more quickly than is currently possible with the 1% per day limit.

Proof of stake difficulty floor
The difficulty level regulates the number of blocks produced to an average of one per minute. The code contains a flaw that ties proof of stake difficulty to proof of work difficulty. This code did not cause a problem in Peercoin because it actually uses proof of work, whereas Nu does not use proof of work at all. The result of this bug is that proof of stake difficulty cannot drop below 0.0024414. This means that if few shareholders are minting, block intervals will drop below one per minute. This stretches out parking intervals and slows down voting. There is no advantage to having the difficulty floor.

Multiple motion votes
A goal of Nu is to allow shareholders to manage the network directly as much as is practical. Allowing only one motion vote severely limits the amount of input shareholders can have. Motion votes take at least several days to complete. Also, there is no definitive way to determine what motion should be actively voted on at any given time. Some may think motion A is most important right now, while other shareholders think motion B is more important. A situation may occur where both motion A and motion B enjoy support from a majority of shareholders, but neither pass because some shareholders are voting for motion A while others are prioritizing voting for motion B. Allowing shareholders to vote for both motion A and motion B will give a much clearer picture of whether there is consensus.

Which parking rates to use
When a parking transaction is signed and broadcast to the network, the park rate that applies is the block the transaction is included in. This introduces a degree of uncertainty in the part rate, because the park rate is finalized just after the parking transaction is sent. Using the park rate from the previous block allows the park rate to be correctly understood more reliably. It should be noted that there is still a chance a user won’t receive the exact park rate they expect due to blockchain reorganizations, the transaction not being included in the next block among other unlikely scenarios. With the maximum interest rate changes being implemented, in the rare circumstance where the park rate is different from what the user anticipates, it will be a very small difference.

Thanks @JordanLee for presenting this great package to us all.

I think all 5 changes are valuable and an improvement over and above the current situation.
Especially the ability to adjust park rates faster is very important in my opinion.

The ability to change transaction fees is another tool which can be used in controlling the money supply. It will take some time to work out how fees, interest rates and custodial grants work together in responding to events on the network. Interesting times ahead.

Don’t want to underestimate the other items, but they feel more like fixes.
Can I assume that all proposed changes are funded by the custodial grant for core development you received earlier?

Anyway, I would definitely support this motion without hesitation.

I agree with Cybnate. Most of these changes seem like no-brainers, giving shareholders more flexibility, which I could only see as a bad thing if a malevolent entity gained control of the network.

Hey Jordan… thank you for the great input your provide. The changes seem very reasonable and like the others said a no brainer.

I’d like to bring your attention to a proposal I made that addresses the infinate supply issue that has been raised and talked about it. I’m not sure how to bring about a motion and I doubt that such a big proposal would be added to your motion as it will likely have it’s own motion after being thoroughly discussed on the forums first. Feel free to create a motion about it or you can teach me how to creat a motion :stuck_out_tongue:

The proposal link :

The transaction fee must be known by the client when it generates the transaction. If the fees happen to increase in the next block then the transaction becomes invalid and cannot be included in the block. It will never be confirmed (unless the fees decrease and a minter kept the invalid-at-that-time transaction).

Some kind of delay could solve the problem (for example the change would only be effective 24h after the vote). But then I’m not sure how the client should handle the fee near the switch time. If this is the direction we’re taking, these details should probably be included in the motion.

I support this motion.

That’s a very good point Mike. This idea needs to be hashed out a bit more it seems.

I will be supporting this motion.

However, I am worried about timing

please consider that not everybody looks at the forum all the time, and the likelyhood that everybody will look at the forum/website when the new client will be released is pretty low.

I advocate for a solutions where shareholders are timely informed on required changes. Either an important rss feed/mailing list that the shareholders can register to, or the infamous client Alerts.

This will also improve communication about interest rates, new motions, new grants. The forum is started to gain volume and I don’t think everybody will be able to keep up.

How to keep it decentralised, that’s another story. However I wouldn’t worry now about having a centralized mailing list or alert system, after all, shareholders seems to be already comfortable with some centralisation (funds).

You raise an interesting point. I’m concerned about the effects on time locked transactions. I will admit I’m not too familiar with how they work. Will a change of the transaction fee invalidate time gated transactions?

I support these changes too. It looks like they will enhance the user experience, as well as improve the ability of shareholders to maintain the 1 USD price of NBT in times of demand adjustments.

My thoughts:

  1. I support this new feature for shareholder-set transaction fees, specifiable per sub-currency. Great idea.
  2. I would support allowing even faster movements, up to 8% change every 24 hours (or the equivalent per-block rate). Because a median value is used, I don’t expect a single shareholder to be able to maliciously abuse this ability.
  3. Good bug fix. I support this.
  4. Another bug fix / obvious feature. I support this.
  5. This could be considered a bug fix. I support this.

Looks good. Thank you, Jordan, for posting this! I look forward to the final version of the motion.