12.1 Testnet Testing Phase Two Ignition

Status
Not open for further replies.

lpsun

New Member
Oct 12, 2016
12
5
3
32
If a masternode drops of the payment list / network due to not being active or due to movement of collateral, it looses its voting power and also its voting history. Once the masternode gets active again on the network it will show on DashCentral as not having voted yet on the budget proposals... even if you have voted with it in the past.
Is that true? In this case at some point in the future a lot of votes will be invalid because definitely the list of MNs is changed with time. And corresponding proposals, budgets, blocks also would be invalid?
 

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
Is that true? In this case at some point in the future a lot of votes will be invalid because definitely the list of MNs is changed with time. And corresponding proposals, budgets, blocks also would be invalid?
I think a masternode that dropped of the network (longer then a hour i think) and then reactivates itself on the network can then only vote on those budget proposals that still have a time window open to vote on them (like multi-period proposals and proposals that were added after the last superblock). Proposals and Budgets from previous Superblocks are already finalized and can not be voted on anymore, so those wont get invalid.

Please correct me if i'm wrong here guys....
 

UdjinM6

Official Dash Dev
Core Developer
Dash Core Group
May 20, 2014
3,639
3,537
1,183
I think a masternode that dropped of the network (longer then a hour i think) and then reactivates itself on the network can then only vote on those budget proposals that still have a time window open to vote on them (like multi-period proposals and proposals that were added after the last superblock). Proposals and Budgets from previous Superblocks are already finalized and can not be voted on anymore, so those wont get invalid.

Please correct me if i'm wrong here guys....
All finished proposals which were finalized and payed out (i.e. recorded in the blockchain) are no longer voted on. In other words, it doesn't mater have masternode dropped out of list or not, all currently active masternodes vote only on currently active proposals (including multi-months proposals which still have more payouts scheduled), they never vote on finished ones.
 

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
Any status update on the network ? All i'm seeing from my wallets (v0.12.1.0-cce7896) that are trying to mix is "privatesend request incomplete, unknown response"
and the PS compatible masternodes that my wallets are connected to are constantly dropping to very low numbers..
 

tgf314

New Member
Oct 17, 2016
30
4
8
53
It seems that only a small number of masternodes have upgraded so far (I currently see 16).
 

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
It seems that only a small number of masternodes have upgraded so far (I currently see 16).
It would be nice for the future to have a certain number of test masternodes (lets say 100) in direct control of dev team so testing on Testnet does not stagnate
due to slow upgrading. I would even support a budget proposal for that...
 

tgf314

New Member
Oct 17, 2016
30
4
8
53
All i'm seeing from my wallets (v0.12.1.0-cce7896) that are trying to mix is "privatesend request incomplete, unknown response"
How many enabled masternodes are you currently seeing ?
 

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
How many enabled masternodes are you currently seeing ?
I already closed all my wallets before reading your post. I opened 3 wallets just now with the following results :

Wallet 1
Total 80 (PS Comp 17 / Enabled 17)
Wallet 2
Total 80 (PS Comp 14 / Enabled 14)
Wallet 3
Total 80 (PS Comp 17 / Enabled 17)

edit :

Wallet 4 :

Total 23 (PS comp 22 / Enabled 22)
note : this one is still low on connections (just 3 connections)
 
Last edited:

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
The latest v0.12.x code only allows IPv4 Masternodes, no IPv6 or TOR Masternodes any more.
Details: https://github.com/dashpay/dash/pull/1065
Good move. Attack the IPv6 issue later. It simply should not be a priority. If it were trivial... sure, add it in. But it seems to be problematic. This is not a "must have" by any stretch for at least a stretch of years.
 

DashNation

New Member
Jun 18, 2016
30
18
8
23
Why is testnet so broken? what is with all the 1.1.1.1 nodes? Is there some bug reported for node ip duplication issues?where do we report bugs do we need an account for github? These nodes are not working obviously and causing mixing isses but still getting MN rewards somehow de spite being 25% unlisted this not good if these bugs can be used on main net.
 

tgf314

New Member
Oct 17, 2016
30
4
8
53
Why is testnet so broken? what is with all the 1.1.1.1 nodes? Is there some bug reported for node ip duplication issues?where do we report bugs do we need an account for github? These nodes are not working obviously and causing mixing isses but still getting MN rewards somehow de spite being 25% unlisted this not good if these bugs can be used on main net.
We've spent the last few weeks working on fixes for these problems. The latest builds should not be affected, have you upgraded to the lastest dashd and sentinel ? If so you should not see invalid masternodes in the ENABLED state.
 

UdjinM6

Official Dash Dev
Core Developer
Dash Core Group
May 20, 2014
3,639
3,537
1,183
  • Like
Reactions: qwizzie

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
Mixing process is starting now with latest build (v0.12.1.0-66c40e0) but i come across signing time-outs, four times now .. here is some debug info.
No successfull mixing so far...

Code:
2016-10-21 18:13:27 CDarksendPool::SetState -- nState: 4, nStateNew: 5
2016-10-21 18:13:27 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-21 18:13:27 CMasternodeSync:ProcessTick -- nTick 1801 nMnCount = 22
2016-10-21 18:13:28 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-21 18:13:29 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting .. )
2016-10-21 18:13:30 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-21 18:13:33 CMasternodeSync:ProcessTick -- nTick 1807 nMnCount = 22
2016-10-21 18:13:35 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-21 18:13:36 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting .. )
2016-10-21 18:13:37 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-21 18:13:39 CMasternodeSync:ProcessTick -- nTick 1813 nMnCount = 22
2016-10-21 18:13:40 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(88369f9624f53b3fe768a7b24f74feea2b763b6d5d6eba75cfccad8194140166, 1), scriptSig=)
2016-10-21 18:13:42 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-21 18:13:43 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting .. )
2016-10-21 18:13:44 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-21 18:13:46 CMasternodeSync:ProcessTick -- nTick 1819 nMnCount = 22
2016-10-21 18:13:49 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-21 18:13:50 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting .. )
2016-10-21 18:13:51 OverviewPage:PrivateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-21 18:13:52 CMasternodeSync:ProcessTick -- nTick 1825 nMnCount = 22
2016-10-21 18:13:52 CDarksendPool::SetState -- nState: 1, nStateNew: 7
2016-10-21 18:13:52 OverviewPage:PrivateSendStatus -- Last PrivateSend message: PrivateSend request incomplete: Signing timed out. Will retry...
2016-10-21 18:13:58 CMasternodeSync:ProcessTick -- nTick 1831 nMnCount = 22
 
Last edited:

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
Updated DashCore Testnet RPMs for Fedora, CentOS, RHEL to build 00667 (today's build): https://drive.google.com/open?id=18qwFkDKfyZhvecuR5kxiIKmPsjPZjFhRY0EsfHYbD7I

Links to the source RPMs, how to validate them (GPG signed), and even rebuild them is all contained in, or linked from, that document. Have a lovely Friday.

UPDATE: Build 00668 came in later... so I rebuilt for that as well. Turns out... same dash core source tarball. Lesson learned: Check SHA signature first. :)
 
Last edited:

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
v0.12.1.0-ed0a0d2 : it still has the signing timed-out probems which i mentioned in my previous post, preventing successfull mixing.
Hopefully UdjinM6 pull 1089 fixes this...

Here is a new example of the "PrivateSend request incomplete: Signing timed out." :

Code:
2016-10-23 10:40:43 CDarksendPool::UpdatePoolStateOnClient -- set nSessionID to 129362
2016-10-23 10:40:43 CDarksendPool::UpdatePoolStateOnClient -- entry accepted!
2016-10-23 10:40:43 CDarksendPool::SetState -- nState: 3, nStateNew: 2
2016-10-23 10:40:43 CDarksendPool::SetState -- nState: 2, nStateNew: 3
2016-10-23 10:40:43 CDarksendPool::SetState -- nState: 3, nStateNew: 4
2016-10-23 10:40:43 CDarksendPool::SignFinalTransaction -- CMutableTransaction(hash=c2610f3dcb, ver=1, vin.size=21, vout.size=21, nLockTime=0)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 34), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 35), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 36), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 37), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 38), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 41), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 42), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 43), scriptSig=)
    CTxIn(COutPoint(c7c823ae2b4a6661a1bb07c9cb05e88f4353105732ac6fa4ee18cae103c8bc49, 44), scriptSig=)
    CTxIn(COutPoint(67343182e4231b4a8e14bd77d945bb6cab76a4ec5d2c5aed85de9e8636d707ce, 34), scriptSig=)
    CTxIn(COutPoint(67343182e4231b4a8e14bd77d945bb6cab76a4ec5d2c5aed85de9e8636d707ce, 36), scriptSig=)
    CTxIn(COutPoint(67343182e4231b4a8e14bd77d945bb6cab76a4ec5d2c5aed85de9e8636d707ce, 37), scriptSig=)
    CTxIn(COutPoint(67343182e4231b4a8e14bd77d945bb6cab76a4ec5d2c5aed85de9e8636d707ce, 38), scriptSig=)
    CTxIn(COutPoint(67343182e4231b4a8e14bd77d945bb6cab76a4ec5d2c5aed85de9e8636d707ce, 39), scriptSig=)
    CTxIn(COutPoint(67343182e4231b4a8e14bd77d945bb6cab76a4ec5d2c5aed85de9e8636d707ce, 42), scriptSig=)
    CTxIn(COutPoint(67343182e4231b4a8e14bd77d945bb6cab76a4ec5d2c5aed85de9e8636d707ce, 44), scriptSig=)
    CTxIn(COutPoint(738ca133d3351c05d08a3bee6908bcc052e9ffd95848d1ff3c2c814ee1b806e7, 35), scriptSig=)
    CTxIn(COutPoint(738ca133d3351c05d08a3bee6908bcc052e9ffd95848d1ff3c2c814ee1b806e7, 37), scriptSig=)
    CTxIn(COutPoint(738ca133d3351c05d08a3bee6908bcc052e9ffd95848d1ff3c2c814ee1b806e7, 39), scriptSig=)
    CTxIn(COutPoint(738ca133d3351c05d08a3bee6908bcc052e9ffd95848d1ff3c2c814ee1b806e7, 41), scriptSig=)
    CTxIn(COutPoint(738ca133d3351c05d08a3bee6908bcc052e9ffd95848d1ff3c2c814ee1b806e7, 43), scriptSig=)
    CTxOut(nValue=100.00100000, scriptPubKey=76a91403986aa3235fa93195f22ef7)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914112276f85491da69584e1c10)
    CTxOut(nValue=100.00100000, scriptPubKey=76a91413aac6ff852587a59c42a6b1)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9141bb3bef734a026d030c36861)
    CTxOut(nValue=100.00100000, scriptPubKey=76a91420a2ff9851c4da77a98a2eca)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9142b8d772acfc27fce9cdb4b41)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9142de5f89eab7fa02d6a04e345)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9144705a1e3f6e42bbf772d95b7)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9144eec6db7717e473385cb4cc3)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9145410166796cfc0f1b254f0ea)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9145e5e1e793d7915cb55dc79df)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9147212eca1c48210f46344bf3b)
    CTxOut(nValue=100.00100000, scriptPubKey=76a9147491b837924fe608338ea27f)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914999e745b30c9fa7eda0bfed5)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914a0bebc6c425c9c5038450ba8)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914c05ac45d02eb01de21ae3c6f)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914de67b8a8e89c3290f1226c86)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914e0142d4daa09468eaf988770)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914e2a981203d9132207981a65f)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914e493f4db67f5e4519dc68e81)
    CTxOut(nValue=100.00100000, scriptPubKey=76a914e6c08abfd1bfd8a3d4cf771d)
2016-10-23 10:40:43 CDarksendPool::SetState -- nState: 4, nStateNew: 5
2016-10-23 10:40:44 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-23 10:40:48 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-23 10:40:49 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting .. )
2016-10-23 10:40:50 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-23 10:40:55 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-23 10:40:56 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting .. )
2016-10-23 10:40:57 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-23 10:41:01 CMasternodeMan::CheckAndRemove
2016-10-23 10:41:01 CMasternodeMan::CheckAndRemove -- Masternodes: 23, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 6, entries in Masternode list we asked for: 79, nDsqCount: 9
2016-10-23 10:41:01 Closing Masternode connection: peer=8, addr=52.45.246.154:19999
2016-10-23 10:41:01 CMasternodePayments::CheckAndRemove -- Votes: 110, Blocks: 16
2016-10-23 10:41:01 ProcessMessages: advertising address [2001:0:5ef5:79fb:3451:1266:2685:7461]:19999
2016-10-23 10:41:01 receive version message: /Dash Core:0.12.1/: version 70202, blocks=90517, us=217.122.139.158:50878, peer=20
2016-10-23 10:41:01 AdvertiseLocal: advertising address 217.122.139.158:19999
2016-10-23 10:41:02 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-23 10:41:03 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting .. )
2016-10-23 10:41:04 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ...
2016-10-23 10:41:07 ProcessMessages: advertising address [2001:0:5ef5:79fb:3451:1266:2685:7461]:19999
2016-10-23 10:41:07 receive version message: /Dash Core:0.12.1/: version 70202, blocks=90517, us=217.122.139.158:50882, peer=21
2016-10-23 10:41:07 AdvertiseLocal: advertising address 217.122.139.158:19999
2016-10-23 10:41:09 OverviewPage::privateSendStatus -- Last PrivateSend message: Found enough users, signing ( waiting . )
2016-10-23 10:41:09 CDarksendPool::SetState -- nState: 1, nStateNew: 7
2016-10-23 10:41:10 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend request incomplete: Signing timed out. Will retry...
2016-10-23 10:41:20 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend is idle.
 
Last edited:

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
also some strange behaviour from one of my wallets thats is trying to mix with regards to the amount it wants to mix : it goes all over the place .. from 883 to 1000 to 483 (wtf ?) to 1000




 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
Mixing is working again :)

Version : v0.12.1.0-565fa31

Well done UdjinM6
v0.12.1.0-565fa31
Indeed it is working now, fast, with in 90 mins, it was done 100%, 800 tDASH and 2 rounds,
BUT... mixing does not stop when amount limit is reached.
 

qwizzie

Well-known Member
Aug 6, 2014
1,804
955
183
v0.12.1.0-565fa31
Indeed it is working now, fast, with in 90 mins, it was done 100%, 800 tDASH and 2 rounds,
BUT... mixing does not stop when amount limit is reached.
yeah, you are right. I'm noticing it too now. I set the amount to 1000 / 8 rounds but it already reached 1100 and no sign its gonna stop mixing :

 
  • Like
Reactions: AjM

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
Test Build 00671 (v0.12.1.0-g565fa31) RPMs for Fedora, CentOS, RHEL
UPDATED
: Build 00672 associated to Dash Core git commit id of ed0a0d2 ...
https://drive.google.com/open?id=18qwFkDKfyZhvecuR5kxiIKmPsjPZjFhRY0EsfHYbD7I
Source package repository and how to build them is linked within as well.

Happy testing.
...

NOTE: Stable (not just testnet) Dash Core packages can be found there as well.
 
Last edited:
  • Like
Reactions: TaoOfSatoshi

UdjinM6

Official Dash Dev
Core Developer
Dash Core Group
May 20, 2014
3,639
3,537
1,183
@UdjinM6
Comment about this?
Not yet :) I'm focusing on making it mixing, not on stopping it :D
But speaking seriously, thanks for reporting but I'm not sure why it's happening, it shouldn't overshoot that much iirc.
Right now I'm wondering why nodes ban each other so often - that's a higher priority issue for me, will look at "non-stop" issue later.
 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
Not yet :) I'm focusing on making it mixing, not on stopping it :D
But speaking seriously, thanks for reporting but I'm not sure why it's happening, it shouldn't overshoot that much iirc.
Right now I'm wondering why nodes ban each other so often - that's a higher priority issue for me, will look at "non-stop" issue later.
Ok, main point is that you know this issue.
Good job so far anyways.:)
 

Balych

Active Member
Sep 12, 2015
365
211
113
Dash Address
Xba1ychX7CjgbRrCKE1LjHjT3jLUhcexs5
My mixing stuck at 22% with PrivateSend request incomplete: Collateral not valid.
but continue to use keys (already 3k used) and not create any TXs for 16+ hours
Code:
2016-10-24 14:19:11 CDarksendPool::DoAutomaticDenominating -- invalid collateral, recreating...
2016-10-24 14:19:11 keypool added key 15603, size=1001
2016-10-24 14:19:11 init message: Loading wallet... (1558.74 %)
2016-10-24 14:19:11 keypool reserve 14603
2016-10-24 14:19:11 keypool keep 14603
2016-10-24 14:19:11 CMasternodeMan::FindRandomNotInVec -- 5 enabled masternodes, 3 masternodes to choose from
2016-10-24 14:19:11 CDarksendPool::DoAutomaticDenominating -- attempt 0 connection to Masternode 45.55.31.68:19999
2016-10-24 14:19:11 CDarksendPool::DoAutomaticDenominating -- connected, addr=45.55.31.68:19999
2016-10-24 14:19:11 CDarksendPool::DoAutomaticDenominating -- connected, sending DSACCEPT, nSessionDenom: 1 (100.001)
2016-10-24 14:19:12 OverviewPage::privateSendStatus -- Last PrivateSend message: Mixing in progress...
2016-10-24 14:19:12 CDarksendPool::SetState -- nState: 3, nStateNew: 1
2016-10-24 14:19:12 CDarksendPool::SetState -- nState: 1, nStateNew: 7
2016-10-24 14:19:13 OverviewPage::privateSendStatus -- Last PrivateSend message: PrivateSend request incomplete: Collateral not valid. Will retry...
 
  • Like
Reactions: qwizzie and UdjinM6

eduffield

Core Developer
Mar 9, 2014
1,084
5,323
183
Happy Monday!

We are looking to move onto the next stage of testnet, but we need some active participation from the masternodes operators currently running active testnet daemons in order to test the code we are working on. Our test network is currently about 5% upgraded, we need at least 65% to force the upgrade. To do the update we will fork testnet and don’t want to leave clients broken on the wrong fork.

To smoothly update the network, we ask anyone running an active masternode to follow the steps below. If you have a masternode, please update, this would greatly help our efforts!

How to upgrade:
  • Update dashd
  • Update sentinel
  • Restart masternode
  • Make sure to enable crontab (described below)
Latest builds (v0.12.1.0-b9bd116) of v0.12.1.x branch
Linux --> https://dashpay.atlassian.net/build...ccessful/artifact/JOB1/gitian-linux-dash-dist
Windows --> https://dashpay.atlassian.net/build...uccessful/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/build...uccessful/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/build...build-latestSuccessful/gitian-RPi2-dash-dist/

Sentinel Code
We’re currently using nmarley’s repository for Sentinel, we will merge this to dashpay/sentinel soon:
https://github.com/nmarley/sentinel.git

Crontab Entry
*/2 * * * * cd /home/YOURUSERNAME/.dashcore/sentinel && venv/bin/python bin/sentinel.py >/dev/null 2>&1

Full Installation Instructions:
https://gist.github.com/moocowmoo/66049a781f8eaa1021306072f19363d4

Github Bug Tracker Links
Find a bug, issue or think we should improve something specific? Please use the issue tracker from Github here:

https://github.com/dashpay/dash/issues
https://github.com/nmarley/sentinel/issues

It’s well worth creating a github account if you don’t have one. Thanks!

edit by admin: updated crontab
 
Last edited by a moderator:
Status
Not open for further replies.