Nu 2.0 release now on test net

willy 2015-07-16 19:59:31 UTC #42

    "sfG6GpAqKpjmKhYtDsTmw3SodEFh824oqx" : {
    "1337.00" : {
        "blocks" : 9052,
        "block_percentage" : 90.52,
        "sharedays" : 1454402995,
        "shareday_percentage" : 95.98893277
    }

Is this the correct fork now ?

willy 2015-07-17 15:33:51 UTC #43

I hope this is the correct chain:

Status: 4374 Confirmations
+1337.00 NSR
a40a614ec2498c3de82b3568b78d47767f1ba33d46424ef0f1c01193cb44030e

Thank you all for voting

pennybreaker 2015-07-17 22:00:55 UTC #44

Awesome! Looks like we’re on the same chain. Just to confirm, can @willy and @cryptog post your current block height and check to see what you current tx fee is? As of 7/17/15, 18:00 EST, I have:

{
“version” : “v2.0.0-Test4-beta”,
“protocolversion” : 2000000,
“walletversion” : 1,
“walletunit” : “S”,
“balance” : 35615468.0,
“newmint” : 0.0,
“stake” : 129840.0,
“parked” : 0.0,
“blocks” : 393891,
“moneysupply” : 1015737965.0,
“connections” : 1,
“proxy” : “”,
“ip” : “”,
“difficulty” : 31.48497906,
“testnet” : true,
“keypoololdest” : 1407175948,
“keypoolsize” : 101,
“paytxfee” : 2.0,
“unlocked_until” : 0,
“errors” : “”
}

pennybreaker 2015-07-17 22:11:03 UTC #45

@willy Once you have confirmed that your block height, paytxfee, and difficulty match mine from above, could you please do the following …

Using coin control, make sure the shares from your grant are spendable by sending me a few to this address: sXp7RewTsokUTvuQc6ig9bxzm8YQV5ZR32
I’m not sure if it matters, but I’m curious to see if you are able to submit liquidity info using your NSR grant … let me know if you need help with this.
burn a portion of your grant using the burn RPC and post the transaction info using the gettransaction RPC

Thanks!

willy 2015-07-18 00:45:31 UTC #46

-Transaction made, 379.00 NSR

-liquidityinfo S 100 100 sfG6GpAqKpjmKhYtDsTmw3SodEFh824oqx
02:44:48 Invalid currency (code -3)

-100 NSR burned, 151a60d73daa66bd4eb8adcf2065486aabbd31f02ef0875aedfb49a8dfe568b7

{
“amount” : 0.0,
“fee” : -100.0,
“confirmations” : 2,
“blockhash” : “aca4dde256c1817d01cde3350dcf611fd0f1f036936bca64583b98dd12f21397”,
“blockindex” : 2,
“txid” : “151a60d73daa66bd4eb8adcf2065486aabbd31f02ef0875aedfb49a8dfe568b7”,
“time” : 1437180171,
“comment” : “hi”,
“from” : “”,
“message” : “”,
“to” : “”,
“details” : [
]
}

Edit: I’m not sure the burn command used the inputs from the grant… will look into this deeper tomorrow.

cryptog 2015-07-18 03:22:10 UTC #47

sorry for the delay.
here you are:

“version” : “v2.0.0-Test4-beta”,
“protocolversion” : 2000000,
“walletversion” : 1,
“walletunit” : “S”,
“balance” : 14985520.0,
“newmint” : 0.0,
“stake” : 40200.0,
“parked” : 0.0,
“blocks” : 394349,
“moneysupply” : 1015756083.0,
“connections” : 1,
“proxy” : “”,
“ip” : XXX",
“difficulty” : 32.49327453,
“testnet” : true,
“keypoololdest” : 1435942894,
“keypoolsize” : 101,
“paytxfee” : 2.0,
“errors” : “”
}

I think it matches what you ve got.

However, I am still having plenty of unconfirmed NSRs after redownloading the whole blockchain.
I am also having plenty of minted shares unconfirmed (the ones i minted before re-downloading) though I got repairwallet passed.

I also run the options (-rescan and -salvagewallet) at startup just in case but the issue is not fixed yet.

Any ideas? (cc @sigmike)

sigmike 2015-07-18 06:48:35 UTC #48

repairwallet should make available again the outputs used in blocks you found but are no longer in the main chain.

But it won’t delete the transactions from your wallet. Unfortunately there’s no way in the client right now to remove these useless transactions. Bitcoin has a -zapwallettxes option to clear them up but we haven’t imported that yet. It should be quite easy to do though.

pennybreaker 2015-07-20 05:11:30 UTC #49

@cryptog and @willy Could you guys please set your testnet data feeds to the following:

nud setdatafeed 'https://raw.githubusercontent.com/sigmike/nu-testnet-datafeed/master/vote.json'

It includes a NuBits and a NuShares custodian vote that I plan to use to look into issue #154 (Propagate the liquidity identifier enhancement), park rates for period 1 minute through 16 minute decreased to zero to measure the new rate decrease changes in issue #134, and park rates for periods 32 minutes through 17.1 hours doubled to measure the rate increase changes in issue #134. These rate changes should also suffice for verifying issue #167 (Make park rates effective 60 blocks after the actual vote).

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.