"sfG6GpAqKpjmKhYtDsTmw3SodEFh824oqx" : {
"1337.00" : {
"blocks" : 9052,
"block_percentage" : 90.52,
"sharedays" : 1454402995,
"shareday_percentage" : 95.98893277
}
Is this the correct fork now ?
"sfG6GpAqKpjmKhYtDsTmw3SodEFh824oqx" : {
"1337.00" : {
"blocks" : 9052,
"block_percentage" : 90.52,
"sharedays" : 1454402995,
"shareday_percentage" : 95.98893277
}
Is this the correct fork now ?
I hope this is the correct chain:
Status: 4374 Confirmations
+1337.00 NSR
a40a614ec2498c3de82b3568b78d47767f1ba33d46424ef0f1c01193cb44030e
Thank you all for voting
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â : ââ
}
@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!
-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.
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)
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.
@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).
Does it imply that the the unconfirmed NSRs (minted and non minted) will not be recovered?
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.
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?
Feed set here.
@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,
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.
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.
@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
}
}
}
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
{
â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 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
}
@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?
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.