dashmnb confusion(s)

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
so, this:
Code:
    ---> getting unused addresses of bip32 path
The chain is getting awfully long...

when running as:
Code:
cd dashmnb/
. venv3/bin/activate
torify python bin/dashmnb.py -b
It pretty much always times out because there are so many requests.

It's become impossible to obtain payments.

I know I should be running my own dashd for these reasons:
Code:
    - dashmnb connects remote service using ssl
    - However `remote dashd/rpc service` use nginx(web server) as frontend

[https://github.com/chaeplin/dash-ticker/tree/master/web/nginx](https://github.com/chaeplin/dash-ticker/tree/master/web/nginx) has frontend configuration

    - As nginx(web server) leave a log containning ip address of user like following
``` 
10.10.10.1 - dashmnb [18/Feb/2017:06:13:33 +0000] "POST / HTTP/1.1" 200 227 "-" "AuthServiceProxy/0.1" "-" [-] [-] []
10.10.10.1 - dashmnb [18/Feb/2017:06:13:39 +0000] "POST / HTTP/1.1" 200 227 "-" "AuthServiceProxy/0.1" "-" [-] [-] []
10.10.10.1 - dashmnb [18/Feb/2017:06:13:44 +0000] "POST / HTTP/1.1" 200 92 "-" "AuthServiceProxy/0.1" "-" [-] [-] []
10.10.10.1 - dashmnb [18/Feb/2017:06:13:54 +0000] "POST / HTTP/1.1" 200 359050 "-" "AuthServiceProxy/0.1" "-" [-] [-] []
```
    - The ip address is `privacy concern`
So, this:
Code:
    - copy dashlib/config.sample.mainnet.py to run own dashd/Dash-QT
This is where it goes sideways..

When reading dashmnb/config.sample.mainnet.py I see things that look pretty dangerous, and the language barrier does not clarify sufficient for me to figure out what I need, what needs to be changed, what I can eliminate for my intended use model... Some things look like they are totally un-useful for my purpose and could be eliminated... But I don't want to end up with dashd listening on an open port with this "xxxx" username and password... Bad Things(tm) would happen.

I just want to have dashmnb pull this data from local (127.0.0.1) dashd on the same machine; safely.

Yes, I already did -reindex.
 
Last edited:

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
@chaeplin
I gave up and restored my original config, and it hangs on this, even when not torified.
Code:
    ---> getting unused addresses of bip32 path
Just sits there forever...
Did something bork in the recent update? It was just a fee change, so I don't see how it's related at all...
 

chaeplin

Active Member
Core Developer
Mar 29, 2014
749
356
133
I will test local dashd rpc(127.0.0.1) again as 12.2 has very fast sync.
 

chaeplin

Active Member
Core Developer
Mar 29, 2014
749
356
133
I have tested local rpc, it's way faster on check `bip32 unused address` than remote service.

First use https://github.com/chaeplin/dashmnb/blob/master/dash.conf.sample for dash.conf

sample dash.conf
Code:
rpcuser=xxxxx
rpcpassword=xxxxx
rpcallowip=127.0.0.1
rpcbind=127.0.0.1
rpcport=9998
server=1
daemon=1
logips=1
logtimestamps=1 
addressindex=1
spentindex=1
timestampindex=1
txindex=1


move/rename config.sample.mainnet.py to config.py
https://github.com/chaeplin/dashmnb/blob/master/dashlib/config.sample.mainnet.py

edit these lines
Code:
account_no = 1
rpcuser = 'xxxx'
rpcpassword = 'xxxxx'
max_gab = 5
run dashd with -reindex
 

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
I have tested local rpc, it's way faster on check `bip32 unused address` than remote service.
I expect it to be... Which is the whole reason I embarked upon this journey.
But, it just doesn't work.
I'll start over from scratch.

I'm worried that even if it does work, this breaks tor and defeats the whole point.
 

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
Well, progress...

I compared the config.py files (old one that wouldn't work, and the new one I just made), and they're identical. No idea why it works (sorta) with one and not the other...

Now it does "checking syncing status" with a spinner...

Does it ever stop?

EDIT: yes, eventually...
 

chaeplin

Active Member
Core Developer
Mar 29, 2014
749
356
133
I expect it to be... Which is the whole reason I embarked upon this journey.
But, it just doesn't work.
I'll start over from scratch.

I'm worried that even if it does work, this breaks tor and defeats the whole point.
following lines are needed
Code:
addressindex=1
spentindex=1
txindex=1
 

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
It seems to be working now, bu it still spends a loonnngggg time on the
Code:
    ---> getting unused addresses of bip32 path
There's only a few hundreds addresses used... I don't understand why it takes so long... top shows python hammering the cpu to 100% and it just stays there...

7 minutes and counting.

EDIT: 9 minutes

EDIT: 11:32 and it finally got on with things.

This is way out of line, even for my wimpy cpu... Sumthin' ain't right.
 
Last edited:

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
...and it totally breaks tor. Attempting to use "torify" on it (which is sloppy to begin with), breaks all local connect attempts.

Feature request incoming... :p
 
Last edited:

chaeplin

Active Member
Core Developer
Mar 29, 2014
749
356
133
It seems to be working now, bu it still spends a loonnngggg time on the
Code:
    ---> getting unused addresses of bip32 path
There's only a few hundreds addresses used... I don't understand why it takes so long... top shows python hammering the cpu to 100% and it just stays there...

7 minutes and counting.

EDIT: 9 minutes

EDIT: 11:32 and it finally got on with things.

This is way out of line, even for my wimpy cpu... Sumthin' ain't right.
looks like you have many txs(!).

chaage this line to like 100
https://github.com/chaeplin/dashmnb/blob/master/dashlib/mnb_bip32.py#L19
Code:
checking_gap = 100
 

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
looks like you have many txs(!).

chaage this line to like 100
https://github.com/chaeplin/dashmnb/blob/master/dashlib/mnb_bip32.py#L19
Code:
checking_gap = 100
Only a few hundred... This cpu cranks out bip32 derivatives at a rate of several dozen per second... No, not impressive, but I can't see a reason for it to take so long... 11:32 is waayyy more addresses than I'm using... This wallet is only a week old. I have some MNs, but not that many!

I changed to 100 as a workaround, but it'd be nice to see what's going on...

EDIT: yeah, skipping ahead by an order of magnitude went waayyy faster! Apparently, the system thinks more addresses are in use than actually are... Maybe something is causing a false positive on address use checking?
 
Last edited: