V12 Testing Thread
- Thread starter eduffield
- Start date
While not terribly active, I am testing. Nothing terribly exciting, just that everything seems dandy on Windows 10 RC, but I'm deleting the bloody thing. It's a complete system hog under VM on my very current macbook pro.
Do have some catching up to get up to speed with you guys!
Do have some catching up to get up to speed with you guys!
It's a good thing evan codes better then he posts links and changes/updates version numbers.
flare
Well-known member
So, in case someone wonders about the myriads of proposal submissions: It's me 
I think that it may be a good idea to restrict the number of active proposals per MN/vin - otherwise we'll have a attack vector for a DDoS on the masternodes. Currently 'mnbudget show' takes 25 seconds for me, i wonder how much proposals the system is capable to handle
I think that it may be a good idea to restrict the number of active proposals per MN/vin - otherwise we'll have a attack vector for a DDoS on the masternodes. Currently 'mnbudget show' takes 25 seconds for me, i wonder how much proposals the system is capable to handle
Sub-Ether
Well-known member
So, in case someone wonders about the myriads of proposal submissions: It's me
I think that it may be a good idea to restrict the number of active proposals per MN/vin - otherwise we'll have a attack vector for a DDoS on the masternodes. Currently 'mnbudget show' takes 25 seconds for me, i wonder how much proposals the system is capable to handle
I am almost at the spec. limit already with this many, the system hangs for some time.
This happens at the end of mnbudget show,
Last edited by a moderator:
qwizzie
Well-known member
So, in case someone wonders about the myriads of proposal submissions: It's me
I think that it may be a good idea to restrict the number of active proposals per MN/vin - otherwise we'll have a attack vector for a DDoS on the masternodes. Currently 'mnbudget show' takes 25 seconds for me, i wonder how much proposals the system is capable to handle
i had the same problem at some point (mnbudget show command taking longer to execute) but that disappeared when i did a bootstrap rebuild with a new wallet version,
i just did one to get the blockchain synced correctly again for latest version v0.12.0.10-10ad242 and the command mnbudget show is not showing any delay.
Could it be stored in the debug console memory somehow, meaning the more you use that command the slower that debug console gets ?
Or maybe its the new wallet version overwriting the old one that refreshes the debug console's memory ?
By the way : is there a command to clear the debug console history, ?
Edit : i tried the command mnbudget show for a second time in that same debug console and now i hang for some time too .. maybe its taxing the memory.
Last edited by a moderator:
flare
Well-known member
I think it takes ages to sync the budget proposal list at the moment - there are currently >13.000 entries in there, and my local QT wallet only shows 100 atm and counting...
EDIT: Now i've got 31Mb of proposal data and my QT freezes on 'mnbudget show' for several seconds
Last edited by a moderator:
qwizzie
Well-known member
Damn 13000 entries ? i had no idea you guys were stress-testing with those kind of numbers, but the end-result does seem to be that it overloads the qt's debug console, making it sluggish and slow to work with (i tried it a third time after restarting the wallet, its indeed getting increasingly more slow)
flare
Well-known member
Code:
#!/bin/bash
for j in `seq $1 $2`;
do
printf -v i "%04d" $j
echo $i
KEY=`dash-cli getnewaddress spam`
echo $KEY
dash-cli mnbudget vote proposal-flare$i http://www.dashpay.io/$i.json 50 79000 $KEY 500 yes
sleep 5
done
Code:
./spam 0 10000
We can easily fix this in next build! :grin:I'm just popping in to say the newest version seems to be functioning for me
Haha, nice!
btw I was (also secretly :wink
doing smth like this but in a pretty dumb manner even before it became mainstream :grin:
Code:
i=1; while true; do dash_testnet-cli -conf=/root/.dash/dash-testnet.conf mnbudget vote proposal-qwizzie-$i http://www.dashpay.io/one$i.json $i $((78000+i*50)) y5WWMBMxHsL5xmscwAyxUf2vfwMX58pprA $i yes; i=$((i+1)); echo $i; sleep 1; doneDisclaimer: I'm not perfectly follow what Evan is doing in budgets part so I might miss smth
With that ^^^^ being said:
I was thinking of ways to stop this and restricting MNs to send proposals doesn't sound like a good idea, we need to stop actual proposal submitters from spamming in the first place imo. So here what I got in my thoughts so far:
1. proposal tx (ptx): one should spend
2. submit proposal (include ptx txid
ut as a part of it) signing it with private key that corresponds to the same proposal address (this now must be done from submitter's normal wallet, no need for MN in that case which is absolutely nice imo)3. network can now say if this proposal is legit by simply verifying that:
- proposal signature match proposal address
- ptx is confirmed (N required confirmations?) and the right fee was payed
and store proposals by hash.
4. to update proposal (s)he needs to create another ptx, proposals with the same ptx should not be allowed - in case there are two of them the one with the earliest valid sig wins and the older one is rejected (applying some ban score to that node (submitter's wallet) to prevent CPU usage attack on network)
5. MNs/MNers should vote by hash to avoid confusions
Feel free to find weak points and reap it apart
eduffield crowning
EDIT: no need in 0.01, spend whatever you want and ptx should be valid as long as you pay proposal_fee
Last edited by a moderator:
Also is it just me or does anyone else feel that a 1 month time frame for proposals might be too quick. I'm watching how long we have worked on testnet and thinking to myself how is anyone going to pull off a massive project in under 30 days? I guess there isn't a specific setting saying the proposal has to be done but if we have a ton of proposals going out and never getting finished it might be a major pita. I wonder if Quarterly would be better?
Also what about doing an actual live dry run on mainnet before we actually open up the proposals. I was thinking we do a multisig wallet and actually do some real world testing voting for that proposal live on mainnet trying to stop us from having another "instamine" fiasco.
I'm also seeing a lot of moving parts and don't want to see this release rushed out to mainnet like some others have in the past just to see 5 more updates on launch day. It's great that we are just taking our time under no major constraints and just working to get this all right.
Also what about doing an actual live dry run on mainnet before we actually open up the proposals. I was thinking we do a multisig wallet and actually do some real world testing voting for that proposal live on mainnet trying to stop us from having another "instamine" fiasco.
I'm also seeing a lot of moving parts and don't want to see this release rushed out to mainnet like some others have in the past just to see 5 more updates on launch day. It's great that we are just taking our time under no major constraints and just working to get this all right.
Last edited by a moderator:
crowning
Well-known member
Proposals are (more or less, permanent payments to the developer of your choice excluded) DASH projects. Valid projects run (including proposal and voting delay) in the order of weeks minimum.
We have about 2700 Masternodes. If each Masternode creates only 1 proposal, and the resulting projects run only 2 weeks average (that's optimistic, with discussion and voting it's easily 4 weeks minimum) we're talking about 5400 weeks, that's more than 100 years. Divide this by the number of developers and we'll have enough work for the rest of our lives.
My proposal :grin: to prevent SPAM/DoS is to allow each Masternode to create exactly one single proposal in its lifetime.
If someone REALLY wants/needs to create a second proposal he can move the 1000 DASH vin to a different address and create it from this new Masternode.
Minimum delay are the confirmations for the Masternode, which we already have in place.
Discuss!
flare
Well-known member
Exactly what i was thinking: use the same mechanism which limits the number of masternodes - it has proven to work since 1+ year now
"One vin, one vote, one proposal"
Sub-Ether
Well-known member
Some musings,Exactly what i was thinking: use the same mechanism which limits the number of masternodes - it has proven to work since 1+ year now
"One vin, one vote, one proposal"
Is there a way of creating a useable proposal VIN on a fresh wallet startup and sync (without a masternode) ?
When released, the VIN is canceled on the local machine somehow, so if the user wants to suggest another project he must delete the whole folder and reinstall and sync again before he can re-propose.
Also to stop spam, make a small charge of say 0.1 - 1 dash to enable the vote from any wallet.
If you go down the 1 masternode per proposal route, what about masternode holders selling off their proposal rights for a small price to enable people without a node to suggest a project (The price could be ball parked at 0.1 Dash, but masternode holders would do it for nothing if they liked the idea)
Again, only 1 idea per masternode (unless VIN address changed like Crowning says) but has the added fruity bonus that the masternode has a little bit of extra value, now it can propose new projects..
Exactly. But it's hard because the way the system works now is the project gets paid on a schedule unless/until enough masternodes vote to cut them off. It won't be a nimble system but it does keep the funds untouched by anyone else, so they don't get involved in taxes or responsibility (hopefully)
But if there were a way to do this, it would be perfect. We originally wanted to have an entity that watched over and approved payments, but that made them vulnerable. It's a sticky situation.
Wait, is this turning into a system where only masternode owners can propose projects / hence only masternode owners get to work for DASH? What about outside people? That's what we're trying to get; outside talent. I thought, at least for now, masternode owners would simply be asked to insert a proposal for projects on behalf of talent. I thought that was pretty hard already because proposals should be in the control of the talent, after all, the proposal ends up being his contract. This creates gate keepers already, in that they have to convince someone to enter their proposal in the first place. Not every masternode owner will be inclined to spend the time to do this for people. Or be able to, as they may not have time.Exactly what i was thinking: use the same mechanism which limits the number of masternodes - it has proven to work since 1+ year now
"One vin, one vote, one proposal"
If it's possible, I think it would be better if proposals expire after a month or two. If they're not accepted by then, they will have lost steam anyway, and the contractor proposing the project will likely have moved on already.
moli
Well-known member
I knew you were up to something when I had to down vote your many "flarexxxx" proposals... lol :tongue::grin:So, in case someone wonders about the myriads of proposal submissions: It's me
I think that it may be a good idea to restrict the number of active proposals per MN/vin - otherwise we'll have a attack vector for a DDoS on the masternodes. Currently 'mnbudget show' takes 25 seconds for me, i wonder how much proposals the system is capable to handle