V12 Testing Thread

Please read my long winded post above. And we need to test to be sure that we can NOT exceed the designated reward amount (The chart flare posted, is that old? I thought we were going 50-40-10?) Thanks :)

BTW, we can test this by simply making payment proposals fit within the constraints. We need to be sure there is a stop gap. Not that I would mind if more coins were created, but we'd ruin the trust the community has in us.

10 X a day = 576/10 = 57.6 payments at ~ 23 coins each *10% means we can't currently exceed 132 coins per payment.

So if someone makes a proposal that would pay more than that, it should be rejected. And if we make a bunch of proposals, around 10 or 15 coins per payout, then we can see if the system will reject any proposal that tips over the 132 coins mark!
 
Last edited by a moderator:
 
UdjinM6 said:
flare TanteStefana
In code:
1) https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L25-L31
2) https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L722-L737
3) https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L603-L659 (https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L628 and https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L641-L650 specifically)
4) and finally https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L1576-L1605 (https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L1586-L1587 specifically)
Click to expand...
Got the memo :)

But why did https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L1587 still allow testnet to create a valid proposal >10% - even if the number of superblocks are increased by https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L30 ?

Seems like some code is assuming that the superblock cycle "will be ok" :)
 
flare said:
Got the memo :)

But why did https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L1587 still allow testnet to create a valid proposal >10% - even if the number of superblocks are increased by https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L30 ?

Seems like some code is assuming that the superblock cycle "will be ok" :)
Click to expand...
Not sure if I get your question right..

You linked to finalized budget check, every single proposal is checked in another place https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L1123-L1127
Not a big deal, that code is complicated and I needed few reads through first too :)

And if you just wondering why sum of totals are more then 10% of normal monthly reward - on testnet we pretend that we have 50 blocks per month to hit budget payments more often and with that in mind - 3K is less then 10% of "monthly" reward.
 
UdjinM6, Thank you for clarifying (with flare's interpretation) I don't understand the code, but I get it now how the payouts are getting distorted. it would still be better IMO if we simply reduced the size of payments to match so we could all tell if it's working properly.

Second question if you'd be so kind to tell me, if we don't use the entire 10% allotted at the end of the month, are all those extra coins forever lost? I think that's a bad idea. Perhaps if the "leftovers" could be given to the foundation, and maybe the foundation could maintain a fountain at the very least. We need to distribute coins as much as possible, IMO :)

update:
It seems that if all the coins available are not spent at the end of the month, they are gone forever. That's what I just got, if I understood correctly, from Evan.


Thanks for insight :)
 
Last edited by a moderator:
UdjinM6 said:
Not sure if I get your question right..

You linked to finalized budget check, every single proposal is checked in another place https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L1123-L1127
Not a big deal, that code is complicated and I needed few reads through first too :)

And if you just wondering why sum of totals are more then 10% of normal monthly reward - on testnet we pretend that we have 50 blocks per month to hit budget payments more often and with that in mind - 3K is less then 10% of "monthly" reward.
Click to expand...
Like i wrote on slack: My only concern/point is that currently testnet does not follow

Code: 
blockreward = 2222222/(((Difficulty+2600)/9)^2)

anymore. If you increase the number of superblocks/time you also need to reduce the budget generation. The way it is currently we are not able to even test the emmision curve on testnet and flaws will only show on mainnet - which is way to late.
 
flare said:
Like i wrote on slack: My only concern/point is that currently testnet does not follow

Code: 
blockreward = 2222222/(((Difficulty+2600)/9)^2)

anymore. If you increase the number of superblocks/time you also need to reduce the budget generation. The way it is currently we are not able to even test the emmision curve on testnet and flaws will only show on mainnet.
Click to expand...
You mean we need to reduce the mining reward? I think that's how it's going to be on mainnet but the masternode reward is still going to be the same except masternodes will never get the 60% as planned before, right?
 
TanteStefana said:
Second question if you'd be so kind to tell me, if we don't use the entire 10% allotted at the end of the month, are all those extra coins forever lost? I think that's a bad idea. Perhaps if the "leftovers" could be given to the foundation, and maybe the foundation could maintain a fountain at the very least. We need to distribute coins as much as possible, IMO :)

