• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

12.1 Testnet Testing Phase Two Ignition

Status
Not open for further replies.
Now I'm reviewing the code of the Governance system in v.0.12.1 and I'm confused about one thing:
from the code it follows that a masternode can vote an indefinite amount of times for the same project proposal (there is only restriction 1 vote per hour). So we have a situation when a masternode votes (VOTE_SIGNAL_FUNDING, yes) many times. And all these votes are valid and counted. Is it correct or I misunderstood something?
 
lpsun said:
Now I'm reviewing the code of the Governance system in v.0.12.1 and I'm confused about one thing:
from the code it follows that a masternode can vote an indefinite amount of times for the same project proposal (there is only restriction 1 vote per hour). So we have a situation when a masternode votes (VOTE_SIGNAL_FUNDING, yes) many times. And all these votes are valid and counted. Is it correct or I misunderstood something?
Click to expand...
A masternode only gets one vote, only the latest counts.
 
nmarley said:
A masternode only gets one vote, only the latest counts.
Click to expand...
that doesn't come from the code... The vote is added as long as its timestamp > old_vote_timestamp + 60*60. And the old vote isn't removed. And they are both counted.
github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L537
 
lpsun said:
that doesn't come from the code... The vote is added as long as its timestamp > old_vote_timestamp + 60*60. And the old vote isn't removed. And they are both counted.
github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L537
Click to expand...
No, masternode can only update the outcome of its vote, it still one vote per masternode when you count them.
https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance-vote.h#L155-L181


EDIT: ok, I take that back, need a closer look :)

EDIT2: yep, actually looks like a bug, thanks!
 
Last edited:
UdjinM6 said:
No, masternode can only update the outcome of its vote, it still one vote per masternode when you count them.
https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance-vote.h#L155-L181
Click to expand...
Thanks for a reply! But I still don't understand
There are two maps for holding votes in governance manager: https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L553-L554
mapVotesByType[nTypeHash] = vote; - I agree that this one will rewrite the old vote (according to your link to GetTypeHash())
mapVotesByHash[nHash] = vote - but this one will not rewrite the old vote (the votes will have different hashes because of different timestamps - see GetHash()). It will successfully save it

And finally here is a code for counting votes. It doesn't iterate through the mapVotesByType, it iterates through the mapVotesByHash where all votes are saved.
https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L1092-L1115

Did I miss something?
 
lpsun said:
Thanks for a reply! But I still don't understand
There are two maps for holding votes in governance manager: https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L553-L554
mapVotesByType[nTypeHash] = vote; - I agree that this one will rewrite the old vote (according to your link to GetTypeHash())
mapVotesByHash[nHash] = vote - but this one will not rewrite the old vote (the votes will have different hashes because of different timestamps - see GetHash()). It will successfully save it

And finally here is a code for counting votes. It doesn't iterate through the mapVotesByType, it iterates through the mapVotesByHash where all votes are saved.
https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L1092-L1115

Did I miss something?
Click to expand...
Yep, I see it too now. Thanks for reporting!
 
ok, it is clear now, thanks!

Have one more question: am I understood correctly that the Governance system isn't fully implemented for now? Especially I'm interested in VoteSignals. There are 4 types of them: VOTE_SIGNAL_FUNDING, VOTE_SIGNAL_VALID, VOTE_SIGNAL_DELETE, VOTE_SIGNAL_ENDORSED. So am I right that their usage are not fully implemented yet?
For example seems like the project proposal would be funded even if there are more than 10% of (VOTE_SIGNAL_VALID, no) votes.
 
One more question, now regarding voting procedure: from this code it follows that the votes which are older than 1 hour (according to timestamps) are invalid
https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance-vote.cpp#L267

But what about synchronization of votes? How this code would work? https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L466-L473
Seems like all votes which are received after sync procedure would be invalid (if their timestamps are far from current time)
 
