Nu 2.0 release now on test net

cryptog 2015-07-20 07:49:23 UTC #50

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

pennybreaker 2015-07-20 20:10:27 UTC #51

Ok, I see that a per block rate increase/decrease is taking place …

getparkrates 399634 B

{
“1 blocks” : 0.00000006,
“2 blocks” : 0.00000011,
“4 blocks” : 0.00000023,
“8 blocks” : 0.00000046,
“32 blocks” : 0.00000205,
“64 blocks” : 0.00000409,
“128 blocks” : 0.00000818,
“256 blocks” : 0.00001659,
“512 blocks” : 0.0000334,
“1024 blocks” : 0.00006681,

getparkrates 399635 B

{
“1 blocks” : 0.00000006,
“2 blocks” : 0.00000011,
“4 blocks” : 0.00000023,
“8 blocks” : 0.00000046,
“32 blocks” : 0.00000205,
“64 blocks” : 0.00000409,
“128 blocks” : 0.00000819,
“256 blocks” : 0.0000166,
“512 blocks” : 0.00003342,
“1024 blocks” : 0.00006685,

… but the percentage change per block is difficult to measure due to the small size of the numbers I changed. For example, we will not be able to see a per block change in a rate of 0.00000006 (1 block). Because of this, I have made another adjustment to the data feed, as follows …

Durations of 1 block through 8192 blocks are set to zero, so we should see these decreasing by a maximum of 0.004% per block.

Durations of 16384 blocks through 33554432 blocks have been doubled from what they were, so we should see these increasing by a maximum of 0.002% per block.

mhps 2015-07-21 00:35:12 UTC #52

I don’t have a clue what you are talking about. Do you find a problem? Did you make a change to limit interest increase rate?

cryptog 2015-07-21 10:04:50 UTC #53

Feed set here.

pennybreaker 2015-07-21 14:01:41 UTC #54

Change maximum interest rate increase/decrease – This
enhancement changes the maximum interest rate rise from 1% per 1440
blocks to a per block rise of 0.002% and enforces a maximum per block
interest rate decrease of 0.004%.

Issue #134: Change maximum interest rate increase/decrease

pennybreaker 2015-07-23 02:33:46 UTC #55

@sigmike I believe we have a bug. Park rate durations 1 minute through 8 minutes have not changed in well over 3000 blocks, despite 100% of the vote being set to zero.

getparkrates 403862 B
{
“1 blocks” : 0.00000006,
“2 blocks” : 0.00000011,
“4 blocks” : 0.00000023,
“8 blocks” : 0.00000046,
“16384 blocks” : 0.00186904,
“32768 blocks” : 0.00373808,
“65536 blocks” : 0.00747616,
“131072 blocks” : 0.01495232,

getparkrates 400862 B

{
“1 blocks” : 0.00000006,
“2 blocks” : 0.00000011,
“4 blocks” : 0.00000023,
“8 blocks” : 0.00000046,
“32 blocks” : 0.00000267,
“64 blocks” : 0.00000532,
“128 blocks” : 0.00001044,
“256 blocks” : 0.0000218,
“512 blocks” : 0.00004436,

sigmike 2015-07-23 15:25:23 UTC #56

Indeed, the new increase limit combined with the current encoding of rates do not permit the increase of rates below 32 blocks. I considered it was not a problem since parking for less then 30 minutes doesn’t make a lot of sense. And Jordan didn’t object. I mentioned it there: https://bitbucket.org/JordanLeePeershares/nubit/pull-request/221/park-rate-change-limitations-are-per-block/diff#comment-7349377

We can still fix it if needed, but it requires a protocol change to update the encoding.

JordanLee 2015-07-23 15:55:54 UTC #57

My perspective on this is that restrictions on the parking intervals are undesirable, but recoding it isn’t a priority. It adds a small degree of additional complexity to the protocol, which can have security implications. However, I think the risk in this case is quite small.

pennybreaker 2015-07-24 05:04:39 UTC #58

@sigmike The new liquidity identifier is working. Is there any way to remove the identifier once it has been created? Is there any type of time out period that will clear the records if not refreshed by the custodian? It seems that there should be. This liquidity info could get quite cluttered, if not. What happens if a custodian goes offline and never resets to zero?

getliquiditydetails B

{
“bDLGTux8AkAHiZitKvneCKXrmeeCKz4GQY” : {
"" : {
“buy” : 555555.0,
“sell” : 555555.0
},
“1” : {
“buy” : 123.0,
“sell” : 456.0
},
“2” : {
“buy” : 789.0,
“sell” : 987.0
},
“3” : {
“buy” : 9999.0,
“sell” : 9999.0
},
“4” : {
“buy” : 9999.0,
“sell” : 9999.0
},
“5” : {
“buy” : 0.0,
“sell” : 0.0
},
“999” : {
“buy” : 99999.0,
“sell” : 99999.0
},
“hereforever?” : {
“buy” : 99999.0,
“sell” : 99999.0
}
},
“bL5AmRyuCtABdFxBimffSJgaWXUo82254e” : {
"" : {
“buy” : 10020040.08,
“sell” : 9651.2376
}
},
“bSBh4Kag9f1kSdsLhVRnnd1TuDwBMs4yPq” : {
"" : {
“buy” : 1.94,
“sell” : 0.0
}
}
}

pennybreaker 2015-07-24 20:44:39 UTC #59

I can confirm that the rate increase/decrease per block is working as expected. This can be seen in the gui, as well as by RPC. I can also confirm that the rates are taking effect 60 blocks after the vote. Here is an example with rates decreasing …

Block 406713 was the first block to have >50% of the vote to decrease rates over the last 2000 blocks:

getparkvotes 406713 2000

},
“19” : {
“blocks” : 524288,
“estimated_duration” : “1.0 years”,
“votes” : [
{
“rate” : 0.0,
“annual_percentage” : 0.0,
“sharedays” : 961.94982639,
“shareday_percentage” : 50.00903397,
“accumulated_percentage” : 50.00903397
},
{
“rate” : 0.05980926,
“annual_percentage” : 5.99999969,
“sharedays” : 961.60228009,
“shareday_percentage” : 49.99096603,
“accumulated_percentage” : 100.0
}
]

Rates for the same block:

getparkrates 406713 B

{
“16384 blocks” : 0.00186904,
“32768 blocks” : 0.00373808,
“65536 blocks” : 0.00747616,
“131072 blocks” : 0.01495232,
“262144 blocks” : 0.02990463,
“524288 blocks” : 0.05980926,
“1048576 blocks” : 0.11961853,
“2097152 blocks” : 0.23923705,
“4194304 blocks” : 0.4784741,
“8388608 blocks” : 0.95694821,
“16777216 blocks” : 1.91389642,
“33554432 blocks” : 3.82779284
}

Rates, 59 blocks later have not changed:

getparkrates 406772 B

Rates of the 60th block show first decrease after vote:

getparkrates 406773 B

{
“16384 blocks” : 0.00186779,
“32768 blocks” : 0.00373559,
“65536 blocks” : 0.00747118,
“131072 blocks” : 0.01494235,
“262144 blocks” : 0.02988469,
“524288 blocks” : 0.05976939,
“1048576 blocks” : 0.11953878,
“2097152 blocks” : 0.23907756,
“4194304 blocks” : 0.47815512,
“8388608 blocks” : 0.95631024,
“16777216 blocks” : 1.91262049,
“33554432 blocks” : 3.82524098
}

desrever 2015-07-25 07:33:35 UTC #60

@pennybreaker @sigmike about liquidity identifiers : is there a way to know the aggregated sum per custodian?
or do you expect clients to aggregate it autonomously?
The empty identifier could look like an aggregated value but its not, and might be confusing.

{
"" : {
“buy” : 555555.0,
“sell” : 555555.0
}

Did I miss anything?

sigmike 2015-07-25 07:51:49 UTC #61

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.

sigmike 2015-07-25 07:53:37 UTC #62

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

sigmike 2015-07-25 07:57:52 UTC #63

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 2015-07-26 18:10:08 UTC #64

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 2015-07-27 00:02:00 UTC #65

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 2015-07-27 04:46:49 UTC #66

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 2015-07-27 06:41:25 UTC #67

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

JordanLee 2015-07-30 03:07:42 UTC #68

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 2015-07-30 21:48:54 UTC #69

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

Future Dividend Distributions