Nu 2.0 release now on test net

[sigmike]

is there a way to know the aggregated sum per custodian?

The RPC getliquidityinfo returns the aggregated sum per custodian in the custodian section.

[sigmike]

Does it imply that the the unconfirmed NSRs (minted and non minted) will not be recovered?

On CoinStake transactions only the reward will not be recovered. The output that generated it will be free again to be spent or to mint.

About normal transactions, I think the client will allow you to spend the outputs you used in the unconfirmed transaction but I’m not sure.

[pennybreaker]

The liquidity info only expires when the custodian is not allowed to send liquidity info anymore (about 6 months after the grant). A timeout was never included in the design, although it seems to have been expected already. Right now it’s the resposibility of the custodian to reset its identifiers by setting them to zero.

The client will still list identifiers with 0 value, but it’s an easy client-side fix if we want to remove them.

The getliquiditydetails RPC was designed to be parsed by programs, as opposed to the human readable getliquidityinfo.

Adding a timeout is also client side only, but it’s better for the network if every node behaves the same way.

Also note that custodians are limited to 100 liquidity identifiers.

Thank you for the explanation. Personally, I believe that 6 months is too long to wait if some custodian is sending bogus liquidity info, but I’m fine with addressing this if/when it becomes a problem since it’s currently working as designed.

All issues have been tested and validated to be functioning correctly. Unless others have issues/concerns/questions, we should decide on a protocol switch time for the production network, create the final v2.0 binaries and begin the upgrade.

[JordanLee]

All issues have been tested and validated to be functioning correctly. Unless others have issues/concerns/questions, we should decide on a protocol switch time for the production network, create the final v2.0 binaries and begin the upgrade.

I’m very happy to hear this. I have asked pennybreaker for some information about the testing that has been done. Once that is clarified I will either request additional testing or schedule the production release.

[pennybreaker]

Issue #184: Handle future vote versions properly - This was tested on a private network where I was able to carefully control the percentage of nodes minting on v2.0 and nodes minting on the previous version. This was started at an approximate 80%/20% mix of v2.0 nodes and v1.1 nodes and slowly adjusted to a 90%/10% mix until a successful protocol switch was observed. Once the switch took place, the remaining v1.1 nodes were upgraded and observed to join the main v2.0 chain. At this point, I upgraded my testnet nodes to v2.0 and the network successfully switched to v2.0.

Issue #134: Change maximum interest rate increase/decrease - As discussed in one of my previous posts, interest rates were raised and lowered and observed to change at the correct percentage on a per block basis. The per block change was observed in the GUI as well as by using the ‘getparkrates’ RPC.

Issue #154: Propagate the liquidity identifier through the network
enhancement - Elected custodians submitted liquidity info on the testnet using tier identifiers and the liquidity info was observed to correctly propagate, by tier, to other nodes on the network. This can be seen, listed by tier, in the GUI, or listed by custodian using the ‘getliquiditydetials’ RPC. NSR custodians were verified to not be able to submit liquidity.

Issue #165: Dynamic fee - Adjusted fees for NSR and NBT were voted for and passed. Transactions were processed to verify that the correct fee was applied. Large and small NSR transactions were processed to verify that the per kb fee was correctly applied.

Issue #167: Make park rates effective 60 blocks after the actual vote - As discussed in a previous post, interest rates were raised and lowered. The block in which rates began to change was identified and then park rates were verified to begin changing on the 60th block from that point. The change was identified in the GUI as well as by using the ‘getparkrates’ RPC.

Issue #180: Permit NuShare custodians and burning transactions - NSR custodians were successfully elected and the correct amount of NSR was granted. NSR was then successfully burned using the ‘brun’ RPC.

[cryptog]

All issues have been tested and validated to be functioning correctly.

So I guess I can stop now minting on the test net.

[JordanLee]

I am comfortable moving forward with final builds for the production release of 2.0 with the testing that has been completed. It is possible to do a much more thorough job of testing, but given our current market cap and funding levels I believe the minimal level of testing we have completed makes the most sense.

We are in the process of negotiating a switch date. We want core team members to be available to monitor the protocol change, so we are coordinating availability. I hope to pick a date and post builds to nubits.com very soon.

[JordanLee]

The Nu 2.0 protocol switch date will be August 25th 14:00 UTC. Builds for Nu 2.0 will be available shortly.