Thanks for insight :)
Click to expand...

I not sure how you missed it, but that debate raged on for weeks on end about 2 months ago or so. A brief summary is below...


...
The problem is, who gets to decide where the coins go and why?

In the end mn owners didn't want to be forced to send the coins originally earmarked for them to anybody that didn't get their approval via voting (that includes the foundation) and they also didn't want the coins accumulating in some address as that would need to be protected from hackers (not to mention that you would need to pick someone to hold those coins).

Some mn owners thought that unused coins should to go back to them because they were originally supposed to get 60%. Others were concerned that if unused budget money went back to the mn owners then they would be incentived not to vote for any proposals.

Finally, Evan suggested that coins not needed to fund the proposals would simply not be generated. People agreed on this idea and it was put to a mn vote. And it passed...
 
Last edited by a moderator:
moli said:
You mean we need to reduce the mining reward? I think that's how it's going to be on mainnet but the masternode reward is still going to be the same except masternodes will never get the 60% as planned before, right?
Click to expand...
I am not talking about reducing the mining reward, i am talking about fixing the payment schedule. This is what we agreed on:

upload_2015-7-28_11-56-39.png



This should be the same for testnet and mainnet, regardless how many superblocks are generated (for testing purposes) - otherwise testnet differs from mainnet and the tests are not valid.

Currently we are seeing

Normal block

40% miner reward
60% masternode reward

Or if we account 10% as "escrowed budget"

36% miner reward
54% masternode reward

e.g. http://test.explorer.darkcoin.qa/bl...c45d18d27ee7d7185dbcef068450bc11fb1ebb4f5181c

upload_2015-7-28_12-5-16.png


Superblock (each 50 blocks)

http://test.explorer.darkcoin.qa/bl...ce7979abbd0dbfcf87e846a55aebd3c1df40e4f23c545

100% miner reward
270% bugdet payout

upload_2015-7-28_12-11-35.png


which is broken: Where is the masternode reward in this block? Why have 49x 23.2 + 3164 = 4300 tDASH been mined in the last 50 blocks, when it should have been 50x 23.2 = 1160 tDASH?

Additionally there seems to be a flaw in the superblock generation, as we see this quite often

Block 90850 --> http://test.explorer.darkcoin.qa/bl...ce7979abbd0dbfcf87e846a55aebd3c1df40e4f23c545 --> 3141 budget payment to "evan-fund", no masternode reward
Block 90851 --> http://test.explorer.darkcoin.qa/bl...dd805fd018acb943df2a1955c874f6dd29fe63d14434b --> 500 budget payment to ""moo-feed", no masternode reward
Block 90852 --> http://test.explorer.darkcoin.qa/bl...9f9ccbcb835f669b8ecaf71a3b9b8f549d5580535cd53 --> 500 budget payment to "COOLEST_APP", no masternode reward

Three budget payouts in 3 consecutive blocks? Why are masternode rewards skipped on a superblock?


Like TanteStefana i need to stress as well: This has to work rock solid. If we mess up the emission curve by a flaw in the generation/subsidy algo it will get worse than the everlasting "instamine" accusations.
 

Attachments

  • upload_2015-7-28_11-55-47.png
    upload_2015-7-28_11-55-47.png
    27.5 KB · Views: 154
  • upload_2015-7-28_12-9-49.png
    upload_2015-7-28_12-9-49.png
    55 KB · Views: 137
flare said:
I am not talking about reducing the mining reward, i am talking about fixing the payment schedule. This is what we agreed on:

View attachment 1648


This should be the same for testnet and mainnet, regardless how many superblocks are generated (for testing purposes) - otherwise testnet differs from mainnet and the tests are not valid.

Currently we are seeing

Normal block

40% miner reward
60% masternode reward

Or if we account 10% as "escrowed budget"

36% miner reward
54% masternode reward

e.g. http://test.explorer.darkcoin.qa/bl...c45d18d27ee7d7185dbcef068450bc11fb1ebb4f5181c

View attachment 1649

Superblock (each 50 blocks)

http://test.explorer.darkcoin.qa/bl...ce7979abbd0dbfcf87e846a55aebd3c1df40e4f23c545

100% miner reward
270% bugdet payout

View attachment 1651

which is broken: Where is the masternode reward in this block? Why have 49x 23.2 + 3164 = 4300 tDASH been mined in 50 blocks, when it should have been 50x 23.2 = 1160 tDASH?

Additionally there seems to be a flaw in the superblock generation, as we see this quite often

Block 90850 --> http://test.explorer.darkcoin.qa/bl...ce7979abbd0dbfcf87e846a55aebd3c1df40e4f23c545 --> 3141 budget payment to "evan-fund"
Block 90851 --> http://test.explorer.darkcoin.qa/bl...dd805fd018acb943df2a1955c874f6dd29fe63d14434b --> 500 budget payment to ""moo-feed"
Block 90852 --> http://test.explorer.darkcoin.qa/bl...9f9ccbcb835f669b8ecaf71a3b9b8f549d5580535cd53 --> 500 budget payment to "COOLEST_APP"

Three budget payouts in 3 consecutive blocks?


Like TanteStefana i need to stress as well: This has to work rock solid. If we mess up the emission curve by a flaw in the generation algo it will get worse than the everlasting "instamine" accusations.
Click to expand...
40/60 - historical testnet rule: https://github.com/dashpay/dash/blob/v0.12.0.x/src/main.cpp#L1582
4300 vs 1160 - because it check against real month instead of faked one, I agree math there https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L736 could be linked to https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L25 instead - make a PR :wink:
"3 consecutive blocks?" - yes, that's how it's designed - it's up to 100 blocks per budget cycle (and yes, most likely testnet will blow up after we have > 50 proposals in final budget:rolleyes:)

To make it clear - I appreciate your review and I'm completely agree that we need to state clearly what model we arrived to at the end of testing:
- block generation: rules, reward schedule, reward split etc;
- vote process: describe process in simple steps, what rules are, how approval/removal works, how many %% needed at each step etc.
- smth else?
 
UdjinM6 said:
40/60 - historical testnet rule: https://github.com/dashpay/dash/blob/v0.12.0.x/src/main.cpp#L1582
Click to expand...
Please fix that to mainnet rule :grin:


UdjinM6 said:
4300 vs 1160 - because it check against real month instead of faked one, I agree math there https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L736 could be linked to https://github.com/dashpay/dash/blob/v0.12.0.x/src/masternode-budget.cpp#L25 instead - make a PR :wink:
Click to expand...

I am QA, i report bugs - i will rather not fix them :tongue:


UdjinM6 said:
"3 consecutive blocks?" - yes, that's how it's designed - it's up to 100 blocks per budget cycle (and yes, most likely testnet will blow up after we have > 50 proposals in final budget:rolleyes:)
Click to expand...
But where did the masternode payment in these blocks go?


UdjinM6 said:
To make it clear - I appreciate your review and I'm completely agree that we need to state clearly what model we arrived to at the end of testing:
- block generation: rules, reward schedule, reward split etc;
- vote process: describe process in simple steps, what rules are, how approval/removal works, how many %% needed at each step etc.
- smth else?
Click to expand...
I fully agree, and that's why I'd like to have testnet as close as possible to mainnet.

So If you ever have some spare time you could dig into the AuXPoW code of Doge/Namecoin/Viacoin so that we can start to merge mine testnet (tDash) with mainnet (Dash) so that even the hashrate is the same :wink:
 
flare said:
Please fix that to mainnet rule :grin:
Click to expand...
There is no real issue with that, you just have to keep in mind that % is different but the rule is the same. We can change it on next testnet restart though but I don't see it as a necessary one tbh.
flare said:
I am QA, i report bugs - i will rather not fix them :tongue:
Click to expand...
Oh, cmon, I know you can code :tongue:
flare said:
But where did the masternode payment in these blocks go?
Click to expand...
Nowhere, there is no reward for MN in superblocks, mn reward queue is on hold and will continue after budget has been completely paid.
flare said:
I fully agree, and that's why I'd like to have testnet as close as possible to mainnet.
So If you ever have some spare time you could dig into the AuXPoW code of Doge/Namecoin/Viacoin so that we can start to merge mine testnet (tDash) with mainnet (Dash) so that even the hashrate is the same :wink:
Click to expand...
:what: Let's see if someone will make a proposal like that once dgbb is live on mainnet :grin:
 
