We need a dancing emoji
I found a bug! I found a bug! LOL
I found a bug! I found a bug! LOL
12.1 Testnet Testing Phase Two Ignition
- Thread starter eduffield
- Start date
- Status
GNULinuxGuy
Active member
Dedicated tMN updated to v0.12.1.0-8fc8e6c and synced nmarley sentinel. Looking pretty healthy so far. Should have time to do some proper testing tomorrow. Hopefully most of the tMNs will be running the latest code by then. 
We had our internet go out last night for I don't know how long, and today, my windowz wallet is still not synced up. Shouldn't the wallet notice it's offline and reconnect when it can, then download the latest blocks?
qwizzie
Well-known member
v0.12.1.0-88ee7a3
* Mixing is still not working optimal, still a lot of "privatesend request incomplete session timed out" messages that effects the speed of Privatesend mixing and in some cases even blocks mixing.
* Amount getting exceeded during mixing will still need to be looked into and fixed, please keep that in your backhead.
* Two of my wallets actually got stuck during syncing while starting up (it wont sync from blocknumber 120287 any further for example), i needed to do a re-index on both wallets to fix this
Wallet seem to think it is synced already, no message of out of sync.
* a large part of the Testnet (50% !!) is still not updated it seems, is that deliberate for testing purposes or do a lot of test masternodes still need to update ?
* Mixing is still not working optimal, still a lot of "privatesend request incomplete session timed out" messages that effects the speed of Privatesend mixing and in some cases even blocks mixing.
* Amount getting exceeded during mixing will still need to be looked into and fixed, please keep that in your backhead.
* Two of my wallets actually got stuck during syncing while starting up (it wont sync from blocknumber 120287 any further for example), i needed to do a re-index on both wallets to fix this
Wallet seem to think it is synced already, no message of out of sync.
* a large part of the Testnet (50% !!) is still not updated it seems, is that deliberate for testing purposes or do a lot of test masternodes still need to update ?
Just want to report that I'm experiencing very slow mixing also
@camosoul, I set mine up exactly per instructions, not the way I usually have my MN set up. Including downloading to .dashcore etc... Also, if you're starting from a fresh OS install, you probably need the libraries for bitcoin and any others Dash uses. I haven't done it from scratch in such a long time that I can't remember all of them???
Forgive me if that's obvious, I'm just trying to help Oh wait, these are pre-compiled... Um, I dunno :/
@camosoul, I set mine up exactly per instructions, not the way I usually have my MN set up. Including downloading to .dashcore etc... Also, if you're starting from a fresh OS install, you probably need the libraries for bitcoin and any others Dash uses. I haven't done it from scratch in such a long time that I can't remember all of them???
Forgive me if that's obvious, I'm just trying to help
Oh wait, these are pre-compiled... Um, I dunno :/
S
snogcel
Guest
Hey guys! @hunterlester and I have been working on a Budget Proposal generator and we could use your help and feedback. Have a look at http://govobject-proposal.slayer.work, this site is designed to walk you through the process of creating and submitting a budget proposal.
Questions:
1. Are the Proposal details clear (especially payment dates and amounts)?
2. Are there any suggested changes in verbiage / language?
3. Generally speaking, is the process clear?
4. Any other ideas or feedback?
Thanks for your help
To view proposals after they've been submitted see https://dev-test.dash.org/insight-api-dash/gobject/list
Questions:
1. Are the Proposal details clear (especially payment dates and amounts)?
2. Are there any suggested changes in verbiage / language?
3. Generally speaking, is the process clear?
4. Any other ideas or feedback?
Thanks for your help
To view proposals after they've been submitted see https://dev-test.dash.org/insight-api-dash/gobject/list
I would suggest changing the "First Payment" box from dated to "current voting cycle" "upcoming voting cycle" or something along those lines; I found the dates confusing, or you could make it so that it displays the block number for the upcoming budget cycle. Either way, I'm guessing not a lot of people plan budget proposals more than a couple of months in advance?
Also I would suggest taking number of "payments" all the way up to 100, you stopped at 97 for some reason, if I recall the spec correctly 100 is the limit?
Awesome job, looks very clean and professional.
Pablo.
Also I would suggest taking number of "payments" all the way up to 100, you stopped at 97 for some reason, if I recall the spec correctly 100 is the limit?
Awesome job, looks very clean and professional
.Pablo.
Snogcel, that's pretty slick! I put in a proposal for Chocolate Cake, so when my 6 confirmations are ready, I'll post my voting information
Seriously, though, isn't this the version of Dash that is supposed to have a bunch of new parameters to make more complex contracts? Or is that for another time? I've only been trying to mix and run MNs to help out here, so I have no idea what is happening under the hood really
Seriously, though, isn't this the version of Dash that is supposed to have a bunch of new parameters to make more complex contracts? Or is that for another time? I've only been trying to mix and run MNs to help out here, so I have no idea what is happening under the hood really
AndyDark
Well-known member
Snogcel, that's pretty slick! I put in a proposal for Chocolate Cake, so when my 6 confirmations are ready, I'll post my voting information
Seriously, though, isn't this the version of Dash that is supposed to have a bunch of new parameters to make more complex contracts? Or is that for another time? I've only been trying to mix and run MNs to help out here, so I have no idea what is happening under the hood really
on the governance changes in 12.1, the advanced functions are there, we're just not using the advanced features yet. is more like foundational changes that needed to be done ready for Evolution. there's a lot of improvements outside of just governance in 12.1 though
S
snogcel
Guest
I would suggest changing the "First Payment" box from dated to "current voting cycle" "upcoming voting cycle" or something along those lines; I found the dates confusing, or you could make it so that it displays the block number for the upcoming budget cycle. Either way, I'm guessing not a lot of people plan budget proposals more than a couple of months in advance?
Also I would suggest taking number of "payments" all the way up to 100, you stopped at 97 for some reason, if I recall the spec correctly 100 is the limit?
Awesome job, looks very clean and professional
Pablo.
Thanks @fible1! It's honestly been a little bit of a challenge to find a good way to frame budget proposal start/stop times. I like the idea of relating it to voting (trying to make this easier for non-dash-nerds, no offense intended to any of us lol). I've adjusted the verbiage to "Voting Deadline", do you guys think this is clear?
Top left logo text looks like 'Govemance', font is too tight.
Thanks @AjM! Going to see what we can do about this one.
Snogcel, that's pretty slick! I put in a proposal for Chocolate Cake, so when my 6 confirmations are ready, I'll post my voting information
Seriously, though, isn't this the version of Dash that is supposed to have a bunch of new parameters to make more complex contracts? Or is that for another time? I've only been trying to mix and run MNs to help out here, so I have no idea what is happening under the hood really
Thanks @TanteStefana! If I had a Testnet Masternode you'd have my vote
camosoul
Well-known member
Yeah, it had the MySQL business in it.
In a slightly off-topic point that need be made. XVC has (had?) an important feature in it's IX implementation. The RECIPIENT could request a TX lock.
This would preclude a merchant that requires IX having to bork the TX, bounce it, wait for user to do it correctly, etc. When the user fails to do it correctly.
It could also plug a potential exploit. Even if DASH decides that all TXes are IXes by default, it would still be possible for a modified client to not issue lock requests and ficntion as a legacy blockchain 1.0 bitclone, letting the backward compatibility be used against the merchant. Relying on the sender alone could present a problem if someone gets clever. So, having the recipient be able to request lock and not just rely on all clients to play fair (which is the mistake of double-spendable bitclones), is a security measure that people in the real world need.
Think of the potential for ugliness if the sender could still dump a ton of TXes from the same inputs into the memory pool, and then determine for himself which one gets a lock request... the mode of operations would be virtually no different that fee priority of a bitclone double-spend. That's a guaranteed double-spend. It seems much more secure for lock requests to come from the recipient end. the recipient is the one that needs the assurance. The sender has nothing to lose from failing this, and if not wearing a white hat, everything to gain...
If this were arbitrated by the nodes, and neither side had any say, that would be even better...
But, it's a complete departure from the current implementation.
this has multiple advantages... If someone tries to dick over a merchant in the current methodology, all they have to do is not use IX. They could claim it's an accident, oops, sorry. But, if the lock originates from the recipient, any conflicting/competing lock request would be a flag of deliberate fraud. Closed-loop instead of the current open-loop. The intent becomes defined. Kind of like adding an abstain vote; it gives is a definition between null for unknown reasons, and null for a specific reason. If the IX lock request is legit, then there is only one on the network. If a second lock request appears, and has a valid signature from the sender, we know the sender is deliberately trying to defraud the recipients lock.
Lock requests could be based on the privatekey of the recipient address or sender inputs. Lock request spam from 3rd party observers would be automatically ignored because they won't have the sig.
This could also lead to identity-less banning of receiving addresses which attempt to defraud IX locks. That would be a kickass feature. If the address was in a deterministic string, oh man, there could actually be consequences for being a dickhead on the network without exposing an identity. Real enforcibility. If it were extended to contracts... If you could blacklist all inputs for X blocks into the future... 3 strikes and you're out... Wow.
In a slightly off-topic point that need be made. XVC has (had?) an important feature in it's IX implementation. The RECIPIENT could request a TX lock.
This would preclude a merchant that requires IX having to bork the TX, bounce it, wait for user to do it correctly, etc. When the user fails to do it correctly.
It could also plug a potential exploit. Even if DASH decides that all TXes are IXes by default, it would still be possible for a modified client to not issue lock requests and ficntion as a legacy blockchain 1.0 bitclone, letting the backward compatibility be used against the merchant. Relying on the sender alone could present a problem if someone gets clever. So, having the recipient be able to request lock and not just rely on all clients to play fair (which is the mistake of double-spendable bitclones), is a security measure that people in the real world need.
Think of the potential for ugliness if the sender could still dump a ton of TXes from the same inputs into the memory pool, and then determine for himself which one gets a lock request... the mode of operations would be virtually no different that fee priority of a bitclone double-spend. That's a guaranteed double-spend. It seems much more secure for lock requests to come from the recipient end. the recipient is the one that needs the assurance. The sender has nothing to lose from failing this, and if not wearing a white hat, everything to gain...
If this were arbitrated by the nodes, and neither side had any say, that would be even better...
But, it's a complete departure from the current implementation.
this has multiple advantages... If someone tries to dick over a merchant in the current methodology, all they have to do is not use IX. They could claim it's an accident, oops, sorry. But, if the lock originates from the recipient, any conflicting/competing lock request would be a flag of deliberate fraud. Closed-loop instead of the current open-loop. The intent becomes defined. Kind of like adding an abstain vote; it gives is a definition between null for unknown reasons, and null for a specific reason. If the IX lock request is legit, then there is only one on the network. If a second lock request appears, and has a valid signature from the sender, we know the sender is deliberately trying to defraud the recipients lock.
Lock requests could be based on the privatekey of the recipient address or sender inputs. Lock request spam from 3rd party observers would be automatically ignored because they won't have the sig.
This could also lead to identity-less banning of receiving addresses which attempt to defraud IX locks. That would be a kickass feature. If the address was in a deterministic string, oh man, there could actually be consequences for being a dickhead on the network without exposing an identity. Real enforcibility. If it were extended to contracts... If you could blacklist all inputs for X blocks into the future... 3 strikes and you're out... Wow.
Last edited:
qwizzie
Well-known member
Mixing seems to be working again fast and furocious with latest build version v0.12.1.0-8c16880
and with multi-session enabled.
Note : i do come across a difference in enabled number of masternodes between my wallets (some show 5, some show 58), but it does not seem to effect the mixing
Update : the "enabled number of masternodes 58" also seems to be dropping over time, i guess the network is still busy with sorting that out.
and with multi-session enabled.
Note : i do come across a difference in enabled number of masternodes between my wallets (some show 5, some show 58), but it does not seem to effect the mixing
Update : the "enabled number of masternodes 58" also seems to be dropping over time, i guess the network is still busy with sorting that out.
Last edited:
started last night trying to get a test-MN running on azure since i realized i had plenty of MSDN credits which are never used but having issues connecting to it, i have added port 19999 in the FW but my local win-qt wallet keeps saying its not a capable node (cant find external IP) when trying to activate..
am i missing some openings or its simply the wrong port? once i get it sorted i will deploy a 2nd masternode for testing also
but having issues connecting to it, i have added port 19999 in the FW but my local win-qt wallet keeps saying its not a capable node (cant find external IP) when trying to activate..am i missing some openings or its simply the wrong port? once i get it sorted i will deploy a 2nd masternode for testing also
flare
Well-known member
How do your dash.conf and masternode.conf files look like?started last night trying to get a test-MN running on azure since i realized i had plenty of MSDN credits which are never used
am i missing some openings or its simply the wrong port? once i get it sorted i will deploy a 2nd masternode for testing also
on the MN as below. actually occured to me now it could be the addnodes parameter perhaps? i basically took it from my prod-MN's..
noticed when i was pasting that rcpport was wrong, changed it but now i get "
Error: Unable to bind to 0.0.0.0:19999 on this computer. Dash Core is probably already running.
Error: Failed to listen on any port. Use -listen=0 if you want this.
" when trying to run.
"
Dash.conf
#CHANGE THE FOLLOWING TO STRONG RANDOM STRING#
rpcuser=
rpcpassword=
rpcallowip=127.0.0.1
rpcport=19999
listen=1
server=1
daemon=1
logtimestamps=1
maxconnections=256
addnode=23.23.186.131
# IF YOU PLAN ON RUNNING YOUR MASTER-NODE VIA TOR UNCOMMENT THE FOLLOWING & REFER TO THE TOR GUIDES #
#proxy=127.0.0.1:9050
#--- DO NOT FORGET TO ENTER THE CORRECT PUBLIC IP# Enter
Code:
curl icanhazip.com
#--------------------------------------------------
externalip=13.69.252.102
masternode=1
masternodeprivkey=X
"and masternode.conf;
# Masternode config file
# Format: alias IPort masternodeprivkey collateral_output_txid collateral_output_index
# Example: mn1 127.0.0.2:19999 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 2bcd3c84c84f87eaa86e4e56834c92927a07f9e18718810b92e0d0324456a67c 0
RolandMN-TS01 13.69.252.102:19999 91sE66vU6NQtYjooTyogTD2FFFFFFFFFFFFFFsXgYqgGp424TG yTfeeHYXXXXXXXXXXXXXXXtyBxdqZ7vy8q9Zm 0
# Masternode config file
# Format: alias IP
ort masternodeprivkey collateral_output_txid collateral_output_index# Example: mn1 127.0.0.2:19999 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 2bcd3c84c84f87eaa86e4e56834c92927a07f9e18718810b92e0d0324456a67c 0
RolandMN-TS01 13.69.252.102:19999 91sE66vU6NQtYjooTyogTD2FFFFFFFFFFFFFFsXgYqgGp424TG yTfeeHYXXXXXXXXXXXXXXXtyBxdqZ7vy8q9Zm 0
flare
Well-known member
rpcport should be different from 19999 (which is the p2p port)
- Status