[But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.]

Armory is released under the Affero GPL v3 software license.

According to the GPL FAQ:

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

(emphasis mine)

IOW, it seems likely that software which uses armoryd's RPC interface is probably a separate program which can have a different license or even be closed source, but short of some new court decision, it's not entirely clear. If such software isn't considered a separate program, then it must also be licensed under Affero GPL v3. Furthermore, if such software is accessed over the Internet (e.g. an armoryd-based block explorer, storefront, etc.), then the entire source code must be made available for download (as per the Affero GPL).

So, I'd like to make a small request: could this be clarified one way or the other, perhaps right in the armoryd.py file itself?

I just happened to come across a "factoid" (actually MZ pointed it out) that seems inaccurate to me:

There are several different types of Bitcoin clients. Hybrid server-assisted clients like Electrum get a lot of their network information from centralized servers, but they also check the server's results using blockchain header data. This is perhaps somewhat more secure than either server-assisted clients or header-only clients.

That last clause "or header-only clients" is what seems inaccurate to me. Could someone point me to a rationale for that clause, or alternatively recommend how we could get it removed?

I find it a little bit concerning because it might encourage Electrum's use over a P2P SPV client, and AFAIK there's no tx-validation-security reason to do this. There may be a reason to prefer P2P SPV clients when it comes to privacy issues vs Electrum/Stratum.

