v13.0 Testing

OK, I still got an error as before, but with the venv/bin/python bin/sentinel.py command, I got this:

@Dash1:~/.dashcore/sentinel$ venv/bin/python bin/sentinel.py
-342: non-JSON HTTP response with '401 Unauthorized' from server
Cannot connect to dashd. Please ensure dashd is running and the JSONRPC port is open to Sentinel.
ingie@Dash1:~/.dashcore/sentinel$ dash-cli getinfo

Perhaps I'm missing something in my dash.conf?

Yup, I thought I didn't need anything in dash.conf except testnet=1 but I see I need the full shebang :)

If anyone can send over 1000 tdash to my address in the post above, I can get a MN up and running :) Here again ;) yebcSn2s3cdw75BQgiVV76itL1fAk5T6rW
 
Last edited:
Hi @TanteStefana I sent you 1K tDASH to get your tMN started.
https://testnet-insight.dashevo.org...e8e3a880c5088b9766de0c892f9293bd808704fa75a3d
Can you meet me in Discord to troubleshoot this?
Make sure that
Code: 
dash-cli getblockcount
returns 266838 or higher.
Make sure your dash.conf has these lines and XXXXX filled out correctly, note for the RPC user/pass only use letters or numbers!
Code: 
testnet=1
rpcuser=XXXXXXXXXXXXXXXXXXX
rpcpassword=XXXXXXXXXXXXXXXXXXXXX
rpcallowip=127.0.0.1
listen=1 
server=1
daemon=1
masternode=1
masternodeprivkey=XXXXXXXXXXXXXXXXXXXX
externalip=XXXXXXXXXXXXXXXXXX
If you that is OK, and you are syncing up correctly try
Code: 
dash-cli mnsync status
and make sure you tMN is synced, if that is OK. Start it from the 13.0 RC4 test wallet. Then try sentinel again. Meet me on discord, this forum is too hard for this sort of troubleshooting.
 
* Mempool problems are gone, all my wallets now show the same number of current transactions & same memory usage in mempool.
(Mempool problem description : my wallets that were actively mixing yesterday showed a higher number of current transactions in mempool, then my wallets that were not mixing).

* InstantSend still not working, which means we can not currently view or test Automatic InstantSend for Simple Transactions & InstantSend transactions.

For those unfamiliar with Automatic InstantSend for Simple Transactions : https://blog.dash.org/product-brief-dash-core-release-v0-13-0-5d7fddffb7ef
InstantSend payments allow users to exchange payment instantly using Dash’s masternodes. When a user sends a payment via InstantSend, a quorum of 10 masternodes is selected for each input of the transaction.
The transaction is then “locked” when a majority of masternodes for each input agree that the input they are responsible for is valid, thus preventing double-spending.

With Release 0.13.0, the system will automatically attempt to lock any transaction with 4 or fewer inputs — which are referred to as “simple” transactions — and remove the additional fee for InstantSend, so only the standard transaction fee applies.
These transactions make up over 90% of all transactions on the Dash network — which means the majority of Dash transactions are about to get even faster, at no additional cost.
Click to expand...

This will also include a special key figure inside these simple transactions, to indicate its locked through Automatic InstantSend.

* DIP3 Masternodes Tab : for testing it is nice to see the operator reward & address per masternode (if they set it), but for Mainnet showing the operator reward address could form a privacy issue when they set a different operator address then the mn pub address.
If this operator reward field only ever show the MN pub address then its okay, as that is the same as Payee field which is public knowledge.

IIImKMD.jpg
 
Last edited:
xkcd said:
@qwizzie Good to hear! For Auto IS, would we not require SPORK16 activated?

View attachment 9017

View attachment 9018
Click to expand...

I was struggling with how to interpretate these spork values yesterday myself and ended up checking "spork show" on both mainnet and testnet to determine if value 0 ment active or not active.
"spork active" command is much more clear in that area, so i will be using that for now on.. thanks.
Looks like we need to indeed wait for activation of spork 16 to get AutoIS working, thank you.
 
Mempool problems are gone, all my wallets now show the same number of current transactions & same memory usage in mempool.
(Mempool problem description : my wallets that were actively mixing yesterday showed a higher number of current transactions in mempool, then my wallets that were not mixing).
Click to expand...

I spoke too soon, i put some wallets to perform mixing again today and they too end up with a higher number of current transactions in mempool, compared to those wallets that are not mixing.
When there is a lot of mixing going on, that can speed up the difference in number of current transactions in mempool across wallets / users.

https://imgur.com/DcQyHEP
https://imgur.com/HhDwFPl
 
Last edited:
xkcd said:
@qwizzie Good to hear! For Auto IS, would we not require SPORK16 activated?

View attachment 9017

View attachment 9018
Click to expand...

qwizzie said:
I was struggling with how to interpretate these spork values yesterday myself and ended up checking "spork show" on both mainnet and testnet to determine if value 0 ment active or not active.
"spork active" command is much more clear in that area, so i will be using that for now on.. thanks.
Looks like we need to indeed wait for activation of spork 16 to get AutoIS working, thank you.
Click to expand...

Weird thing though : From page 1 post 1

