PyQt5 for 32 bit / ubuntu14.04 / cold storage

[samspaces]

So, if you happen to have electrum cold storage, you might run into this issue when you want to make an offline system to restore from seed phrases. PyQt5 seems impossible to get installed on older 32 bit systems / ubuntu distros and without it, electrum won't work with a gui.

To spare anyone reading this the trouble of trying to python/pip/pip3/apt-get/whatever PyQt5, just download anaconda3-2018.12-linux-x86.sh from the anaconda repo, chmod +x it, and install it on your system. Open a new terminal and use python3.7 ./run electrum. Disconnect the machine and it should work fine.

[1714799019]

1714799019

[NotATether]

There is in fact a PyQt5 for 32-bit linux: python3-pyqt5 binary package in Ubuntu Trusty i386. It exists in the other Ubuntu versions, just replace "trusty" in the URL with the version's codename.

The package is usually named python3-pyqt5 in Ubuntu/debian, and python3-qt5 in Fedora/centos. i386 builds are provided unless the distribution in question is 64-bit only, like CentOS 7, and they have the same package names as their amd64 counterparts, so apt-get install python3-pyqt5 or dnf install python3-qt5 is enough to install 32-bit PyQT5.

You also need to install libsecp256k1 package to get Electrum working.

[pooya87]

i would worry about a lot more when using a 32-bit system if i were you. all of the projects are developed on 64-bit machines and only a handful of them also test their code for 32-bit machines and some things may break if the developer hadn't spend a lot of time thinking ahead.

You also need to install libsecp256k1 package to get Electrum working.

didn't they include all required packages in their releases from 3.3.4 versions?

[NotATether]

You also need to install libsecp256k1 package to get Electrum working.

didn't they include all required packages in their releases from 3.3.4 versions?

I believe the python bindings for libsecp256k1 are bundled with electrum's portable python release, but those need the associated C library to work and that has to be installed via package manager.

[samspaces]

i would worry about a lot more when using a 32-bit system if i were you. all of the projects are developed on 64-bit machines and only a handful of them also test their code for 32-bit machines and some things may break if the developer hadn't spend a lot of time thinking ahead.

You also need to install libsecp256k1 package to get Electrum working.

didn't they include all required packages in their releases from 3.3.4 versions?

@pooya87 Are you saying that restoring a wallet on a 32 bit machine can break sending that transaction from a 64 bit machine, or am I being paranoid here? I've had no problems with that otherwise, but perhaps for multisig restoration it is different?

Electrum-3.2.2 works without libsecp256k1 but it falls back to python-ecdsa. Is that something that could break things too?

[NotATether]

@pooya87 Are you saying that restoring a wallet on a 32 bit machine can break sending that transaction from a 64 bit machine, or am I being paranoid here? I've had no problems with that otherwise, but perhaps for multisig restoration it is different?

No that doesn't happen because Python is an architecture-independent language which means that code you write for Python works the same way on all platforms (x86/x64), just by installing the Python interpreter corresponding to your architecture. So Electrum on 32-bit Python works exactly the same way as Electrum on 64-bit python, they can read data generated by the other version.

Electrum-3.2.2 works without libsecp256k1 but it falls back to python-ecdsa. Is that something that could break things too?

No. Those are just backends for Electrum's cryptographic functions and, these backends are not directly exposed to end users so there's nothing you need to worry about.

[samspaces]

Is it practical? I never use anaconda, but that means you need to install anaconda on device you use as cold storage which increases the complexity.

Started the thread with restoration in mind, not creation of cold storage. The anaconda installation seems to save hours of time figuring out python / pip errors, which you will get for sure on these older systems. Since you need all kinds of software, my 'method' which is far from a cypherpunk way, I'm sure, is to wipe a disk, clean (encrypted) OS install, get required software and then disconnect that disk forever, before restoring from seeds. You could then create a new wallet if you wanted to, since it's offline forever. If I'm missing an obvious pitfall here, please let me know.

@NotATether, thanks for the explanation, appreciate it.

[pooya87]

No that doesn't happen because Python is an architecture-independent language which means that code you write for Python works the same way on all platforms (x86/x64), just by installing the Python interpreter corresponding to your architecture. So Electrum on 32-bit Python works exactly the same way as Electrum on 64-bit python, they can read data generated by the other version.

i'm not so familiar with python so you may be right. but the bugs i have in mind are't language dependent. for instance in c# which is not as simplified a language as python but it also isn't really architecture-dependent, you can still write code that fails on a 32-bit machine. a simple example that come to mind is using IntPtr.
so if i were to use the projects i use on a 32-bit machine i would like to know whether they and their dependencies are thoroughly tested on 32-bit machines since devs write code and test it on 64-bit machines nowadays.

[NotATether]

No that doesn't happen because Python is an architecture-independent language which means that code you write for Python works the same way on all platforms (x86/x64), just by installing the Python interpreter corresponding to your architecture. So Electrum on 32-bit Python works exactly the same way as Electrum on 64-bit python, they can read data generated by the other version.

i'm not so familiar with python so you may be right. but the bugs i have in mind are't language dependent. for instance in c# which is not as simplified a language as python but it also isn't really architecture-dependent, you can still write code that fails on a 32-bit machine. a simple example that come to mind is using IntPtr.
so if i were to use the projects i use on a 32-bit machine i would like to know whether they and their dependencies are thoroughly tested on 32-bit machines since devs write code and test it on 64-bit machines nowadays.

As far as I know, the only part of Python where different architectures can have different behaviors is if you load a C library directly with Python code (which is pretty much the purpose of IntPtr in C# as well), and by extension using any Python library that contained compiled C code, like numpy, so those have to be tested on all arch's they support.

Pure python programs however run the same on both architectures.

[pooya87]

if you load a C library directly with Python code (which is pretty much the purpose of IntPtr in C# as well)

IntPtr is just a pointer to an object in memory and can be used for many different things not just to load another library. and it was just an example off the top of my head. there are other things to consider that involved cryptography and usually are in optimized code that are written and compiled separately for different architectures.