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.

The RIPEMD-160 hash of the motion that you need to enter into your client to vote for this motion is:
7283C71D2BDDC3B71E2EB7CD0693E28E3665BF66

When verifying the hash of the motion start with the letter “T” and end with a period as the last character.

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.

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.

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%.

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.

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.

Currently parking rate are determined based on the rates published for the block that contains a parking transaction. Instead, use the rate from 60 blocks in the past. This will permit the parking rates to be known 60 blocks into the future. Transaction fees should also be set using the fee from 60 blocks in the past. Though not a protocol change, the client should use the highest fee to be charged in the next 10 blocks.

Permit a custodial grant to have zero as the quantity of currency.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 60 blocks in the past 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.

This will permit the parking rates to be known 60 blocks into the future.

This has an interesting side-effect: a user who sees a rising park rate in the future should always wait for the blocks to pass before parking. Do the advantage(s) of looking back 60 blocks instead of 1 block in the past outweigh this anomaly?