We are at stage 4. and I will update this line every time we move forward to the next stage.
Click to expand...

- Starting with stage 3., test if automatic InstantSend locks for simple transactions are working as expected.
Click to expand...

Does this mean spork 16 should have been active since stage 3 ?
 
Last edited:
Dunno @qwizzie but I am able to get some PS IS TXes through!

upload_2018-11-19_1-6-35.png


Since there are still not enough MNs for IS to work on large TXes since you need a large quorum, you gotta send a single input and take no change.

Steps

0) Enable coin control
1) Click on inputs and select one input that has mixed enough rounds accroding to how many rounds you are mixing to. Click OK.
2) Check the following three boxes, Subtract fee from amount, PS and IS
3) Copy the amount from the top of the screen, right click copy an paste into the amount field.
4) Fill in the address details and click send.

If you did it right, it is a one input, one output TX and will get IS locked !
-X
 
Hello instant-locked transaction :

QQbrSVL.jpg


Thank you xkcd

To UdjinM6 : maybe adjust the column-wide a tiny bit, so the lock symbol fits in it more (without user having to widen the column)
Actually i think my monitor resolution interfered there, when i ignore high dpi in windows it looks just fine.

Funny thing, the lock symbol disappears again when the transaction is fully confirmed (six confirmations).
Which makes sense.
 
Last edited:
Technologov said:
Hello, while working on v13 "Evolution", can you please revisit my idea of new address type for Dash Insta-Send, as described here ?
https://github.com/dashpay/dash/issues/1559

"Assume a retail merchant wants to accept ONLY InstantSend transactions.
Today there is no way to make it happen. A retailer accepting Dash may get a normal transaction, and get double-spend attacked. This technique will improve zero-confirmation security from the retailer point of view.
I would like to propose a new Dash address type (starting with "IX..." or "D..."), which will only accept InstantSend transaction types. (but allow to spend/outgoing to any address)"
Click to expand...

I don't know if anyone ever answered your question, but since every transaction on the network is going to be an IS transaction, this is unnecessary.

Thank you so much, xkcd

So, I have another problem:

14:00:08
protx register_prepare e68611bb8bfa7ef3f65e8e3a880c5088b9766de0c892f9293bd808704fa75a3d 0 IP:19999 yUEhRFS6cZ9njP7DmQ4UdaBjkDgCvzRNLi 956adf179a20930bdc106a1d07446a2967f15d59df91f4a8895dccfe7df9334478c870d7af2aaca23b43e3b5fd81130a yUEhRFS6cZ9njP7DmQ4UdaBjkDgCvzRNLi 0 yg8G647Sqg6xqh3z2XSv4ZFrXmueCTa8NV
14:00:08

Insufficient funds. (code -32603)

If I double click on my transaction, I get my transaction ID and output Index. Are these not the same as I would find on the explorers? (I cant't find the index # on the testnet explorers undoubtedly because I am kinda dyslexic and when layouts are all different, I run up against a wall, LOL. I'm used to chainz...

There are 554 confirmations (again, thank you xkcd!)
 
Hi @TanteStefana, A lot of questions there, but I think I can help you. Firstly the 'protx submit' command does require some tDASH to pay for the miner, so in case that is your issue I just sent you some extra tDASH for that. There is a working explorer you can use https://testnet-insight.dashevo.org/insight/address/yebcSn2s3cdw75BQgiVV76itL1fAk5T6rW but it isn't as good as the cryptoid one. You should be able to verify the output hash and index by typing in 'masternode outputs' in the QT wallet. Your 'protx register_prepare' looks OK to me. However, remember that you first have to create a regular tMN before updating to tDMN. I just checked the tMNs on testnet and could not find yours there. So make sure you first setup it up as a regular tMN.

Good Luck!
-X
 
AH! That's the problem! It's a fresh setup and I did not get it running before hand! Thanks so much!
 
@UdjinM6 While mixing, I noticed these red X on my screen for 'conflicted' transactions. I was mixing for 16 rounds with multi-session enabled on 13.0RC4. Is this something you are interested in? Is this a bug or expected behaviour?

upload_2018-11-19_12-22-13.png
 
Ugh, I'm having a hell of a time syncing. This is my 4th attempt, it was stuck at 18 hours forever. I've tried deleting peers.dat this time and reindexed. Is it really slow to sync on testnet? Earlier I saw more than 400 nodes, so I would think not, but???
 
TanteStefana said:
Ugh, I'm having a hell of a time syncing. This is my 4th attempt, it was stuck at 18 hours forever. I've tried deleting peers.dat this time and reindexed. Is it really slow to sync on testnet? Earlier I saw more than 400 nodes, so I would think not, but???
Click to expand...
Try keeping only v.13 nodes in your peers tab (kick the others), then copy a bunch of them that seem reliable (stay connected) and put them as nodes in your dash.conf (addnode=ipaddress).
Lastly delete the peers.dat file and start the wallet again.

You can add these for now :

addnode=140.82.59.51:19999
addnode=66.244.243.87:19999
addnode=145.239.235.17:19999
 
Last edited:
You must log in or register to reply here.
Back
Top