• 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.
When will there be a GUI for this version? CLI is a pain in the butt :).

Pablo.
 
Small Update

I'm going to be leading our testing of the sentinel platform by creating a real world simulation of what we're actually going to use the superblock system for. This basically comes down to needing to ensure that we can process more than 100 proposals that are generated from the community, so we're going to use real data for this process. The problem is basically herding cats at this point, it's hard to get everything humming with so many people involved.

The solution? I'm thinking we should add a small feature to sentinel, vote mirroring. The operator should be able to pick another trusted masternode that they would like to base their votes off of, then they will mirror all of these.

On mainnet, the feature could be expanded to allow us to enable an idea we've had for awhile, which is to create small committees which review proposals and then vote internally, then signal their decision to the network. We could have multiple independent committees of this kind doing research, even completely disagreeing at times. Masternode operators would then decide how much time they think they can spend on research and determine if they would like to do the research themselves, or trust one of these elected bodies to do the research on their behalf. Just an idea :)

I am still working the list of proposals to test and other requirements for making sure 12.1 is rock solid. More soon...
 
Small Update

I'm going to be leading our testing of the sentinel platform by creating a real world simulation of what we're actually going to use the superblock system for. This basically comes down to needing to ensure that we can process more than 100 proposals that are generated from the community, so we're going to use real data for this process. The problem is basically herding cats at this point, it's hard to get everything humming with so many people involved.

The solution? I'm thinking we should add a small feature to sentinel, vote mirroring. The operator should be able to pick another trusted masternode that they would like to base their votes off of, then they will mirror all of these.

On mainnet, the feature could be expanded to allow us to enable an idea we've had for awhile, which is to create small committees which review proposals and then vote internally, then signal their decision to the network. We could have multiple independent committees of this kind doing research, even completely disagreeing at times. Masternode operators would then decide how much time they think they can spend on research and determine if they would like to do the research themselves, or trust one of these elected bodies to do the research on their behalf. Just an idea :)

I am still working the list of proposals to test and other requirements for making sure 12.1 is rock solid. More soon...

With regards to vote mirroring :

For Testnet that could be a good method to mass-test and analyse the 12.1 proposal system, so i'm fine with that.
For Mainnet (through the use of small committees) i have reservations about this and feel this could impact voting behaviour in perhaps unexspected or unforeseen ways
 
Hi @eduffield, the committee system sounds a bit over engineered.

I find most proposals arent that complicated. And proposals that im not sure about, i tend to read the views of other community members i trust and go with them.

That being said, its always great to experiment. And would defo give it a go on testnet.
 
I suppose I misspoke, I don't mean we should create a bunch of committees now while the network is small. However, we're in the beginning stages of making a very complex and sophisticated software platform for money, if successful it will be of the valuation of a bank. That means we're going to be managing an awful lot of money and the projects will just continually grow in complexity until we do have problems. This is a solution to that future problem, not merely a hammer in search of a nail.
 
@eduffield I had to redo my comments in response to your clarification. What you are saying makes more sense now, but I would suggest we leave this committee discussion up to when it is needed due to the actual scale of the project and table it for now. Further, I feel like there is wisdom in crowd sourcing and I'm not convinced of this idea even at an enterprise level, this whole committee thing is open to manipulation and abuse. You engineered and excellent system of incentives with masternodes, if we reach a certain level, masternode owners will be able to dedicate resources to vetting more complex proposals as to their interest. Lets see where it goes first before centralizing is what I'm saying.

Pablo.
 
Ran the voting script from my dedicated tMN running v0.12.1.0-b9bd116. Returned 4 "Governance object not found!" failures, but also many successes.

tMN has been running for close to 48 hours. Quick scanning of the debug.log indicates things are generally fairly healthy. About to start testing some mixing from other nodes now. :)
 