UdjinM6 said:
Oh, cmon, I know you can code :tongue:
Click to expand...
:tongue:


UdjinM6 said:
Nowhere, there is no reward for MN in superblocks, mn reward queue is on hold and will continue after budget has been completely paid.
Click to expand...
Ah, ok so if the payment is on hold i am fine with that - otherwise you'll have to explain to the masternode operator why the payment he has been waiting for 5 days has been skipped :cool:
 
v0.12.0.32

- Masternode testnet budgets are now non-inflationary, max budget per 50 blocks is ((nSubsidy/100)*10)*50, or 25 DASH.
- We'll need to remake all of our budgets, please don't make any budgets above 5 DASH so we can have a few working at the same time
- Budgets commands have changed slightly:

c2 mnbudget prepare one url 5 1750 xx9FwiqeRbuxBn5Sh3SNeoxmgpwQNSuMC4 10 true
{
"fee_tx" : "514a3ad0319c1130573323dd9f863f7cc43ff039dd5c88e3a27d8dba5778a0d6",
"time" : 1438097546
}

- You'll need to grab fee_tx and time, the add them to the end of submit like so:

c2 mnbudget submit one url 5 1750 xx9FwiqeRbuxBn5Sh3SNeoxmgpwQNSuMC4 10 514a3ad0319c1130573323dd9f863f7cc43ff039dd5c88e3a27d8dba5778a0d6 1438097546

- Then it should appear, but it won't qualify to make it into a budget for another 30 minutes (1 day on mainnet):

mnbudget show
{
"one" : {
"IsEstablished" : false, // this means it's not mature enough to make it into a budget yet
}
}

Linux32:
https://dashpay.atlassian.net/build...n-linux-dash-dist//dash-0.12.0-linux32.tar.gz

Linux64:
https://dashpay.atlassian.net/build...n-linux-dash-dist//dash-0.12.0-linux64.tar.gz

Mac:
https://dashpay.atlassian.net/build...n-osx-dash-dist//dash-0.12.0-osx-unsigned.dmg

Win32:
https://dashpay.atlassian.net/build...1/gitian-win-dash-dist//dash-0.12.0-win32.zip

Win64:
https://dashpay.atlassian.net/build...1/gitian-win-dash-dist//dash-0.12.0-win64.zip
 
Last edited by a moderator:
v0.12.0.32-ffaedc1
DS mixing is still broken.
DS mixing does nothing but sitting idle and session timed out, no mixing.
New fresh wallet, new downloaded blockchain.
 
I don't think anyone has their masternodes up an running yet. I'm reindexing mine and will have 3 up and running soon :)

Ok, started
 
eduffield said:
There will be no inflationary effect on mainnet, when there's 1 set of superblocks per month totally 8000 DASH or less. The effect on the coin generation will actually be deflationary. These superblocks are allowed to happen 10 times a day right now, however on mainnet they will be once per month.

There's an average of 553 blocks per day on mainnet (60*24/2.6), which means we have 16615 blocks per month. To not be inflationary, we'll reduce the block reward by 10% each block . Total monthly generation can be calculated as 553*30*5*.93 = 77143 (minimum), so 10% of that is 7714 (minimum). That means every 16615 blocks on mainnet, we'll be allowed to create a few blocks that total that much in generation. We'll eliminate 10% of the total reward, but we'll only be allowed to create the minimum reward. For example, if we average 8DASH per block and reduce the block reward by 10k DASH, we'll still only recreate up to 8k DASH. If we only have budgets approved for 3k, that will result in the other 7k DASH never being created at all, a deflationary effect.
Click to expand...

But why does the budget logic have to influence the coin supply at all? Couldn't the the difference (the 7k in your example) be distributed as mining reward for all following blocks until the next superblock is created?
 
You must log in or register to reply here.
Back
Top