librelist archives

« back to archive

Bitcoin anonymity

Bitcoin anonymity

From:
Amir Taaki
Date:
2011-12-29 @ 17:45

Hey,

Cool group. I'm new here and this is my spam email address. My personal 
email is genjix@riseup.net and this is my GPG key:

http://privatepaste.com/download/a8c1c961b2

I'm pretty much involved with bitcoin. Without going into specifics too 
much, one thing I've been working on for a while now is re-implementing 
the bitcoin protocol as a highly asynchronous toolkit-based library 
implementing proactors. The conventional approach for proactors is using a
framework, and I was able to do this using the new C++11 std::bind(...) 
and std::function(...) for passing completion handlers around.

I started work on this library, after it became clear to me that the 
current bitcoin codebase is not at all scalable and has some massive 
problems while working on it. Satoshi did a great job with the concept, 
although the implementation was more of an experiment and it shows.

The design concepts behind this library are encapsulated in this video:

http://www.youtube.com/watch?v=zyKcSpx5xDg

Design documents:

https://bitcointalk.org/index.php?topic=30646.msg384825#msg384825
https://bitcointalk.org/index.php?topic=30646.msg662021#msg662021

Code!
https://gitorious.org/libbitcoin

Using this library, I was able to implement a set of command line 
utilities called subvertx:
https://bitcointalk.org/index.php?topic=50721.0

For subvertx, I plan a bunch more utilities but one in particular is a 
router node that you'd use for shaping traffic. It got me thinking about 
anonymity.

There are 2 issues at hand here:

1) Transactions can be traced throughout the network by maintaining nodes 
with high connectivity. This is how a bitcoin 'transaction radar' works. 
It monitors 100 nodes and gives a % propagation for a transaction (abbrev 
tx) depending on how many of those nodes report back a particular tx. Once
100 nodes have reported the tx, the radar says it is propagated 100%. This
can also be used to triangulate the origin of new txs.

The 100 (or 1000 or 10,000) nodes you are connected to, all tell you their
IP address. If you are able to lookup the location of IP addresses fairly 
easily, then you can use this information to map out how particular txs 
originate and propagate throughout the network.

2) The blockchain which is a ledger is public. It is a story of all the 
money flows since the system's inception. It describes every tx that 
happened. However each tx is between abstract addresses (hashes of public 
keys) which is kind-of private, but not anonymous. If you manage to figure
out ownership of certain addresses, you can do a bit of detective work to 
piece the puzzle pieces backwards. A few scammers were outed this way in 
the community.

If we solve both of these issues, then we can call the bitcoin system anonymous.

1) Using libbitcoin, I could make the bitcoin protocol work over tor or 
another anonymising network. There are some implementation details (how do
I store a tor onion address in a 16 bit field- maybe using a bit of 
hackery), but nothing that is a huge blocker. In libbitcoin, the network 
interface is just an abstract base class and easy replaceable by other 
backends.

If bitcoin runs over tor you would have:

bitcoin in tor + bitcoin on plaintext internet = bitcoin system

Between the plaintext normal protocol and tor based one, gateways would be
needed to keep them glued together. Since the gateways would be getting a 
lot of traffic in and out, anonymity would either depend on many tor nodes
existing (plausible deniability) or a large number of gateways 
(obfuscation).

Another idea is that since a tx is basically a crypto signed contract:

struct transaction_input
{
    output_point previous_output;
    script input_script;
    uint32_t sequence;
};

struct transaction_output
{
    uint64_t value;
    script output_script;
};

typedef std::vector<transaction_input> transaction_input_list;
typedef std::vector<transaction_output> transaction_output_list;

struct transaction
{
    uint32_t version;
    uint32_t locktime;
    transaction_input_list inputs;
    transaction_output_list outputs;
};


The signing happens inside the input_script fields. You can create these 
transaction objects on one machine and then broadcast them to the network 
elsewhere. This is termed offline transactions. subvertx has a command for
this:

$ mktx create -p 
priv@c524c555aad1932c24c26ec20439a9caefc49f7c0df6d6bccced890ef980b45c:0 -k
priv@keys/privkey -r 12oabCifvHuxzXtYVGhkxVfWZDvKcU743s:2000000 -r 
14DDgj2r8WQEwfTDEjJFBn3wRnHmXzgB3z:58000000 | mktx send
1 peers connected.
s: version (85 bytes)
r: version (85 bytes)
s: verack (0 bytes)
r: verack (0 bytes)
Connected
s: tx (258 bytes)

The first part of the pipe is create the binary data for the tx and the 
second part (mktx send) is sending it to bitcoind running on localhost. 
The idea is that you pipe the first half to a file, put it on a USB stick,
travel to a public library or somewhere else and send it on. This is also 
secure since the tx cannot be modified as it is signed.

Both these concepts largely alleviate #1.

2) This is a bit harder. The only concept which seems to work ATM is a 
mixing service.

Imagine:

A wants to send 10 BTC to X
B wants to send 10 BTC to Y 
C wants to send 10 BTC to Z

A -> X
B -> Y
C -> Z


Those txs would be public in the blockchain. But by inserting a magical 
black box between the transactions, you can obfuscate them:
A sends 10 to N sends 10 to Z
B sends 10 to N sends 10 to X
C sends 10 to N sends 10 to Y


And so anyone looking in the blockchain will see:

A -> N -> Z
B -> N -> X
C -> N -> Y


The result is the same, but done a little differently. However the problem
is that you're trusting the mixing service would could be compromised. 
Also for the mixing service to function it needs to have sufficient 
traffic otherwise statistical analysis could deduce transactions.

Any insight, suggestions or reading would be great. I'm genjix on Freenode
IRC. Bitcoin needs to be anonymous so we can finally have our crypto 
anarchy future and pirate revolution! This is the year of the linux 
desktop.





c5 3e a3 b4 d4 4c cf 67 31 73 17 b2 bd 8d 0a 99 46 d8 2d 67 6c 02 d0 d1 13
2b 11 8f 95 d0 7f 57

Re: [remailer] Bitcoin anonymity

From:
Greg Rubino
Date:
2011-12-29 @ 21:28
Hi Amir,

I'm still working my way through your email, but I noticed something
that I wanted to comment on.

On Thu, Dec 29, 2011 at 12:45 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
>
>
> Hey,
>
> Cool group. I'm new here and this is my spam email address. My personal 
email is genjix@riseup.net and this is my GPG key:
>
> http://privatepaste.com/download/a8c1c961b2
>
> I'm pretty much involved with bitcoin. Without going into specifics too 
much, one thing I've been working on for a while now is re-implementing 
the bitcoin protocol as a highly asynchronous toolkit-based library 
implementing proactors. The conventional approach for proactors is using a
framework, and I was able to do this using the new C++11 std::bind(...) 
and std::function(...) for passing completion handlers around.
>

Have you heard of boost::asio?  I believe it is proactor-based and
takes great pains to be cross-platform.  I hear the implementation is
pretty clever as well, although I haven't looked too deeply at it.

http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio.html

Re: [remailer] Bitcoin anonymity

From:
Amir Taaki
Date:
2011-12-30 @ 05:08
> Have you heard of boost::asio?  I believe it is proactor-based and

> takes great pains to be cross-platform.  I hear the implementation is
> pretty clever as well, although I haven't looked too deeply at it.

> http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio.html

Yes. I absolute love boost and use it everywhere internally. boost is what
inspired this design approach.