[Bitcoin-development] Improving resistance to transaction origination harvesting

[Bitcoin-development] Improving resistance to transaction origination harvesting

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The ability of entities with large numbers of nodes to track the
origination of Bitcoin transactions is very similar to an attack on
the Freenet project.

The Freenet project addressed this weakness by via a technique they
called "Darket" - which means that nodes would only connected to a
defined set of trusted peers instead of being open to all connections
(Opennet) An individual Freenet node can operate in Opennet mode, or
Darknet mode, or mixed mode. [1]

This approach would be beneficial to Bitcoin as well to reduce privacy
leaks due to harvesting attacks.

Proposal:

Allow Bitcoin nodes to create authenticated connections with trusted
peers via CurveCP [2]. Nodes that have at least one CurveCP peer only
broadcast their transactions to those peers.

Use of CurveCP requires both sides of the connection to know each
other's long term public key. This key can be packaged in a structure
similar in concept to a Freenet node reference.

A Bitcoin node reference consists of a JSON structure containing one
or more "externalip" elements followed by one "pubkey" element. The
structure is then clearsigned by the long term CurveCP public key
contained in the "pubkey" element.

Users who wish to set up a secure connection between their nodes would
first use an API command to generate their node references, exchange
these files, and copy them to the ~/.bitcoin/curvecp directory with a
.ref extension. The node only accepts CurveCP connections from, and
attempts CurveCP connection to, peers whose references are present in
that directory.

Instead of listening both for regular TCP and CurveCP connections on
the same port, CurveCP connections would take place on a separate
port, designated by -bind_curvecp, -port_curvecp, and -externalip_curvecp

If -bind_curvecp is specified, the node will always listen for
incoming CurveCP connections, -listen=0 can be set to disallow
non-authenticated incoming connections.

Relationship with Tor:

This proposal would work along with, or independently of Tor usage.

The same network monitoring techniques which can track an originating
transaction to a particular IP address could do the same thing for a
node which is listening as a hidden service, and any technique for
deanonymising hidden services could then identify the point of origin.

Currently the only way to configure a node to submit its transactions
anonymously to the network is to make the node non-listening, which
means it can not contribute to the network.

This proposal would allow nodes to contribute to the network as
listening nodes, while retaining privacy with regards to transactions
originating from themselves.

SPV peers:

CurveCP connections also can be created between full nodes and SPV
nodes, in which case transactions originating from the SPV peers would
be routed as if they originated from the full node.


[1] https://wiki.freenetproject.org/Darknet
[2] http://curvecp.org

- -- 
Justus Ranvier                   | Monetas <http://monetas.net/>
<mailto:justus@monetas.net>      | Public key ID : C3F7BB2638450DB5
                                 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJVCFWiAAoJECpf2nDq2eYjsqIP/2Ri7gmJ1ULqRKh6k0BZskTh
zW2T+Bm+QgoTqiaoLSB61kX6IjwMdTTeVmzCn8ciRIUzvn+RD4843qG0vYKAU3BZ
o+7kMzfAn+KK/Y7j9S++FLteCs21GxsQfARwkKlJxvluoqxlIL50K5H1SySpmZMs
UKppgAIUpHv8H+5T4hwRlgM2vnZv7YyMqEpCDAsVWtQfyOg/WsftVP2UI4zsM3ei
KU36ztJYVUDqmnu3gg0mIW+lv/DqHk59d3Mo/gveRUUUTGzYXy7kKkubCzJQ5t7s
AgEdm5OmlKDEhZt/gFt6AA1FEjoQY+TzDSspFCJMiXmWQU7xu+wJwP7TBINXUbXr
7TNPC0KWHkBCa0ccKvP4O72dToPQM8LQl42My8ye0sUkfqAcOldRoqYBsnpqAdVv
ddvjSyr1wn1ek8bC7tjL1eRdjYz9PFeNayDv5vyur067DI5yjgpTXLjKVHxZe5TO
zA8MC8gp/mHDexO9+zmi+mFdPD/HiFl2liiLMsSg7pxGxMCy6cB8sUXHNPm6+vow
HHGgRWAVWVkTZNHc7n50+ugbtrudQaDOehVSH3NRLZC4pnRAg+pzZz/5Z/WWjr/M
mE1M3nbitCwznFpBm/Zgg7DUZq+MMTlUwsiNdGhyqYfadW7L5/vlp4d7otNoIhOz
V8zOgdC3ZwMfbf/g26PM
=u2MW
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

Re: [Bitcoin-development] Improving resistance to transaction origination harvesting

[Wladimir J. van der Laan]

On Tue, Mar 17, 2015 at 11:26:10AM -0500, Justus Ranvier wrote:
> 
> Allow Bitcoin nodes to create authenticated connections with trusted
> peers via CurveCP [2]. Nodes that have at least one CurveCP peer only
> broadcast their transactions to those peers.

The user would have to select trusted peers or rely on a web of trust to
pick them. Experience with other networks such as Retroshare shows that
not only this is a lot of work to use, mistakes are easily made. It
will only protect the privacy of those that know what they're
doing and who they're trusting.

Otherwise, paradoxally this could reduce privacy, as the trusted peers
necessarily know (part of) your identity to be able to exchange keys
out-of-band. 
(and in practice most people are easily tricked into adding someone as
'friend', for Retroshare here is a case in which a law firm did this and
thus could sue people for making files available...)

> Use of CurveCP requires both sides of the connection to know each
> other's long term public key. This key can be packaged in a structure
> similar in concept to a Freenet node reference.

Right.

> Users who wish to set up a secure connection between their nodes would
> first use an API command to generate their node references, exchange
> these files, and copy them to the ~/.bitcoin/curvecp directory with a
> .ref extension. The node only accepts CurveCP connections from, and
> attempts CurveCP connection to, peers whose references are present in
> that directory.

Indeed, if the goal is to make a secure connections between nodes that
know and trust each other, this could employ any kind of tunnelling on top
of the P2P protocol. CurveCP would be one option. 

As said I'm not convinced this will help with privacy, but this could be
used for whitelisting: trusted nodes could be subjected to fewer DoS
constraints.

> Relationship with Tor:
> 
> This proposal would work along with, or independently of Tor usage.
> 
> The same network monitoring techniques which can track an originating
> transaction to a particular IP address could do the same thing for a
> node which is listening as a hidden service, and any technique for
> deanonymising hidden services could then identify the point of origin.

Seperating the transaction submission from normal node functionality
would already go a long way, and that can be done without any protocol
changes. The transaction submitter would connect to a few nodes
through Tor and drop off a transaction, then disconnect. It would not
advertise itself as the hidden service, and should also use a different
Tor circuit as the node connections.

This could even work if the normal node functionality does not go
through Tor - although then one'd have to be even more careful about
any kind of residual fingerprinting or timing attacks.

Wladimir