As of v0.97, Armory supports BIP 150 and BIP 151 in a specific manner. In particular, Armory can run a headless server on one machine and have an Armory client connect remotely. Such a connection may be configured to be encrypted. If encrypted, after the initial handshake, Armory will attempt to establish a connection, per the BIP 151 spec. After the connection has been established, BIP 150 may be used for authentication purposes. BIP 150 "whitelists" specific IP:Port combinations and performs a basic authentication handshake using pre-determined ECDSA keys. If the handshake succeeds, the connection may proceed, otherwise it will be terminated.
As of August 2018, BIP 150 and BIP 151 are not implemented in Bitcoin Core. Usage of BIP 150 and BIP 151 applies only between an Armory server and its Armory clients. Unless otherwise noted in the future, the connections between Armory and Core nodes will not use BIP 150 or BIP 151.
In addition, the BIP developer (Jonas Schnelli) has stated that BIP 151 will be significantly overhauled in the near future, and possibly rewritten as a new BIP. The rewrite should increase the possibility of Core support (and, hence, introduce Armory node interoperability). However, it won't be backwards compatible with the current implementation.
In order to enable BIP 151, the --bip151v0 flag may be used at the command line.
In order to enable BIP 150, the --bip150v0 flag may be used at the command line. Note that this flag will also force usage of BIP 151 (i.e., the --bip151v0 flag won't be required). While no significant changes to BIP 150 are expected, the "v0" label is used so that anybody with BIP 150 in their config won't suddenly find themselves unable to connect to older implementations.
For BIP 150, pre-determined private and public ECDSA keys will be required. While the spec technically doesn't care which curve is used as long as private keys are 32 bytes long (i.e., 256-bit curves) and signatures can be validated, Armory will use secp256k1. In addition, the spec doesn't care if the public keys are compressed or uncompressed. There's no reason to support uncompressed keys. Therefore, Armory will only support compressed keys.
Armory uses the version of libsecp256k1 that's found in libbtc. This means that Armory will generate only low-S signatures for BIP 150. However, low-S and high-S signautres can be verified.
BIP 150 support is included only for IPv4 and IPv6 connections. The BIP 150 spec mentions support for Tor so that a node can't be fingerprinted if it uses Tor. Armory's support for Tor is very rudimentary and isn't smart enough to recognize when Tor is being used. In order to not give users a false sense of security, BIP 150 will simply not work if Armory's Tor mode is enabled. Should Armory obtain a more robust Tor support method one day, the code has been set up such that adding Tor support under BIP 150 will be minimal.
The following files are used in BIP 150.
armory_data_directory/authorized-peers-v4 - A list of public keys authorized for peers responding to a BIP 150 connection request over an IPv4 connection. armory_data_directory/authorized-peers-v6 - A list of public keys authorized for peers responding to a BIP 150 connection request over an IPv6 connection. armory_data_directory/known-peers-v4 - A list of public keys and related metadata for peers requesting a BIP 150 connection over an IPv4 connection. armory_data_directory/known-peers-v6 - A list of public keys and related metadata for peers requesting a BIP 150 connection over an IPv6 connection. armory_data_directory/identity-key-ipv4 - The private key that will be used by Armory over IPv4 connections. armory_data_directory/identity-key-ipv6 - The private key that will be used by Armory over IPv6 connections. armory_data_directory/identity-key-ipv4.pub - The public key that will be used by Armory over IPv4 connections. armory_data_directory/identity-key-ipv6.pub - The public key that will be used by Armory over IPv6 connections.
Per the BIP 150 spec, ECDSA public keys must be stored in two separate databases. To keep things simple, Armory will simply read two separate text files with the appropriate keys.
As of v0.97, Armory offers no specific tools to add entries to the database files. All values must be added manually via a text editor. Tools may be added in the future to simplify the process. As stated in BIP 150, keys should be supplied via alternative communication channels than the one that will connect the Armory server and client.
If users want a secure method for generating identity keys, extras/genPrivPubKeyPair.py may be used locally to generate a private and (compressed) public secp256k1 key pair using the same methods that Armory uses. The resultant hex strings may be placed in the appropriate files and sent to appropriate parties.
The known-peers files will use a format similar to the OpenSSH "known_hosts" format. In particular, Armory will use the following format, with an example included directly below the template.
hostname,ip:port comp-secp256k1 compressed-public-key-value
dummy,1.2.3.4:8333 comp-secp256k1 02fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0
The following rules apply to the known-peers template.
- A hostname value is mandatory but, for now, the value will be ignored; Armory doesn't support DNS resolution as of v0.97.
- Port values are mandatory.
- "comp-secp256k1" merely indicates that the following key value will be a compressed secp256k1 public key. As of v0.97, no other key types are supported.
- Keys must be written as hex strings.
The authorized-peers file will use a stripped-down version of the known-peers file format. The template and an example are included below.
comp-secp256k1 compressed-public-key-value
comp-secp256k1 02fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0
The following rules apply to the authorized-peers template.
- "comp-secp256k1" merely indicates that the following key value will be a compressed secp256k1 public key. As of v0.97, no other key types are supported.
- Keys must be written as hex strings.
The identity-key files are the private identity keys for BIP 150 nodes. Separate keys are required for IPv4 and IPv6 connections. (BIP 150 also requires a separate key for Tor connections. Due to technical issues, Armory will not support BIP 150 when in Tor mode.) However, no particular connection type is mandatory.
The identity-key file has a template and an example below.
private-key-value
53CDC1E0CFAC07F7E1C312768886F4635F6BCEEBEC0887F63A9D37A26A92E6B6
The following rules apply to the identity-key template.
- The keys must be valid secp256k1-based private keys.
- Keys must be written as hex strings.
The identity-key.pub files are the public identity keys for BIP 150 nodes. Separate keys are required for IPv4 and IPv6, and Tor connections. (BIP 150 also requires a separate key for Tor connections. Due to technical issues, Armory will not support BIP 150 when in Tor mode) However, no particular connection type is mandatory.
The identity-key file has a template and an example below.
compressed-public-key-value
02fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0
The following rules apply to the identity-key.pub template.
- The keys must be valid secp256k1-based compressed public keys.
- Keys must be written as hex strings, and must be 33 bytes long.
(c) 2018 goatpig