Well, I'm still seeing it moli, maybe it's a propagation thing??
V12 Testing Thread
- Thread starter eduffield
- Start date
moli
Well-known member
Here's another test I've just submitted with 9 "NO" votes and 1 "YES" vote. Let's see how long it's going to stay up in the system:
EDIT: An hour later... I don't see this down-voted proposal on the list anymore:
EDIT: Also, note ""IsValidReason" : "Active removal"," from the screenshot.
EDIT: An hour later... I don't see this down-voted proposal on the list anymore:
EDIT: Also, note ""IsValidReason" : "Active removal"," from the screenshot.
Last edited by a moderator:
YES! I got a proposal payment! Cool!
And my ubuntu servers on 11.2.23 have fallen off the chain it seams
I don't know if there is a use for them being there like that anymore? So far, it all seems to work. In 5 hours or so, I will see if my proposal stops getting payments, which would mean everything is working as it should.
And my ubuntu servers on 11.2.23 have fallen off the chain it seams
I don't know if there is a use for them being there like that anymore? So far, it all seems to work. In 5 hours or so, I will see if my proposal stops getting payments, which would mean everything is working as it should.
My windows wallet was still on 12.35 and it got stuck at 78650. If there is anything interesting in that, let me know, I'll bundle up the debug log. You probably already fixed it in 36
moli
Well-known member
Block 79000 pays to one proposal:
http://test.insight.dash.siampm.com...55efbcacc39a2568ff80271d156264581c62430b0ad0e
Then block 79001 pays to another proposal:
http://test.insight.dash.siampm.com...cb9ecb5bcff0aa9020344791b221f26ed2db2ecaf2a87
Is this going to be the same pattern for Mainnet? What if we have 10, or 20... proposals approved on Mainnet and 10, or 20 blocks are excluded to pay to proposals and miners (all in a row instead of spreading out), and no payments for Masternodes? What can happen then?
EDIT: you know we have whiners about masternodes not getting paid...
http://test.insight.dash.siampm.com...55efbcacc39a2568ff80271d156264581c62430b0ad0e
Then block 79001 pays to another proposal:
http://test.insight.dash.siampm.com...cb9ecb5bcff0aa9020344791b221f26ed2db2ecaf2a87
Is this going to be the same pattern for Mainnet? What if we have 10, or 20... proposals approved on Mainnet and 10, or 20 blocks are excluded to pay to proposals and miners (all in a row instead of spreading out), and no payments for Masternodes? What can happen then?
EDIT: you know we have whiners about masternodes not getting paid...
Last edited by a moderator:
moli
Well-known member
The OP of this thread says:
"Proposal Application
We’ve had a developer working on the proposal viewing/submission website now for a couple of months. It’s going great and we’ll open that application up for testing after we’re happy with the v12 software."
So it doesn't say the website will or will not be ready at the launch of v12... The devs are still working on v.12.
eduffield
Core Developer
The voting side of the code wasn't checking if the masternode was actually valid, however the receiving side does. So you voted on your local client, but not on the network. I've fixed the code where it won't do this anymore
eduffield
Core Developer
A friend of mine is working on this project. I'll get together with him after v12 is launched, we'll get the site up sometime later this year. There's really no hurry on that side, we can use the forums for awhile.
eduffield
Core Developer
Block 79000 pays to one proposal:
http://test.insight.dash.siampm.com...55efbcacc39a2568ff80271d156264581c62430b0ad0e
Then block 79001 pays to another proposal:
http://test.insight.dash.siampm.com...cb9ecb5bcff0aa9020344791b221f26ed2db2ecaf2a87
Is this going to be the same pattern for Mainnet? What if we have 10, or 20... proposals approved on Mainnet and 10, or 20 blocks are excluded to pay to proposals and miners (all in a row instead of spreading out), and no payments for Masternodes? What can happen then?
EDIT: you know we have whiners about masternodes not getting paid...
Yep. There can only be 100 proposals and it's probably going to be much, much lower for awhile. If it's 10, that means the masternodes will have payments delayed by 25 minutes per month on average. I don't think they'll even notice.
eduffield
Core Developer
New Version - v0.12.0.37
Fixed a bunch of minor bugs that Tante/moli found, along with a few issues that could have cropped up in the future. The GetBudget code is a bit different, so I had to turn off enforcement until the network updates. Once we update, I'll turn it back on and make sure everything still functions properly.
eduffield
protocol bump
new wakeup/sleep sync code
Fixed GetBudget
Lower IX conf minimum …
check collateral tx, find masternode before vote
disable ix for fin budget submit
Fixed bug with AutoCheck finalbudget voting
disable try-lock on IBD
Add superblock checks in various places
Added ReprocessBlocks
Reconsider : typo, use i and break
UdjinM6
translations >80%
use fBlockchainSynced right on IsBlockchainSynced start
fix release notes format
refactor IsBlockchainSynced
add composite debug category dash=darksend+instantx+masternode+keepas… …
fix rpc for darksend
fix debug output
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
Fixed a bunch of minor bugs that Tante/moli found, along with a few issues that could have cropped up in the future. The GetBudget code is a bit different, so I had to turn off enforcement until the network updates. Once we update, I'll turn it back on and make sure everything still functions properly.
eduffield
protocol bump
new wakeup/sleep sync code
Fixed GetBudget
Lower IX conf minimum …
check collateral tx, find masternode before vote
disable ix for fin budget submit
Fixed bug with AutoCheck finalbudget voting
disable try-lock on IBD
Add superblock checks in various places
Added ReprocessBlocks
Reconsider : typo, use i and break
UdjinM6
translations >80%
use fBlockchainSynced right on IsBlockchainSynced start
fix release notes format
refactor IsBlockchainSynced
add composite debug category dash=darksend+instantx+masternode+keepas… …
fix rpc for darksend
fix debug output
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
eduffield
Core Developer
What exactly is different that you're referring to? Having a series of payments per proposal at the end of the month?
Except for when people voted to support said concept... How do their votes still apply when the concept has changed?
In a democratic society if you put something to referendum then change the referendum points is the original referendum still valid?
I don't disagree with the proposed changes but this has been such a moving concept it's hard to really keep up with everything thats changed and what hasn't. I myself have tried really hard to follow everything but honestly am completely lost as to what we are actually implementing compared to what we voted to implement.
eduffield
Core Developer
I rephrased my question, but you answered to my original statement before I even clicked submit! I don't think it's changed at all from what we originally discussed, just the implementation strategy has. For example, I don't think they voted on if everyone was paid in 1 block, vs 10 blocks, vs all blocks throughout the month.
It might help once we are done with all the implementation changes if we circled around back and updated the required verbiage so that everything matches up.
If you wanted to be extra proper you'd also have everyone reconfirm their votes of support based on the final draft of the new system. I doubt many would change their votes but to be respectful of democratic process and to give less ammunition to the troll's it might have some merit.
Since we are basically solving the problem for e-voting it would be nice to follow all of the proper democratic processes to get there.
If you wanted to be extra proper you'd also have everyone reconfirm their votes of support based on the final draft of the new system. I doubt many would change their votes but to be respectful of democratic process and to give less ammunition to the troll's it might have some merit.
Since we are basically solving the problem for e-voting it would be nice to follow all of the proper democratic processes to get there.
eduffield
Core Developer
I'm still not really sure what has changed since the vote? The original version, plus existing changes were all made prevote so they should still be favorable to everyone that voted. There's no change that was made to the system after the vote that was non-technical in nature. Maybe I'm missing something?