[https://onedrive.live.com/redir?resid=584F122BA17116EE%21313]

This is a first attempt at creating a compatibility matrix for deterministic wallets. In other words, it tries to answer the questions:

When using two different wallet apps from different devs, will I have the same list of addresses and the same balance if I:

• use the same mnemonic sentence (seed) in both?
• export a master private key from one into the other?
• export a master public key from one into the other (creating a watch-only wallet)?

For now, it's an Excel file available for viewing or downloading here: https://onedrive.live.com/redir?resid=584F122BA17116EE%21313.

It has four tabs. The first, "Details", lists out (hopefully) all relevant details of various wallets that might make them compatible or not with one another.

The next three are calculated from the first; they try to answer the three corresponding questions above. (Sorry, but Excel Online doesn't render vertical text correctly, so they look a bit ugly online. Either download a local file, or hover over the wallet names in the first row to read them; they're in the same order as the wallet names in the first column.)

I'm definitely interested if anyone has any input; in particular I'm not at all confident that the Details tab has everything correct, and it's probably missing some deterministic wallets that I'm unaware of. If there are any wallet devs who could take a quick look at their wallet on the first tab to see if I got anything wrong, that'd be great!

I'm also not sure that the list of requirements (spelled out on the three right-most tabs) is sufficient to guarantee compatibility.

(Also: don't rely on this without doing your own testing first!)

I'm not sure where, if anywhere, this is headed, but it'd be nice to turn this into a set of web-based tables on GitHub, perhaps something jekyll-based like this. Again, input is most welcome.

I have a favor to ask of someone who already has MultiBit HD built and installed.

I'd like to get a copy of a newly created & empty wallet file. I could d/l the JDK and build it myself.... I'm just being lazy and hopeful that someone might take a few minutes to help me out.

If anyone's willing, specifically I'd like a:

• Newly created wallet,
• this password used to protect it: btcr-test-password
• nothing else added to it or changed.

FYI this is so that I can test bitcoinj support I recently added to btcrecover.

If anyone's willing, please email the wallet file to cenrug-mbhd@yahoo.com. I'll lock this thread if I get any takers.

Thanks!

n/m

This is an install script for Armory on Ubuntu. It's nothing real special, but I needed it for myself (for Travis CI) and thought I may as well share.

It locates and automatically downloads, verifies, and installs the latest stable version of Armory plus all required prerequisites. Please note that on Ubuntu Server edition, there are a lot of GUI-related prerequisites that while technically required (and installed by this script), aren't required in practice, so you may prefer not to use this script in that case.

Code:

#!/bin/bash

set -e

DOWNLOADS="`curl -fsS --retry 10 https://s3.amazonaws.com/bitcoinarmory-media/announce.txt | awk '/^downloads/{print $2}'`"
echo "$DOWNLOADS" | grep -q '^https://' || { echo "Can't find Armory downloads URL"; exit 1; }

uname -m | grep -q '64$' && BITS=64 || BITS=32
LATEST="`curl -fsS --retry 10 \"$DOWNLOADS\" | grep "^Armory [0-9.]* Ubuntu [0-9.,]*\`lsb_release -rs\`[0-9.,]* $BITS " | sort -k 2V | tail -1 | awk '{print $6}'`"
echo "$LATEST" | grep -q '^https://' || { echo "Can't find latest Armory download URL"; exit 1; }

curl -fsS --retry 10 -o '/tmp/armory.deb' "$LATEST"

sudo apt-get update
sudo apt-get install dpkg-sig gdebi-core

gpg -q --keyserver keyserver.ubuntu.com --recv-keys 98832223
dpkg-sig --verify /tmp/armory.deb | grep -q 'GOODSIG.*821F122936BDD565366AC36A4AB16AEA98832223' || { echo "Signature verification failed"; exit 1; }

sudo gdebi /tmp/armory.deb
rm /tmp/armory.deb

Here's a version for unattended installation (the one I use for Travis CI, more or less):

Code:

#!/bin/bash

set -e

DOWNLOADS="`curl -fsS --retry 10 https://s3.amazonaws.com/bitcoinarmory-media/announce.txt | awk '/^downloads/{print $2}'`"
echo "$DOWNLOADS" | grep -q '^https://' || { echo "Can't find Armory downloads URL"; exit 1; }

uname -m | grep -q '64$' && BITS=64 || BITS=32
LATEST="`curl -fsS --retry 10 \"$DOWNLOADS\" | grep "^Armory [0-9.]* Ubuntu [0-9.,]*\`lsb_release -rs\`[0-9.,]* $BITS " | sort -k 2V | tail -1 | awk '{print $6}'`"
echo "$LATEST" | grep -q '^https://' || { echo "Can't find latest Armory download URL"; exit 1; }

curl -fsS --retry 10 -o '/tmp/armory.deb' "$LATEST"

sudo apt-get -q update
sudo apt-get -yq install dpkg-sig gdebi-core

gpg -q --keyserver keyserver.ubuntu.com --recv-keys 98832223
dpkg-sig --verify /tmp/armory.deb | grep -q 'GOODSIG.*821F122936BDD565366AC36A4AB16AEA98832223' || { echo "Signature verification failed"; exit 1; }

sudo gdebi -nq /tmp/armory.deb
rm /tmp/armory.deb

It's not as thorough as the built-in secure downloader because it only checks the signatures of the very last download (the install .deb file itself), but it was good enough for my purposes.

Hi, all.

Every so often, there's a new "which wallet is best" thread that appears. The correct answer is almost always "it depends"... there are a lot of options out there, and the best wallet for one person may not be the best for someone else.

It can be particularly confusing for beginners. With this is mind, I've compiled a very simple table which I've put up online here:

http://gurnec.github.io/btc-wallet-comparison/

There's not much to it so far... just 5 wallets listed, and a handful of columns that I thought would be most important for beginners. Note that I'm intentionally leaving out more complicated features (m of n, cold storage, etc.) because this is just geared towards beginners for now.

I'm very much open to input. If anyone has additional experience with different wallets, or just thinks I'm flat-out wrong with something that's already on that page, please speak up. You can do the whole GitHub fork / pull request thing if you like, but it seems easier to just respond in this thread or open an issue on GH.

I'm hoping that in the end, this will be a good starting point for answering the "which wallet is best for me" question for beginners.

Just a quick heads up for anyone out there who uses LastPass--

The new MtGox login page doesn't seem to work for me (at least on Chrome) if you have the LastPass extension installed and enabled (even if you're not logged in to LastPass). The only way I can log in is by disabling the extension completely.

Hope this helps someone...

-Chris