Windows CMD version, if anyone need:
Code:
for %i in (148b22487c8acc3f7331e9db73c0da68fd0d2e7dd02efbe8f43f9951d7913e05 d7cb1936fca7efe2db94b39e7ea8ef63c8c4cf28206f25e783dc6e7eb35b6706 211fd7058a489700658daebaea83f863d2937d441865f7bef19c1026c3681208 1470642721e8d033be6b26bcb95c9b7efc1fb09b2b3ffe3e9d2a97dbe886a808 65a72fe16c91607d5839f493c8f4f4c42283027a00750aff50f1fc398970e60b 4f434004e1b6f0e553f59c5d2b606fa2683964f76927d726f06ba5afc45dad11 b9f42f914c0be92c9e044b1dc9aab8a9f6530fbacd6bc44279c92dc6d945ed1c 0ffd36400e5bd9fd470565c3591f8c1919a5b713342b295c5ec898fc7f89f320 e249875c34d280afb5b74b24208e9ca272f1bad54fc221f833061ed4a2e06a21 490ccbb1ce8b92682d92e41b0e8d21f9aaf0ea1aba727e2a03d0615d5f370025 985d30e963eb55d07af9f561cadbd1c118e6eefa6ca7226a3370e0a4273d5229 15f32baef7ce1eee24f8f0c71da468b89ac7e9e09d6b9a8092e756a22cb85f2c cb59b96654f53599723d290bae31477faf115fc0707c852696dbed7b7a406f2f 2a5a29910b4dd8aeebf0cdf4b1f4337f6b561275a11e14cad648fd8fee83b32f 0523445762025b2e01a2cd34f1d10f4816cf26ee1796167e5b029901e5873630 d01a2779efc8742106e4a9102cbcb9130b423b5d8bafda9e4d333eeac375a534 1d074c99dcdbe0791036f3513848f9c7e46494b153752f8eff471f23f1f6bf35 02020fec4848e75a22b31442775e42511c5bbdd450c211c7fbd5ea36f0cf4a37 a260c00411cd8beb523eda434e6b6f6975fdc457f509e160d18a02c3757d323f 741d95f1fa0527ad725f86dd8729385509f3e08530ba75ed068fea4279472b42 9161dbca3f91127702d62e0b4e4165ec39428b10691b34952d47553136fd7442 762d7ec4137bec3876c35322cb260f86a71225131932ff77c0d809d8a160d742 a180522bc1114e986746140afa66c6deade1be9e772a4e091865dbf2769a1959 7b73985cafdb7ba07fd541f74db751785e66dde76287356092f0c46609acd059 bce763ef31d3f27b8257240d0c1b8da83fe113eca84b34dada5544bf1502b95b 28d786336e8044481cb9711e1848c957adba33ff51ae7c3c913700d8e3bc0360 3500872ee6e96901bf47988382939dafb71e25488fe504565bd9eb5404e96361 96274f939f9f75e2a5d0076f21e4050a004c5139d5b445da04c7ae9f5d28d462 1e540fead1f4dd33be51c553213a7d880cc637c425004f23bfbb6ee3f9394864 273a73e5ec0ed811532ba5cd1aa9014aab5759c20f957b0e6e7fb592997e8966 dfd7d63979c0b62456b63d5fc5306dbec451180adee85876cbf5b28c69d1a86c cbde5fb320c6fe88487d5858cb06e1702cbee83700491d6214c364766291df6c 8f9c8e277b406a65499fc01c079192a21c0b251632d9672264dd14305e176d6e 855b94ec0fb5198bb5c301c43640dfc0caee8f9f41c113e17c4d5cf89257f46f 88bad1fbd9118c6181f66e392283f71d48a4c62d55205afec5e315b1a9ca5f75 bbcd920ead24e01ba4622fd678f035f775e83d7f44a6b0a83f8790d84223197d 34bf091d059eaa5810bdba14724296f6a38a06cbcce4e10ca1c8fea240082081 5625b09eab76cbb3bfab1caeada069dfd4fe7116db4a9e3f48d0e5daf566a681 fc8432581f168b90ed5150dcaa01526018e7c99a72d5854f0c5f37e705254a87 0643acd3f3f13ea5848c5db5fbaa37485e701df5e00602d5fb7851f3e87b388a c80f0a2b3f0a668c8cc94ab96adb111305a06200763b29946a7af2bde722499d a16af56f174ee7a4c709e9992e6d6e710b21e94c8f68426eb05b2012e509fa9f 92697190c5543ac4daa679e498bc1fbe2399256bfac357c6cc42e5a74f965ea5 6a7116b2ae806bb75c980a3f50dc91b3cece1615e0ce5b9d71f24dd1850f77a8 d2b46fac4ed401e100dab979426a30b7d10e68ee7cbc2aecdad4a08516b3cbac 8b9433723a9d030f134c0d4113800bca0663c4405e54257e3b4e036657151dad 1e34042e4b0bfc7cf6c1c179e7388ece7bb027aa13870e3fc60c484e757667b3 c6bdb47e55009c340ef05e3c3d96258025a13326f4c326001ff3bdc1babb5fb5 57c2cb76c2306363f68783ce83517dd11b4994caee3b400c1044384438f9a6b5 1c956c422b3c143005b4dd7c19d09a30e592e08833ea579a081e7d6378c3d6ba 7a16b77f38593bd6fa6eff64d3f9963759f96974c0fdda4de48f1dab3826f2bb 6121d1d3815f7e07ecd474241d8226ee22e0058e7bc7d3075793d65ed2e833c2 c51599a8ef590f2da4ac0b2ac6134820ce72e50532da41d2dda75506111771ca 1e7383edd1c1bea7f20d1ef55f1a14a4b6eeac8944751b1768981900107618cb a18e1dfa344e4b1979b6426760782b5acba2608f67c342c25088e8f370e130cd cbabfa3f1be7ba11be9c9b6365af269a6fd93d70d2dac2a868297f38bad070cd 13616a95bd4edfe0556429b4dbb57c11bc978b0d2cf06f2ebde7f43d57508ed9 4fe293d44dbe6b32c91ef54abf8d4f90642aac50e0ba2d237d3978db224833dd e11f52c2bf7505b88c0dddaad60892d8a25fd909ac3bf5fcd5df259f3e0d3bdd 8f91ffb105739ec7d5b6c0b12000210fcfcc0837d3bb8ca6333ba93ab5fc0bdf ab44e37d1e977351bb313f70d779844fe1d44f6165f83cdbf5c8031fa998ebe0 4b2154e0c3cb91f1f5c7ddd1adae741997ab6a841b5758c9e75f71d69f2378ea 22db1ab849300ecc48344039531e52f29c62d22529b43c215f03054431b7a8ef d66062e9aa31f60742910d4bc71e65d403305992eb324a0357c66f09bd0e56f6 40f3c06f61ce0443f82860f8b7b3c3407469ec9c5918c623e506fc6b3fc8e8f6) do dash-cli gobject vote-many %i funding yes
 
