• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

dashmnb confusion(s)

camosoul

Well-known member
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:
@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...
 
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
 
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.
 
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...
 
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
 
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:
...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:
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
 
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:
Back
Top