lpsun said:
One more question, now regarding voting procedure: from this code it follows that the votes which are older than 1 hour (according to timestamps) are invalid
https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance-vote.cpp#L267

But what about synchronization of votes? How this code would work? https://github.com/dashpay/dash/blob/v0.12.1.x/src/governance.cpp#L466-L473
Seems like all votes which are received after sync procedure would be invalid (if their timestamps are far from current time)
Click to expand...

GetTime() + (60*60) is an hour into the future. Then it checks if the vote's timestamp is higher than that e.g. over an hour into the future. It's those which are invalid, not votes older than an hour. That would be the opposite direction.

Vote syncing is something that's still being worked on, which we've had to hold off on due to some other things coming up.

The next release still has a few TO-DOs before it will be ready.
 
nmarley said:
GetTime() + (60*60) is an hour into the future. Then it checks if the vote's timestamp is higher than that e.g. over an hour into the future. It's those which are invalid, not votes older than an hour. That would be the opposite direction.

Vote syncing is something that's still being worked on, which we've had to hold off on due to some other things coming up.

The next release still has a few TO-DOs before it will be ready.
Click to expand...
ok, thanks, I see it now

But have another question: how the superblock can be validated (in terms of checking the correct value of coinbase transaction)?
I had a quick look through the code and it seems to me that the node can verify the superblock only if it has a corresponding finalized budget in the internal database.
So am I right that the full history of finalized budgets (and votes for these budgets) should be saved all the time?
 
crowning said:
Mixing doesn't work right now, I guess testnet needs to stabilize first. Too much non-compliant Masternodes at the moment.
Click to expand...
Tested mixing, no go, waited one hour.

Clipboard01.png Clipboard02.png

Code: 
2016-10-16 09:09:38 CDarksendPool::SetState -- nState: 3, nStateNew: 1
2016-10-16 09:09:38 CDarksendPool::SetState -- nState: 1, nStateNew: 7
2016-10-16 09:09:38 receive version message: /Dash Core:0.12.1/: version 70202, blocks=86660, us=188.67.68.32:8590, peer=267
2016-10-16 09:09:38 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend request incomplete: Last PrivateSend was too recent. Will retry...
2016-10-16 09:09:43 CMasternodeMan::CheckAndRemove
2016-10-16 09:09:43 Closing Masternode connection 108.61.192.47:19999
2016-10-16 09:09:43 Closing Masternode connection 163.172.170.94:19999
2016-10-16 09:09:43 Closing Masternode connection 37.59.168.129:19999
2016-10-16 09:09:43 Closing Masternode connection 104.128.228.246:19999
2016-10-16 09:09:43 Closing Masternode connection 104.238.215.6:19999
2016-10-16 09:09:43 Closing Masternode connection 103.58.149.157:19999
2016-10-16 09:09:43 Closing Masternode connection 84.200.53.39:19999
2016-10-16 09:09:43 Closing Masternode connection 84.200.53.56:19999
2016-10-16 09:09:43 Closing Masternode connection 84.200.53.76:19999
2016-10-16 09:09:43 Closing Masternode connection 104.128.228.248:19999
2016-10-16 09:09:43 Closing Masternode connection 45.48.185.55:19999
2016-10-16 09:09:43 CMasternodePayments::CheckAndRemove -- Votes: 746, Blocks: 95
2016-10-16 09:09:48 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend is idle.
2016-10-16 09:09:51 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(c13d55ed69ada97eb9ae89bcf1db7bbee52d616d5a620750250d2c25f1770647, 1), scriptSig=)
2016-10-16 09:09:53 CDarksendPool::SetState -- nState: 1, nStateNew: 3
2016-10-16 09:09:53 CMasternodeMan::FindRandomNotInVec -- 67 enabled masternodes, 19 masternodes aren't yet exluded
2016-10-16 09:09:53 CDarksendPool::DoAutomaticDenominating -- attempt 0 connection to Masternode 108.61.192.47:19999
2016-10-16 09:09:53 CDarksendPool::DoAutomaticDenominating -- can't connect CTxIn(COutPoint(1c6efb4440c7a372000bd2427202cff2ed3c370f963f553e025e35f911c7b6d6, 1), scriptSig=)
2016-10-16 09:09:53 CMasternodeMan::FindRandomNotInVec -- 67 enabled masternodes, 18 masternodes aren't yet exluded
2016-10-16 09:09:53 CDarksendPool::DoAutomaticDenominating -- attempt 1 connection to Masternode 108.61.192.47:19999
2016-10-16 09:09:53 CDarksendPool::DoAutomaticDenominating -- can't connect CTxIn(COutPoint(bee3427fb5ae51e69dfff0be849e6635306a4b033874e4d0b24ec58883c70b78, 0), scriptSig=)
2016-10-16 09:09:53 CMasternodeMan::FindRandomNotInVec -- 67 enabled masternodes, 17 masternodes aren't yet exluded
2016-10-16 09:09:53 CDarksendPool::DoAutomaticDenominating -- attempt 2 connection to Masternode 103.58.149.157:19999
2016-10-16 09:09:53 OverviewPage::privateSendStatus -- Last PrivateSend message: Masternode: Last PrivateSend was too recent.
2016-10-16 09:09:54 receive version message: /Dash Core:0.12.1/: version 70202, blocks=86660, us=188.67.68.32:8591, peer=268
2016-10-16 09:09:54 CDarksendPool::DoAutomaticDenominating -- can't connect CTxIn(COutPoint(e162036e7ff36ee4c4217be3912a9449d4346c9d5bb80f7cf7a5304ad70493ed, 1), scriptSig=)
2016-10-16 09:09:54 CMasternodeMan::FindRandomNotInVec -- 67 enabled masternodes, 16 masternodes aren't yet exluded
2016-10-16 09:09:54 CDarksendPool::DoAutomaticDenominating -- attempt 3 connection to Masternode 108.61.192.47:19999
2016-10-16 09:09:54 CDarksendPool::DoAutomaticDenominating -- connected CTxIn(COutPoint(110aa2d2a93396cb8d13f26a0e082aae27a07d689491653c3e0e3bc84e37c418, 0), scriptSig=)
2016-10-16 09:09:54 CDarksendPool::DoAutomaticDenominating -- connected, sending DSACCEPT, nSessionDenom: 2
2016-10-16 09:09:54 CDarksendPool::SetState -- nState: 3, nStateNew: 1
2016-10-16 09:09:54 CDarksendPool::SetState -- nState: 1, nStateNew: 7
2016-10-16 09:09:54 receive version message: /Dash Core:0.12.1()/: version 70202, blocks=86660, us=188.67.68.32:8592, peer=269
2016-10-16 09:09:54 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend request incomplete: Last PrivateSend was too recent. Will retry...
2016-10-16 09:10:05 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend is idle.
2016-10-16 09:10:08 CDarksendPool::SetState -- nState: 1, nStateNew: 3
2016-10-16 09:10:08 CMasternodeMan::FindRandomNotInVec -- 67 enabled masternodes, 15 masternodes aren't yet exluded
2016-10-16 09:10:08 CDarksendPool::DoAutomaticDenominating -- attempt 0 connection to Masternode 178.62.6.122:19999
2016-10-16 09:10:09 OverviewPage::privateSendStatus -- Last PrivateSend message: Masternode: Last PrivateSend was too recent.
2016-10-16 09:10:13 CDarksendPool::DoAutomaticDenominating -- can't connect CTxIn(COutPoint(505aab5909382e3250c89bc8874843e428b8813f1f16ba971391e2355609c6e3, 0), scriptSig=)
2016-10-16 09:10:13 CMasternodeMan::FindRandomNotInVec -- 67 enabled masternodes, 14 masternodes aren't yet exluded
2016-10-16 09:10:13 CDarksendPool::DoAutomaticDenominating -- attempt 1 connection to Masternode 108.61.192.47:19999
2016-10-16 09:10:13 CDarksendPool::DoAutomaticDenominating -- connected CTxIn(COutPoint(ad1480fb9d223192e47f491213281def584a5bfafdc8613bce3a6f0d2ec6514a, 1), scriptSig=)
2016-10-16 09:10:13 CDarksendPool::DoAutomaticDenominating -- connected, sending DSACCEPT, nSessionDenom: 8
2016-10-16 09:10:14 CDarksendPool::SetState -- nState: 3, nStateNew: 1
2016-10-16 09:10:14 CDarksendPool::SetState -- nState: 1, nStateNew: 7
2016-10-16 09:10:14 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend request incomplete: Last PrivateSend was too recent. Will retry...
 
xdashguy said:
Why is this testing thread so dead?
Click to expand...
Someone spawned a bunch of fake masternodes on testnet so instead of testing new things we had to deal with that and implement new protection (mostly for testnet because collateral worth literally $0 there unlike mainnet so mainnet is pretty much immune to that already). Once it's done we'll relaunch testing again.
 
UdjinM6 said:
Someone spawned a bunch of fake masternodes on testnet so instead of testing new things we had to deal with that and implement new protection (mostly for testnet because collateral worth literally $0 there unlike mainnet so mainnet is pretty much immune to that already). Once it's done we'll relaunch testing again.
Click to expand...

can you please answer on this question:
how the superblock can be validated (in terms of checking the correct value of coinbase transaction)?
I had a quick look through the code and it seems to me that the node can verify the superblock only if it has a corresponding finalized budget in the internal database.
So am I right that the full history of finalized budgets (and votes for these budgets) should be saved all the time?
 
lpsun said:
can you please answer on this question:
how the superblock can be validated (in terms of checking the correct value of coinbase transaction)?
I had a quick look through the code and it seems to me that the node can verify the superblock only if it has a corresponding finalized budget in the internal database.
So am I right that the full history of finalized budgets (and votes for these budgets) should be saved all the time?
Click to expand...
Yes, that's basically the same trust model as for regular masternode payments - it relies on the fact that there are a lot of nodes online at any given moment which validate this correctly while your node is offline. So when your node starts it assumes that network has validated such blocks already and only verifies that upper limit of such blocks doesn't exceed the max value allowed by the protocol, i.e. total subsidy wasn't bumped above max. Once it's synced, it starts to fully validate such blocks just like any other online node does.
 
UdjinM6 said:
Yes, that's basically the same trust model as for regular masternode payments - it relies on the fact that there are a lot of nodes online at any given moment which validate this correctly while your node is offline. So when your node starts it assumes that network has validated such blocks already and only verifies that upper limit of such blocks doesn't exceed the max value allowed by the protocol, i.e. total subsidy wasn't bumped above max. Once it's synced, it starts to fully validate such blocks just like any other online node does.
Click to expand...

Actually regular masternode payment can be easily validated based on info from the previous blocks.

But with superblock there is different situation:
What if after a superblock was created someone issues additional votes for another finalized budget so it becomes the most voted (for the past superblock). So the nodes would think that for creating that superblock incorrect finalized budget was used and they would reject it. Is such type of attack possible?

In general, there is a situation when for validating a superblock you need an information which is not stored in the blockchain. And that info can be manipulated in some way...
 
lpsun said:
Actually regular masternode payment can be easily validated based on info from the previous blocks.
...
Click to expand...
Not really, you need to reconstruct mn list which can't be done by using blockchain information atm.

lpsun said:
...
What if after a superblock was created someone issues additional votes for another finalized budget so it becomes the most voted (for the past superblock). So the nodes would think that for creating that superblock incorrect finalized budget was used and they would reject it. Is such type of attack possible?
...
Click to expand...
Finalized budgets for past blocks don't matter, they are simply ignored.
 
Status
Not open for further replies.
Back
Top