Electrum Wallet Guides

flare said:
Sorry, no - had to focus on 12.1 the last weeks. We'll follow up on that one next week.
Click to expand...
Well crap. I just wiped and set my Trezor up for realz and moved all my DASH over. Definitely bigger fish to fry, understood.

Will this be built into electrum-dash? Or still planning to do this with a python script? Or something else entirely?
 
camosoul said:
Well crap. I just wiped and set my Trezor up for realz and moved all my DASH over. Definitely bigger fish to fry, understood.

Will this be built into electrum-dash? Or still planning to do this with a python script? Or something else entirely?
Click to expand...

Both options will be available i think, Python script already works very good --> https://github.com/chaeplin/dashmnb

The script is even capable to harvest the rewards from the nodes without breaking it (coin control)
 
flare said:
Both options will be available i think, Python script already works very good --> https://github.com/chaeplin/dashmnb

The script is even capable to harvest the rewards from the nodes without breaking it (coin control)
Click to expand...
I was just going to ask that...

Will the coin control features in the script be added to electrum-dash?

When will electrum-dash query DAPI/MNs for data instead of centralized servers?

Have to figure out how to force 16.04 to upgrade python above 2.7....
Code: 
anon@workstation:~$ sudo apt-get install python3
[sudo] password for anon:
Reading package lists... Done
Building dependency tree     
Reading state information... Done
python3 is already the newest version (3.5.1-3).
0 upgraded, 0 newly installed, 0 to remove and 121 not upgraded.
anon@workstation:~$ python --version
Python 2.7.12
anon@workstation:~$
Derp...
 
Last edited:
I got it to work, listed a bunch of addresses... Not sure how to make it do anything else yet... Seems to list more addresses than it should. The rest of the documentation on the git page leaves me hanging...
 
Last edited:
camosoul said:
I got it to work, listed a bunch of addresses... Not sure how to make it do anything else yet... Seems to list more addresses than it should.
Click to expand...
camosoul said:
@chaeplin

https://github.com/chaeplin/dashmnb...tnetpy-to-dashlibconfigpy-and-edit-parameters

1. Move dashlib/config.sample.mainnet[testnet].py to dashlib/config.py and edit parameters
- for testnet dashlib/config.sample.mainnet.py to dashlib/config.py
- for mainet dashlib/config.mainet.testnet.py to dashlib/config.py

Doc needs editing... :p

I can figure out what it meant, but some people might not...
Click to expand...

Updated, Thank you.

change no of max_gab. default is 20.
Code: 
# config.py
max_gab = 20     # number of keys used on mn config
 
camosoul said:
The rest of the documentation on the git page leaves me hanging...
Click to expand...
From this point on, I'm kinda lost...
chaeplin said:
Code: 
# config.py
max_gab = 20     # number of keys used on mn config
Click to expand...
Ah, so it's just a static number off the bip32 chain.

I'll see if I can figure out how to broadcast an MN start later, too tired now... Is it just checking the log for a true closed-loop MN activation notification? I really don't want to set up my ssh with keys...

I really hope a "start masternode" button gets added to electrum-dash... If IIRC, wasn't there an earlier version that had this, and it was removed because the protocal wasn't sorted or even certain to be included?

As cool as this script is, it's a real pain in the ass... The numberpad thing was like woah... I'm not knocking the work. I like doing things in console, and it's definitely a clever tool. But, reality is that most people are not going to do this. It's got 5x more dependencies and pre-requisites than the official client! Not to mention the versioning mess that Python has created. Gentoo is used to upstream derpage and has a visible way to wrangle it as the user desires... Not so visible or convenient in in Debian derivatives. Sure, it slotted, but I still facepalm...

P.S., @moocowmoo the forum edit button doesn't update stored variable content anymore... It's a real pain. Repeated edits require a refresh or the previous edit is lost.
 
