Monero 14 merge

.gitmodules

@@ -9,3 +9,6 @@
 [submodule "external/rapidjson"]
 	path = external/rapidjson
 	url = https://github.com/Tencent/rapidjson
+[submodule "external/trezor-common"]
+	path = external/trezor-common
+	url = https://github.com/trezor/trezor-common.git

.travis.yml

@@ -10,37 +10,33 @@ cache:
 env:
   global:
     - MAKEJOBS=-j3
-    - RUN_TESTS=false
-    - BOOST_TEST_RANDOM=1$TRAVIS_BUILD_ID
     - CCACHE_SIZE=100M
     - CCACHE_TEMPDIR=/tmp/.ccache-temp
     - CCACHE_COMPRESS=1
     - CCACHE_DIR=$HOME/.ccache
     - BASE_OUTDIR=$TRAVIS_BUILD_DIR/out
     - SDK_URL=https://bitcoincore.org/depends-sources/sdks
-    - PYTHON_DEBUG=1
-    - WINEDEBUG=fixme-all
     - DOCKER_PACKAGES="build-essential libtool cmake autotools-dev automake pkg-config bsdmainutils curl git ca-certificates ccache"
   matrix:
 # ARM v7
-    - HOST=arm-linux-gnueabihf PACKAGES="gperf g++-arm-linux-gnueabihf"
+    - HOST=arm-linux-gnueabihf PACKAGES="python3 gperf g++-arm-linux-gnueabihf"
 # ARM v8
-    - HOST=aarch64-linux-gnu PACKAGES="gperf g++-aarch64-linux-gnu"
+    - HOST=aarch64-linux-gnu PACKAGES="python3 gperf g++-aarch64-linux-gnu"
 # i686 Win
-    - HOST=i686-w64-mingw32 PACKAGES="python3 nsis g++-mingw-w64-i686"
+    - HOST=i686-w64-mingw32 DEP_OPTS="NO_QT=1" PACKAGES="python3 g++-mingw-w64-i686 qttools5-dev-tools"
 # i686 Linux
-    - HOST=i686-pc-linux-gnu PACKAGES="gperf cmake g++-multilib bc python3-zmq" RUN_TESTS=true
+    - HOST=i686-pc-linux-gnu PACKAGES="gperf cmake g++-multilib python3-zmq"
 # Win64
-    - HOST=x86_64-w64-mingw32 PACKAGES="cmake python3 nsis g++-mingw-w64-x86-64 wine-binfmt wine64 bc" RUN_TESTS=true
+    - HOST=x86_64-w64-mingw32 DEP_OPTS="NO_QT=1" PACKAGES="cmake python3 g++-mingw-w64-x86-64 qttools5-dev-tools"
 # x86_64 Linux
-    - HOST=x86_64-unknown-linux-gnu PACKAGES="gperf cmake python3-zmq protobuf-compiler libdbus-1-dev libharfbuzz-dev libprotobuf-dev" RUN_TESTS=true
+    - HOST=x86_64-unknown-linux-gnu PACKAGES="gperf cmake python3-zmq libdbus-1-dev libharfbuzz-dev"
 # Cross-Mac
     - HOST=x86_64-apple-darwin11 PACKAGES="cmake imagemagick libcap-dev librsvg2-bin libz-dev libbz2-dev libtiff-tools python-dev python3-setuptools-git" OSX_SDK=10.11
 
 before_install:
     - export PATH=$(echo $PATH | tr ':' "\n" | sed '/\/opt\/python/d' | tr "\n" ":" | sed "s|::|:|g")
 install:
-    - env | grep -E '^(CCACHE_|WINEDEBUG|DISPLAY|BOOST_TEST_RANDOM|CONFIG_SHELL)' | tee /tmp/env
+    - env | grep -E '^(CCACHE_|DISPLAY|CONFIG_SHELL)' | tee /tmp/env
     - if [[ $HOST = *-mingw32 ]]; then DOCKER_ADMIN="--cap-add SYS_ADMIN"; fi
     - DOCKER_ID=$(docker run $DOCKER_ADMIN -idt --mount type=bind,src=$TRAVIS_BUILD_DIR,dst=$TRAVIS_BUILD_DIR --mount type=bind,src=$CCACHE_DIR,dst=$CCACHE_DIR -w $TRAVIS_BUILD_DIR --env-file /tmp/env ubuntu:18.04)
     - DOCKER_EXEC="docker exec $DOCKER_ID"
@@ -52,6 +48,7 @@ before_script:
     - if [ -n "$OSX_SDK" -a ! -f contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz ]; then curl --location --fail $SDK_URL/MacOSX${OSX_SDK}.sdk.tar.gz -o contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz; fi
     - if [ -n "$OSX_SDK" -a -f contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz ]; then tar -C contrib/depends/SDKs -xf contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz; fi
     - if [[ $HOST = *-mingw32 ]]; then $DOCKER_EXEC bash -c "update-alternatives --set $HOST-g++ \$(which $HOST-g++-posix)"; fi