Ran the voting script from my dedicated tMN running v0.12.1.0-b9bd116. Returned 4 "Governance object not found!" failures, but also many successes.

tMN has been running for close to 48 hours. Quick scanning of the debug.log indicates things are generally fairly healthy. About to start testing some mixing from other nodes now. :)

We're still getting things sorted regarding test data, etc, so there might be a few hiccups. I expect I'll perform another import with more accurate/valid data within another day or so, but feel free to keep running against this data as it's all a good test for the 12.1 network/Sentinel at this time.
 
Anyone running any liquidity providers? Mixing isn't going very well so far, but I haven't been testing long, and I'm only using 1 node right now.
 
Anyone running any liquidity providers? Mixing isn't going very well so far, but I haven't been testing long, and I'm only using 1 node right now.

Mixing doesn't work right now, I guess testnet needs to stabilize first. Too much non-compliant Masternodes at the moment.
 
Mixing doesn't work right now, I guess testnet needs to stabilize first. Too much non-compliant Masternodes at the moment.

how do we determine "compliance" it looks like 85% are on current version is that not enough? can the MN with the closed firewalls be dropped or banned?
 
Just echoing what @eduffield is saying, eventually it's inevitable that we'll have people VOLUNTARILY delegating their votes to third parties. This month we had 26 proposals to vote on, which is manageable. But what happens when the price of Dash goes higher and higher, and suddenly we have 2600 proposals per month to vote on? Sure, by then most masternode owners will be able to "retire" and simply "manage" their masternodes full time. But what of the people who can't, or won't, or simply aren't interested in doing so?

I think the system should (and will be) voluntary, but eventually something like that will happen. In fact, I'd be very surprised if it hasn't happened already. I can almost guarantee that there are people who have delegated their mnprivkeys to others on the network to vote for them.

It's effectively a republican form of government, just like in the real world. I wouldn't worry too much about it for the time being, but Evan is always looking forward to the future and building tools that we don't need now but will be glad to have when the time comes.
 
Just echoing what @eduffield is saying, eventually it's inevitable that we'll have people VOLUNTARILY delegating their votes to third parties. This month we had 26 proposals to vote on, which is manageable. But what happens when the price of Dash goes higher and higher, and suddenly we have 2600 proposals per month to vote on? Sure, by then most masternode owners will be able to "retire" and simply "manage" their masternodes full time. But what of the people who can't, or won't, or simply aren't interested in doing so?

I think the system should (and will be) voluntary, but eventually something like that will happen. In fact, I'd be very surprised if it hasn't happened already. I can almost guarantee that there are people who have delegated their mnprivkeys to others on the network to vote for them.

It's effectively a republican form of government, just like in the real world. I wouldn't worry too much about it for the time being, but Evan is always looking forward to the future and building tools that we don't need now but will be glad to have when the time comes.

How does this relate to testnet? Maybe you posted in wrong thread.
 
How does this relate to testnet? Maybe you posted in wrong thread.

This post of Evans back on the first page:
Small Update

I'm going to be leading our testing of the sentinel platform by creating a real world simulation of what we're actually going to use the superblock system for. This basically comes down to needing to ensure that we can process more than 100 proposals that are generated from the community, so we're going to use real data for this process. The problem is basically herding cats at this point, it's hard to get everything humming with so many people involved.

The solution? I'm thinking we should add a small feature to sentinel, vote mirroring. The operator should be able to pick another trusted masternode that they would like to base their votes off of, then they will mirror all of these.

On mainnet, the feature could be expanded to allow us to enable an idea we've had for awhile, which is to create small committees which review proposals and then vote internally, then signal their decision to the network. We could have multiple independent committees of this kind doing research, even completely disagreeing at times. Masternode operators would then decide how much time they think they can spend on research and determine if they would like to do the research themselves, or trust one of these elected bodies to do the research on their behalf. Just an idea :)

I am still working the list of proposals to test and other requirements for making sure 12.1 is rock solid. More soon...

"Committees" sets alarm bells ringing for me but otherwise a big thumbs up, being able to delegate decision making is an essential step imho.
 
Last edited:
Dedicated tMN updated to v0.12.1.0-0d324ea. Seeing quite a bit of "last dsq too recent, must wait" messages in the debug.log. Is the problem with mixing really related to tMNs running old code? Seems we have a lot more tMNs than usual, so isn't it a pretty safe assumption that most of them are running at least v0.12.1.0-b9bd116?
 
Status
Not open for further replies.
Back
Top