Last edited:
Weird... I can't get the Trezor to work with electrum-dash on any other machines... It asks for the PIN, then instead of the confirm screen, it jumps to showing the wallet history, with only 3 VINs. It won't work at all with the wallet.trezor.io site... I looked for all the docs I could find, checking for dependencies... lsusb shows the Trezor. Comes and goes when plugged/unplugged. On the wallet.trezor.io site, it just sits there telling me to plug it in. Which I do and nothing happens. If I unplug it I get an error saying HID was interrupted... I can sit there and wait forever, nothing happens until I unplug it and get the HID error.

I can take it back to the original machine and it works flawlessly.

All the same OS, 16.04...

I'm guessing I'm missing a dependency, but I can't figure out what...

I'm trying to run it without any official dashcore installation. It's just electrum-dash and nothing else. Is there, perhaps, some dependency overlap that is unnoticed for people who are using the official dashcore, and it's dependencies, on the same machine?

Why should anyone care about this?

If you go to the downloads page and grab the electrum client and install it on a fresh 16.04 with all updates; it doesn't work. Dependencies listed here: https://dashpay.atlassian.net/wiki/display/DOC/Install has no effect. Identical symptoms persist.
 
Last edited:
I tried Windows on the exact same machines, and the Windows electrum-dash works. So, it's not hardware or BIOS settings...

It's definitely a software issue, and probably a missing dependency. But, I can't identify it.

For this who with to run an electrum-only life with Hardware Wallets, this is a problem.

Can we get a solid list of dependencies for fresh/clean 16.04 installs?
 
Welp, now electrum-dash on Windows has spontaneously quit working.

I'm down to one Linux machine on which electrum-dash still works. Every other electrum-dash installation has quit working without any indication why, or has never worked.

wallet.trezor.io continues to work perfectly in all instances.
 
Windows client(s) are now asking me to install github.com/trezor/python-trezor. Obviously not going to happen.

Since I can't get any useful output from Windows, I decided to go back to playing with the Linux clients...

After doing the PIN, it shows 3 TXes, all 3 unverified.

Oddly...

It shows the 1st VIN on the main account. It then shows one of the VINs on the second account. It then shows the last VIN on the main account. The main account has only two VINs. This is chronologically accurate, with the exception that a bunch of the second account's VINs are missing.

If you go to the addresses tab, it shows the second account as "pending." Apparently it's not bothering to chase down the rest of the BIP32 chain. Think it's related to the "pending" thing, because we know it checks for there actually being a payment on the top address before allowing the "account" creation to occur. It does recognize the first VIN, but that's it...

I re-iterate; works flawlessly on wallet.trezor.io - Trezor isn't busted. Obviously not an interfacing problem.

Noticed the new servers... and the .onion server. Nice touch. I selected it manually and it claims to be synching, but as with all other server selections, it never actually counts out the 2nd account's VINs, and leaves all 3 that it shows as "unverified." Not sure what's causing that, but I'm pretty sure:

1) the "unverified" status on all VINs
2) the fact that it's not chasing the rest of account 2's BIP32 chain
3) is chasing the main account's BIP32 chain
4) calling account 2 "pending account"

Are all the same root cause.
 
Last edited:
Just launched it for the 10-billionth time and it loaded everything...

Sumthin's flaky... But it worked... Was it server related? Seems someone is working on that end of things as I fool around.
 
It's really hard to troubleshoot when you do the exact same thing over and over, and never get the same result twice...

There is an essential piece missing, which is kinda obvious. python-trezor needs to be installed. But, sometimes the hidapi build succeeds, sometimes it fails. There seems to be no reason because the dependency is present. It claims the file isn't there, and it very much is there.
Code: 
user@hostname:~$ sudo -H pip install trezor
Collecting trezor
Requirement already satisfied: ecdsa>=0.9 in /usr/local/lib/python2.7/dist-packages (from trezor)
Requirement already satisfied: setuptools>=19.0 in /usr/lib/python2.7/dist-packages (from trezor)
Collecting hidapi>=0.7.99 (from trezor)
  Using cached hidapi-0.7.99.post20.tar.gz