+    - if [[ $HOST = *-mingw32 ]]; then $DOCKER_EXEC bash -c "update-alternatives --set $HOST-gcc \$(which $HOST-gcc-posix)"; fi
     - if [ -z "$NO_DEPENDS" ]; then $DOCKER_EXEC bash -c "CONFIG_SHELL= make $MAKEJOBS -C contrib/depends HOST=$HOST $DEP_OPTS"; fi
 script:
     - git submodule init && git submodule update

ANONYMITY_NETWORKS.md

@@ -0,0 +1,210 @@
+# Anonymity Networks with Monero
+
+Currently only Tor and I2P have been integrated into Monero. The usage of
+these networks is still considered experimental - there are a few pessimistic
+cases where privacy is leaked. The design is intended to maximize privacy of
+the source of a transaction by broadcasting it over an anonymity network, while
+relying on IPv4 for the remainder of messages to make surrounding node attacks
+(via sybil) more difficult.
+
+
+## Behavior
+
+If _any_ anonymity network is enabled, transactions being broadcast that lack
+a valid "context" (i.e. the transaction did not come from a p2p connection),
+will only be sent to peers on anonymity networks. If an anonymity network is
+enabled but no peers over an anonymity network are available, an error is
+logged and the transaction is kept for future broadcasting over an anonymity
+network. The transaction will not be broadcast unless an anonymity connection
+is made or until `monerod` is shutdown and restarted with only public
+connections enabled.
+
+Anonymity networks can also be used with `monero-wallet-cli` and
+`monero-wallet-rpc` - the wallets will connect to a daemon through a proxy. The
+daemon must provide a hidden service for the RPC itself, which is separate from
+the hidden service for P2P connections.
+
+
+## P2P Commands
+
+Only handshakes, peer timed syncs and transaction broadcast messages are
+supported over anonymity networks. If one `--add-exclusive-node` p2p address
+is specified, then no syncing will take place and only transaction broadcasting
+can occur. It is therefore recommended that `--add-exclusive-node` be combined
+with additional exclusive IPv4 address(es).
+
+
+## Usage
+
+Anonymity networks have no seed nodes (the feature is still considered
+experimental), so a user must specify an address. If configured properly,
+additional peers can be found through typical p2p peerlist sharing.
+
+### Outbound Connections
+
+Connecting to an anonymous address requires the command line option
+`--proxy` which tells `monerod` the ip/port of a socks proxy provided by a
+separate process. On most systems the configuration will look like:
+
+> `--proxy tor,127.0.0.1:9050,10`
+> `--proxy i2p,127.0.0.1:9000`
+
+which tells `monerod` that ".onion" p2p addresses can be forwarded to a socks
+proxy at IP 127.0.0.1 port 9050 with a max of 10 outgoing connections and
+".b32.i2p" p2p addresses can be forwarded to a socks proxy at IP 127.0.0.1 port
+9000 with the default max outgoing connections. Since there are no seed nodes
+for anonymity connections, peers must be manually specified:
+
+> `--add-exclusive-node rveahdfho7wo4b2m.onion:28083`
+> `--add-peer rveahdfho7wo4b2m.onion:28083`
+
+Either option can be listed multiple times, and can specify any mix of Tor,
+I2P, and IPv4 addresses. Using `--add-exclusive-node` will prevent the usage of
+seed nodes on ALL networks, which will typically be undesireable.
+
+### Inbound Connections
+
+Receiving anonymity connections is done through the option
+`--anonymous-inbound`. This option tells `monerod` the inbound address, network
+type, and max connections:
+
+> `--anonymous-inbound rveahdfho7wo4b2m.onion:28083,127.0.0.1:28083,25`
+> `--anonymous-inbound cmeua5767mz2q5jsaelk2rxhf67agrwuetaso5dzbenyzwlbkg2q.b32.i2p:5000,127.0.0.1:30000`
+
+which tells `monerod` that a max of 25 inbound Tor connections are being
+received at address "rveahdfho7wo4b2m.onion:28083" and forwarded to `monerod`
+localhost port 28083, and a default max I2P connections are being received at
+address "cmeua5767mz2q5jsaelk2rxhf67agrwuetaso5dzbenyzwlbkg2q.b32.i2p:5000" and
+forwarded to `monerod` localhost port 30000.
+These addresses will be shared with outgoing peers, over the same network type,
+otherwise the peer will not be notified of the peer address by the proxy.
+
+### Wallet RPC
+
+An anonymity network can be configured to forward incoming connections to a
+`monerod` RPC port - which is independent from the configuration for incoming
+P2P anonymity connections. The anonymity network (Tor/i2p) is
+[configured in the same manner](#configuration), except the localhost port
+must be the RPC port (typically 18081 for mainnet) instead of the p2p port:
+
+> HiddenServiceDir /var/lib/tor/data/monero
+> HiddenServicePort 18081 127.0.0.1:18081
+
+Then the wallet will be configured to use a Tor/i2p address:
+> `--proxy 127.0.0.1:9050`
+> `--daemon-address rveahdfho7wo4b2m.onion`
+
+The proxy must match the address type - a Tor proxy will not work properly with
+i2p addresses, etc.
+
+i2p and onion addresses provide the information necessary to authenticate and
+encrypt the connection from end-to-end. If desired, SSL can also be applied to
+the connection with `--daemon-address https://rveahdfho7wo4b2m.onion` which
+requires a server certificate that is signed by a "root" certificate on the
+machine running the wallet. Alternatively, `--daemon-cert-file` can be used to
+specify a certificate to authenticate the server.
+
+Proxies can also be used to connect to "clearnet" (ipv4 addresses or ICANN
+domains), but `--daemon-cert-file` _must_ be used for authentication and
+encryption.
+
+### Network Types
+
+#### Tor & I2P
+
+Options `--add-exclusive-node` and `--add-peer` recognize ".onion" and
+".b32.i2p" addresses, and will properly forward those addresses to the proxy
+provided with `--proxy tor,...` or `--proxy i2p,...`.
+
+Option `--anonymous-inbound` also recognizes ".onion" and ".b32.i2p" addresses,
+and will automatically be sent out to outgoing Tor/I2P connections so the peer
+can distribute the address to its other peers.
+
+##### Configuration
+
+Tor must be configured for hidden services. An example configuration ("torrc")
+might look like:
+
+> HiddenServiceDir /var/lib/tor/data/monero
+> HiddenServicePort 28083 127.0.0.1:28083
+
+This will store key information in `/var/lib/tor/data/monero` and will forward
+"Tor port" 28083 to port 28083 of ip 127.0.0.1. The file
+`/usr/lib/tor/data/monero/hostname` will contain the ".onion" address for use
+with `--anonymous-inbound`.
+
+I2P must be configured with a standard server tunnel. Configuration differs by
+I2P implementation.
+
+## Privacy Limitations
+
+There are currently some techniques that could be used to _possibly_ identify
+the machine that broadcast a transaction over an anonymity network.
+
+### Timestamps
+
+The peer timed sync command sends the current time in the message. This value
+can be used to link an onion address to an IPv4/IPv6 address. If a peer first
+sees a transaction over Tor, it could _assume_ (possibly incorrectly) that the
+transaction originated from the peer. If both the Tor connection and an
+IPv4/IPv6 connection have timestamps that are approximately close in value they
+could be used to link the two connections. This is less likely to happen if the
+system clock is fairly accurate - many peers on the Monero network should have
+similar timestamps.
+
+#### Mitigation
+
+Keep the system clock accurate so that fingerprinting is more difficult. In
+the future a random offset might be applied to anonymity networks so that if
+the system clock is noticeably off (and therefore more fingerprintable),
+linking the public IPv4/IPv6 connections with the anonymity networks will be
+more difficult.
+
+### Bandwidth Usage
+
+An ISP can passively monitor `monerod` connections from a node and observe when
+a transaction is sent over a Tor/I2P connection via timing analysis + size of
+data sent during that timeframe. I2P should provide better protection against
+this attack - its connections are not circuit based. However, if a node is
+only using I2P for broadcasting Monero transactions, the total aggregate of
+I2P data would also leak information.
+
+#### Mitigation
+
+There is no current mitigation for the user right now. This attack is fairly
+sophisticated, and likely requires support from the internet host of a Monero
+user.
+
+In the near future, "whitening" the amount of data sent over anonymity network
+connections will be performed. An attempt will be made to make a transaction
+broadcast indistinguishable from a peer timed sync command.
+
+### Intermittent Monero Syncing
+
+If a user only runs `monerod` to send a transaction then quit, this can also
+be used by an ISP to link a user to a transaction.
+
+#### Mitigation
+
+Run `monerod` as often as possible to conceal when transactions are being sent.
+Future versions will also have peers that first receive a transaction over an
+anonymity network delay the broadcast to public peers by a randomized amount.
+This will not completetely mitigate a user who syncs up sends then quits, in
+part because this rule is not enforceable, so this mitigation strategy is
+simply a best effort attempt.
+
+### Active Bandwidth Shaping
+
+An attacker could attempt to bandwidth shape traffic in an attempt to determine
+the source of a Tor/I2P connection. There isn't great mitigation against
+this, but I2P should provide better protection against this attack since
+the connections are not circuit based.
+
+#### Mitigation
+
+The best mitigiation is to use I2P instead of Tor. However, I2P
+has a smaller set of users (less cover traffic) and academic reviews, so there
+is a tradeoff in potential isses. Also, anyone attempting this strategy really
+wants to uncover a user, it seems unlikely that this would be performed against
+every Tor/I2P user.
+