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

V12 Testing Thread

Just checking in to say everything is great from my end, these budget proposals are a bit over my dummy skill level for now...
 
From Bitcointalk forum:
MasterMined7 said:
WastedLTC" said:
Given the nature of DASH. Can we please move away from a wallet.dat file that can be opened without password? Would be nice if the file was encrypted so if it was found on your computer or someone was able to grab it they couldn't see all of your transaction history.

bitshares has a cover screen where you must put in your password before being able to see your balance and transaction history. we need something like that!

I think this is an excellent idea. When you open the wallet, you can't see anything until you enter a code. I think it'd be especially cool if it could be a number keyboard, for easy unlocking, and not the same as the encryption password. Something easy to insert. That way you can protect your computer or cell phone, etc.. from prying eyes when it's sitting around.
 
For sure, Dash Core version v0.12.0.16-9e9e01b (32-bit)
Edit: I think that's new, no?

Lol, I hope it is, I ran over and installed it!

capture_007_14072015_182345.jpg
 
LOL, I'm so silly. I found a wallet.dat file on a jump drive and was wondering what the heck? What is that one? So I put it in, changed the dash.conf to be on main net, and waited, but it couldn't find a block source at about 6 weeks out..... And I'm waiting, and wondering... and then it dawned on me....

It's v12! Of course it's not working on mainnet, LOL.
 
Last edited by a moderator:
This proposal got only that first payment and hasn't got paid anymore.
I guess the next step is the proposal needs to be evaluated before the next payment?

The enforcement sporks are currently off while I've been debugging inconsistencies in budget items across the network. It actually seems to be working perfectly as far as I can tell on v12.0.17, so I'll be turning it on soon enough. Payments should be like clockwork soon!
 
This may or may not be relevant; I have been working on upgrading my technical prowess in the area of Linux security and just started running the Grsecurity kernel and PaX on my Arch Linux Lenovo T400 laptop. My .11.2.23 wallet runs fine but the last two test wallets fail with the following:

(dash-qt:3552): GLib-ERROR **: file gthread-posix.c: line 1182 (g_system_thread_new): error 'Operation not permitted' during 'pthread_create'
Trace/breakpoint trap (core dumped)

I suspect this is caused by running the compiled test executable from my desktop as opposed to /usr/bin/ but am posting this in case the devs think this is something that warrents their attention. In the meantime I am out of testing until I figure things out on my end.:mad::oops:
 
The enforcement sporks are currently off while I've been debugging inconsistencies in budget items across the network. It actually seems to be working perfectly as far as I can tell on v12.0.17, so I'll be turning it on soon enough. Payments should be like clockwork soon!
What I meant to ask is from your post https://dashtalk.org/threads/v12-testing-thread.5484/page-60#post-59115, you said:

5. Proposer or whoever starts the work
6. Proposer gets the first payment
7. Proposer submits progress reports for target milestones (if the community doesn't like what they're doing they can down vote them at this point or any time and stop future payments)
8. Proposer gets another payment 30 days later, submits another milestone report
9. Repeat 8 until the work is complete


How do we do continue with the procedure from #7 until the completion? Do approved proposals, after their first payment, go back to the voting board for the next votes before they get the next payment or not? And if this is how it's going to happen on Mainnet, then they're not getting paid like clockwork, but by the spork enforcement on or off, correct? (Sorry for so many questions, but I think many of us would want to know. Thanks, Evan.)
 
Please vote yes on the following!

dash-cli mnbudget vote f069240c45d7fe0e3952059c72225f133420be3ff8e764600a1cd4de2f5d4ccc yes
dash-cli mnbudget vote c782b9b9cc2c8bd8346f5300ecf0b88ec7c96ec483185fd5645a129efef34093 yes
dash-cli mnbudget vote a4830da09f674af25e8c68494344228c5bc4cd605cac009a9a0b76b2e86339a4 yes
dash-cli mnbudget vote 73409160b4e97ed712e67757ea6ff9cc6b32fc8087aeb41b355c3b2a635b8ffe yes
 
Please vote yes on the following!

dash-cli mnbudget vote f069240c45d7fe0e3952059c72225f133420be3ff8e764600a1cd4de2f5d4ccc yes
dash-cli mnbudget vote c782b9b9cc2c8bd8346f5300ecf0b88ec7c96ec483185fd5645a129efef34093 yes
dash-cli mnbudget vote a4830da09f674af25e8c68494344228c5bc4cd605cac009a9a0b76b2e86339a4 yes
dash-cli mnbudget vote 73409160b4e97ed712e67757ea6ff9cc6b32fc8087aeb41b355c3b2a635b8ffe yes

69 yeas cast for all! :)
 
What I meant to ask is from your post https://dashtalk.org/threads/v12-testing-thread.5484/page-60#post-59115, you said:

5. Proposer or whoever starts the work
6. Proposer gets the first payment
7. Proposer submits progress reports for target milestones (if the community doesn't like what they're doing they can down vote them at this point or any time and stop future payments)
8. Proposer gets another payment 30 days later, submits another milestone report
9. Repeat 8 until the work is complete


How do we do continue with the procedure from #7 until the completion? Do approved proposals, after their first payment, go back to the voting board for the next votes before they get the next payment or not? And if this is how it's going to happen on Mainnet, then they're not getting paid like clockwork, but by the spork enforcement on or off, correct? (Sorry for so many questions, but I think many of us would want to know. Thanks, Evan.)

There will be a portal where masternode operators can track the progress of different projects (eventually, it's in the works). Say a masternode votes yes, then the proposal gets a payment, that yes vote will remain yes until the operator changes their mind. If something happens and that proposal needs to be removed, anyone can lobby other masternodes to change their vote which will inturn kick the proposal out of the payment queue and stop payments. I'm imagining this will happen and you'll see messages on the threads/reddit to the effect of "Alert Masternode Operators, Please see this post about Proposal X. TLDR: We need to remove them from the budget system immediately"
 
Back
Top