Requirement already satisfied: protobuf>=2.6.1 in /usr/local/lib/python2.7/dist-packages (from trezor)
Requirement already satisfied: mnemonic>=0.8 in /usr/local/lib/python2.7/dist-packages (from trezor)
Requirement already satisfied: six>=1.9 in /usr/local/lib/python2.7/dist-packages (from protobuf>=2.6.1->trezor)
Requirement already satisfied: pbkdf2 in /usr/local/lib/python2.7/dist-packages (from mnemonic>=0.8->trezor)
Building wheels for collected packages: hidapi
  Running setup.py bdist_wheel for hidapi ... error
  Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-Uj9H6u/hidapi/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmpNHBN82pip-wheel- --python-tag cp27:
  running bdist_wheel
  running build
  running build_ext
  cythoning hid.pyx to hid.c
  building 'hid' extension
  creating build
  creating build/temp.linux-x86_64-2.7
  creating build/temp.linux-x86_64-2.7/hidapi
  creating build/temp.linux-x86_64-2.7/hidapi/libusb
  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Ihidapi/hidapi -I/usr/include/libusb-1.0 -I/usr/include/python2.7 -c hid.c -o build/temp.linux-x86_64-2.7/hid.o
  hid.c: In function ‘__pyx_pf_3hid_6device_open’:
  hid.c:1633:45: warning: passing argument 1 of ‘PyUnicodeUCS4_AsWideChar’ from incompatible pointer type [-Wincompatible-pointer-types]
         __pyx_v_result = PyUnicode_AsWideChar(__pyx_v_serial_number, __pyx_v_cserial_number, __pyx_v_serial_len);
                                               ^
  In file included from /usr/include/python2.7/Python.h:85:0,
                   from hid.c:4:
  /usr/include/python2.7/unicodeobject.h:246:31: note: expected ‘PyUnicodeObject * {aka struct <anonymous> *}’ but argument is of type ‘PyObject * {aka struct _object *}’
   # define PyUnicode_AsWideChar PyUnicodeUCS4_AsWideChar
                                 ^
  /usr/include/python2.7/unicodeobject.h:591:24: note: in expansion of macro ‘PyUnicode_AsWideChar’
   PyAPI_FUNC(Py_ssize_t) PyUnicode_AsWideChar(
                          ^
  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Ihidapi/hidapi -I/usr/include/libusb-1.0 -I/usr/include/python2.7 -c hidapi/libusb/hid.c -o build/temp.linux-x86_64-2.7/hidapi/libusb/hid.o
  hidapi/libusb/hid.c:47:20: fatal error: libusb.h: No such file or directory
  compilation terminated.
  error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
 
  ----------------------------------------
  Failed building wheel for hidapi
  Running setup.py clean for hidapi
Failed to build hidapi
Installing collected packages: hidapi, trezor
  Running setup.py install for hidapi ... error
    Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-Uj9H6u/hidapi/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-FQaHAF-record/install-record.txt --single-version-externally-managed --compile:
    running install
    running build
    running build_ext
    skipping 'hid.c' Cython extension (up-to-date)
    building 'hid' extension
    creating build
    creating build/temp.linux-x86_64-2.7
    creating build/temp.linux-x86_64-2.7/hidapi
    creating build/temp.linux-x86_64-2.7/hidapi/libusb
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Ihidapi/hidapi -I/usr/include/libusb-1.0 -I/usr/include/python2.7 -c hid.c -o build/temp.linux-x86_64-2.7/hid.o
    hid.c: In function ‘__pyx_pf_3hid_6device_open’:
    hid.c:1633:45: warning: passing argument 1 of ‘PyUnicodeUCS4_AsWideChar’ from incompatible pointer type [-Wincompatible-pointer-types]
           __pyx_v_result = PyUnicode_AsWideChar(__pyx_v_serial_number, __pyx_v_cserial_number, __pyx_v_serial_len);
                                                 ^
    In file included from /usr/include/python2.7/Python.h:85:0,
                     from hid.c:4:
    /usr/include/python2.7/unicodeobject.h:246:31: note: expected ‘PyUnicodeObject * {aka struct <anonymous> *}’ but argument is of type ‘PyObject * {aka struct _object *}’
     # define PyUnicode_AsWideChar PyUnicodeUCS4_AsWideChar
                                   ^
    /usr/include/python2.7/unicodeobject.h:591:24: note: in expansion of macro ‘PyUnicode_AsWideChar’
     PyAPI_FUNC(Py_ssize_t) PyUnicode_AsWideChar(
                            ^
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Ihidapi/hidapi -I/usr/include/libusb-1.0 -I/usr/include/python2.7 -c hidapi/libusb/hid.c -o build/temp.linux-x86_64-2.7/hidapi/libusb/hid.o
    hidapi/libusb/hid.c:47:20: fatal error: libusb.h: No such file or directory
    compilation terminated.
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
 
    ----------------------------------------
Command "/usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-Uj9H6u/hidapi/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-FQaHAF-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-Uj9H6u/hidapi/
user@hostname:~$
If one re-installs the OS, installs all updates, and does this, over and over and over again, eventually, it spontaneously works. But, usually, it gives this false failure message declaring a missing libusb that is, in fact, not missing.

The symptoms I've observed so far are a pin entry screen that looks different and doesn't say "ultimate" when reaching the 8th and 9th chars. It will then proceed to show the goofed up VINs as previously described.

When this build succeeds, for absolutely no reason, then everything works flawlessly.

It's pretty obvious why this build needs to succeed. But, what causes it to lie and fail to build due to falsely reporting a lack of dependency which is in fact present, for no reason at all, and sometimes succeed, under identical circumstances, I cannot figure out.
Code: 
fatal error: libusb.h: No such file or directory
This part is simply a lie. I even made a script so I knew I wasn't goofing up. Sometimes it works, sometimes it doesn't. When it doesn't there's nothing that can ever be done but to re-install the OS and try again. Run same script. Keep doing it over and over until it stops lying, gives up, and works.
 
Last edited:
Seems to be repeating this: https://github.com/dashpay/electrum-dash/issues/47

I told apt to install libusb-1.0, which it told me was already latest version and did nothing. But, now that doesn't fail anymore. So, apt clearly did do something, and then lied... The file is still in /usr/includes like it always has been, but now, for some unknown reason, the hidapi build can find it.

The very next step fails...

Code: 
/usr/bin/ld: cannot find -ludev
Code: 
xubuntu@xubuntu:/usr/include$ sudo apt-get install libudev1
Reading package lists... Done
Building dependency tree      
Reading state information... Done
libudev1 is already the newest version (229-4ubuntu4).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
This is stupid...

At least the libusb-1.0 that's already there but isn't problem is solved...
 
Not sure which of those was the ticket, but hidapi built. Thanks!

The pin screen looks like the others that work, which none of that stuff was installed but they built...

But, it's still doing the weird "pending account" and the random TXes/VINs it shows are all unconfirmed...

UPDATE: Seems this fixes itself if you just let it sit for half an hour. Balances showing properly now.
 
Last edited:
So, yeah. It works repeatably now.

The Electrum page on Atlassian needs to be updated to show all these pre-requisites. Including that which satoshi labs fails to document on their own stuffs...

If someone just downloads it from the dash.org/downloads page, they're going to have no idea the wild ride they have to go on to make it work. Most of it has nothing to do with the electrum-dash client itself (which is pretty damn cool @chaeplin and @flare ). It's getting the Trezor to communicate which is the pain.
 
Last edited:
You must log in or register to reply here.
Back
Top