Bitcoin client with I2P patch

[giv]

Update 08 Mar 2013
Release 0.1
Update 28 Mar 2013
Merged with 0.8.1
Update 04 Jul 2013
Release 0.2
Improved I2P related code.
Some GUI indicators are added: number of I2P-connections, I2P/non-I2P mode, static/dynamic I2P-address
An I2P options tab added. (Settings - Options... - I2P)
Now you could generate a new I2P-address or could see your current I2P-address in GUI.
Update 11 Jul 2013
Migrated to 0.8.3.
Update 13 Sep 2013
Migrated to 0.8.5.
Update 24 Dec 2013
Migrated to 0.8.6.


References:
Source files:
https://github.com/VirtualDestructor/bitcoin-qt-i2p
Binaries for Windows and Linux x64:
https://sourceforge.net/projects/bitcoinqti2p
Original theme in Russian subforum:
https://bitcointalk.org/index.php?topic=138588.0

(Sorry for my bad English. If someone has a better translation of this post, please pm me)
My project is a patch for Satoshi-client (aka bitcoin-qt/bitcoind). For the present it is more like a Proof-of-Concept than finished application. On the other hand the vanilla bitcoin-client is still beta and nobody worries about that. My client can work in i2p-net using SAM bridge without any third-party libraries. Blocks database is compatible with vanilla client, so you may copy the database from your usual client instead of downloading whole database again.



Installation on Linux (on Ubuntu 12.04 for example):
1) add ppa for i2p and bitcoin

Code:

sudo apt-add-repository ppa:i2p-maintainers/i2p
sudo apt-add-repository ppa:bitcoin/bitcoin

2) update

Code:

sudo apt-get update
sudo apt-get upgrade

3) install packages (java will be installed by dependencies)

Code:

sudo apt-get install i2p bitcoin-qt

4) edit this file /etc/default/i2p under root

Code:

  RUN_DAEMON="true"  <- set to true
...
  MEMORYLIMIT="xxx"  <- specify a value subject to your operative memory (256 or 512 shoud be enough)

5) now run i2p

Code:

sudo service i2p start

Installation on Windows:
1) download an i2p distribution kit from official site only: http://www.i2p2.de/download
2) i2p installer will notify you if Java is not installed on your system. If so you should download Java from official site too http://java.com/download/
3) first install Java, then install I2P
4) go to Control Panel - Administrative tools - Services, find "I2P" and check it is running (if it isn't running you should run it)

Running bitcoin in i2p (both Windows and Linux):
1) after I2P was running you should wait a few minutes while i2p is integrating in the network
2) in your browser open the page http://127.0.0.1:7657/configclients. If the page is unavailable that mean I2P was not running (maybe some errors were occured). If the page opens you should press "Start" button near "SAM application bridge" item and enable a checkbox in column "Run at Startup?" After that press "Save Client Configuration" button.
3) delete (or rename) file peers.dat, it's located at C:\Documents and Settings\<YourUserName>\Application data\Bitcoin (for Win XP)  | C:\Users\<YourUserName>\Appdata\Roaming\Bitcoin (for Vista and 7) | ~/.bitcoin (for linux).
You must to do this because serialization format of network addresses is incompatible between the vanilla client and my patch. You need to do this procedure only once before the first start of the patched client. The patched client will make his own peers.dat with required format. Warning! If you leave this file at his place it cause a deadlock of the patched client.
4) download the patched executable files or compile the executable files by yourself and run it

Code:

bitcoin-qt -onlynet=native_i2p

If you want to deal with i2p-net only you should specify option -onlynet=native_i2p as shown above. If you want to deal with both i2p and ip(usual internet) don't specify this option at all, in this case you client will be a gate between i2p-segment of bitcoin-net and the rest net.

Notes:
If you want to help other bitcoin users in I2P you may send me or publish here your dest-hash or b32-address and I will add them to the sources as seed-node in a next release. But if you want this you should run your wallet with a permanent i2p-address (see section "Starting wallet with a permanent I2P-address" below)

Changes in command line arguments:
1) New command line options are added:

Code:

-i2psessionname=<session name> - name of an I2P session. If it is not specified, value will be "Bitcoin-client"
-samhost=<ip or host name> - address of the SAM bridge host. If it is not specified, value will be "127.0.0.1"
-samport=<port> - port number of the SAM bridge host. If it is not specified, value will be "7656".
-mydestination=<pub+priv i2p-keys> - your full destination (public+private keys). If it is not specified, the client will geneterate a random destination for you. See below (Starting wallet with a permanent i2p-address) more details about this option.
-generatei2pdestination - if this option is specified, your client will start for generation i2p-destination only and will close after that.

2) New possible value for "-onlynet" option is added:

Code:

native_i2p

3) In all options required IP-addresses now you can specify destination hash: <512 symbols>AAAA or b32-address: <52 symbols>.b32.i2p


Compatibility:
1) All of the rest options (except of described above) is not changed and working as they did before
2) Database-file peers.dat is not compatible in both way, neither from vanilla client to my patch, not from my patch to vanilla client. This file must be deleted (or renamed) before using my patch and before going back to vanilla client. This file doesn't contain any important data, so you don't need to back up it.
3) all the rest of databases is compatible with vanilla client.
4) Full backward compatibility of the bitcoin-protocol! Patched client works fine with unpatched vanilla clients. Changes in the protocol are appeared only if both clients are patched.

Starting wallet with a permanent I2P-address:
By default if you don't specify -mydestination parameter the patched wallet generates random i2p-destination. It anonymizes your work with bitcoin even more than before. Especially if you use a new bitcoin-address for each transaction. But if you want to help network by publishing you i2p-address or you just like some i2p-address you have to run wallet with permanent i2p-address. You should specify a full destination in the "mydestination" option for that. Full destionation consists of base64 destionation (b32-address is not allowed here!) and your private tunnel key.
Example:
Run from command line:

Code:

bitcoin-qt -mydestination=SVAxpjZzKn~HjvuqpoX5Y948CQnrPpw~9Y9n7itkniijx3NbgTQGJVmZJoc1ERXE87CqcLeeaWtAwqIwhYXL5Y5XkvaUAlAA5BD-9afCmyP42rtEluQLBAprd70UuN20ujuVm0HPyKcIyezphMHsK~GbYMNFiyTz8ko~Kd2wHaeXKWQh6pXyjQJzT4Bwcv1Y9JtPC5b1P5VpwQaLlMJJvblRi8jbRAbimjsxxrMSG6YX8Ks99tsdnQ6YOHGzTPoGpHFgBiROSYwXtC~BbFSv0XfhmN17ZfG6ZCXTbp-xVs-4txSyS~hnS9dL9xHWIv9MNbJzZhI7YztxWgMR3ZNMwR-W2fUeHAcZusmvbm3r-NpIC0O0p9LDDcu7Vxszk~QD~qylFfIT3j8kwu4RDExgqyelVdXVVSlyriHWoIdt9BklqwI1dbAEoLAfG7IZ3921dP4-MH7~AS8Jn3foNe8CAUvu2baRNRIAu75GknCFV5gGIuRRJjFNnrt~vaZfIQP6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3HWfbGlqztnwMY3ChbVHkDwJv52n9ElA-cWCRJp8lquVU4H-l2kY5Me1QlpY~7qFy

Or you may use your config-file (bitcoin.conf):

Code:

$ cat ~/.bitcoin/bitcoin.conf
mydestination=SVAxpjZzKn~HjvuqpoX5Y948CQnrPpw~9Y9n7itkniijx3NbgTQGJVmZJoc1ERXE87CqcLeeaWtAwqIwhYXL5Y5XkvaUAlAA5BD-9afCmyP42rtEluQLBAprd70UuN20ujuVm0HPyKcIyezphMHsK~GbYMNFiyTz8ko~Kd2wHaeXKWQh6pXyjQJzT4Bwcv1Y9JtPC5b1P5VpwQaLlMJJvblRi8jbRAbimjsxxrMSG6YX8Ks99tsdnQ6YOHGzTPoGpHFgBiROSYwXtC~BbFSv0XfhmN17ZfG6ZCXTbp-xVs-4txSyS~hnS9dL9xHWIv9MNbJzZhI7YztxWgMR3ZNMwR-W2fUeHAcZusmvbm3r-NpIC0O0p9LDDcu7Vxszk~QD~qylFfIT3j8kwu4RDExgqyelVdXVVSlyriHWoIdt9BklqwI1dbAEoLAfG7IZ3921dP4-MH7~AS8Jn3foNe8CAUvu2baRNRIAu75GknCFV5gGIuRRJjFNnrt~vaZfIQP6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3HWfbGlqztnwMY3ChbVHkDwJv52n9ElA-cWCRJp8lquVU4H-l2kY5Me1QlpY~7qFy

The first 516 symbols (SVAxp......~vaZfIQP6AAAA) are public key. This key is a base64 i2p-address (aka dest-hash). The rest symbols are private key. If you want to use some i2p-address you need to know its private key. If you publishes you private i2p-key anyone can use your i2p-address. So keep in secret your private key. This program don't send your private key, it uses your key only to open i2p-tunnel. A simplest way to generate your own I2P-address is running the patched client with option -generatei2pdestination. A generated address with a private key will be shown and you will can copy it to your config-file and publish it.

Building from the sources on Linux:
0) Install all necessary libraries for bitcoin. No additional dependencies are needed.
1) Go to a root directory of the project and run 1.build-unix.sh

Code:

./1.build-unix.sh

Crosscompillation for Windows on Linux:
0) Install mingw32

Code:

apt-get install mingw32

1) Download and unpack dependencies using script 1.env-setup.sh

Code:

./1.env-setup.sh

2) Build dependencies by script 2.build-deps.sh

Code:

./2.build-deps.sh

3) Build bitcoin with i2p-patch using 3.build-linux-mingw.sh

Code:

./3.build-linux-mingw.sh

All builded binaries will be located at <directory with project>/release.
I don't have native windows build scripts, because I use crosscompilation as shown above.

This program is provided "as is" without any warranties.

If you like my project support further developing 1JTtvgy5CzwnsRj3vtHACdyKWxgTnYn754

[1713937799]

1713937799

[1713937799]

1713937799

[1713937799]

1713937799

[1713937799]

1713937799

[giv]

reserved

[naima53]

English-speaking community is not interested in such a substantial improvement of BTC-client (open source)? I'm shocked.  
It seems that for him it was announced the bounty?

[Herbert]

Although personally I don't use I2P i think this is huge! Don't know why no one is interested :-)

[giv]

Update 28 Mar 2013
Merged with 0.8.1

[r.willis]

This is excellent. You did right thing.

[matthewh3]

What's a SAM bridge is it like an exit node/relay on Tor.

[giv]

No. It's a service inside i2p, that allows applications to interact with i2p using simple (berkley) socket.
www.i2p2.de/samv3.html
Applications must be written with SAM support. You cannot run usual apps with SAM.

[matthewh3]

No. It's a service inside i2p, that allows applications to interact with i2p using simple (berkley) socket.
www.i2p2.de/samv3.html
Applications must be written with SAM support. You cannot run usual apps with SAM.

Thanks for the link so the SAM bridge enables the I2p wallet to interact with the public blockchain?  As when you make a Tx it still needs to be stored on the public ledger.  What IP address will Tx's on the I2p wallet show on the public blockchain.  Sorry if that sounds stupid 

Maybe - https://piratelinux.org/ - will start using your wallet.  Pirate Linux comes with Bitcoin-Qt and I2p.  Also just like the Tor browser package it'd be good if a wallet+I2p bundle was available.  As I think the simplicity of the Tor Browser package is one of the major reasons (but not the only reason) that the Tor network of users is larger than that of I2p's (ATM).

Congratulations on the bounty BTW 

[giv]

With my patch you can run your wallet using i2p only ("-onlynet=native_i2p" option) or in a mixed mode. If you run the client in the mixed mode, your wallet will be like a gate between i2p bitcoin subnet and the rest net. If you run the client using i2p only, you have to communicate with the gates run in the mixed mode (maybe indirectly). Otherwise, your wallet will be separated from the rest net.

Let's say wallet1 and wallet3 running in i2p-only mode. And wallet2 running in mixed mode (gate).

Code:

|wallet1|  <-----I2P----->  |wallet2| <---clear internet---> (others)
   ^-- I2P--> |wallet3| <--I2P--^

In this case wallet1, wallet2 and wallet3 will communicate only through I2P. Wallet1 and wallet3 cannot communicate with the rest bitcoin net directly. But wallet2 will retranslate their transactions to the rest net. If wallet2 is down, wallet1 and wallet3 will be separated from the rest network. Some people help me and run their clients in the mixed mode with a static I2P-address. I add their I2P-addresses to source files as seed-nodes. That allows other people use the "i2p only" mode and do not fear to be separated from main bitcoin network.

As I know, blockchain shows IP-address of a node which first retranslate a transction. So I guess it will be an IP of a gate-node. Anyway no one can to know you real IP if you use "i2p only" mode. Moreover, you can firewall all your network connections except i2p-connections and your wallet will work.

[wumpus]

Looks interesting.

How did you solve the address issue? From what I understood, I2P has a very large address space, that doesn't fit in the IPv6 address used in the network protocol.

[giv]

It's true. I've been beating my brains out trying to solve the problem. And my solution is...
Instead of thousand words:

Code:

#ifdef USE_NATIVE_I2P
uint64 nLocalServices = NODE_I2P | NODE_NETWORK;
#else
uint64 nLocalServices = NODE_NETWORK;
#endif

I added a new service NODE_I2P to bitcoin protocol.
And I added a new serialization flag SER_IPADDRONLY. By default my client serialize both of ip-address and i2p-address. But if my client interacts with a node which is not support NODE_I2P service (vanila clients), I do serialize an ip-address only.

Code:

        IMPLEMENT_SERIALIZE
            (
             READWRITE(FLATDATA(ip));

#ifdef USE_NATIVE_I2P
             if (!(nType & SER_IPADDRONLY))
             {
                READWRITE(FLATDATA(i2pDest));
             }
#endif

            )

So, if my client connected to a node with NODE_I2P service it will send and receive full ip and i2p-addresses. If my client connected to a standard client it will send and receive only IPs. It's fully backward compatible with standard clients, except of "peers.dat" file.

[wumpus]

Good solution. Though I'd make it more general: I'd name the cap NODE_LONG_ADDRESS (or similar). That makes it usable if other protocols with long addresses turn up.

[giv]

Yes, I thought about making it more abstract.
In general case there must be a method to negotiate a length of address and type of net. Different nets may have equal length of address.
Also current bitcoin code is hard to add new protocols. So adding general NODE_LONG_ADDRESS service is much more harder than add i2p protocol only. Probably adding a general long address support will cause a huge refactoring of the current bitcoin code.
I considered a "boost::asio" library as a base for this refactoring, but it's just in my thoughts yet.

[K1773R]

With my patch you can run your wallet using i2p only ("-onlynet=native_i2p" option) or in a mixed mode. If you run the client in the mixed mode, your wallet will be like a gate between i2p bitcoin subnet and the rest net. If you run the client using i2p only, you have to communicate with the gates run in the mixed mode (maybe indirectly). Otherwise, your wallet will be separated from the rest net.

Let's say wallet1 and wallet3 running in i2p-only mode. And wallet2 running in mixed mode (gate).

Code:

|wallet1|  <-----I2P----->  |wallet2| <---clear internet---> (others)
   ^-- I2P--> |wallet3| <--I2P--^

In this case wallet1, wallet2 and wallet3 will communicate only through I2P. Wallet1 and wallet3 cannot communicate with the rest bitcoin net directly. But wallet2 will retranslate their transactions to the rest net. If wallet2 is down, wallet1 and wallet3 will be separated from the rest network. Some people help me and run their clients in the mixed mode with a static I2P-address. I add their I2P-addresses to source files as seed-nodes. That allows other people use the "i2p only" mode and do not fear to be separated from main bitcoin network.

As I know, blockchain shows IP-address of a node which first retranslate a transction. So I guess it will be an IP of a gate-node. Anyway no one can to know you real IP if you use "i2p only" mode. Moreover, you can firewall all your network connections except i2p-connections and your wallet will work.

you can ban blockchain so you wont be the first guy to relay it and therefore wont show up!

[wumpus]

I considered a "boost::asio" library as a base for this refactoring, but it's just in my thoughts yet.

It's best to keep the changes as small and specific as possible, at least if the idea is to have this merged upstream at some point, which I think would be useful.

Coupling it to refactoring and using different I/O libraries (which may be a good idea in itself) could become too complex and too much at once to review.

[giv]

I considered a "boost::asio" library as a base for this refactoring, but it's just in my thoughts yet.

It's best to keep the changes as small and specific as possible, at least if the idea is to have this merged upstream at some point, which I think would be useful.

Coupling it to refactoring and using different I/O libraries (which may be a good idea in itself) could become too complex and too much at once to review.

Exactly. That's why I made smallest changes as I could. And that's why there is i2p-patch only, not general "long-address" patch. Because it's too complex for this moment.

you can ban blockchain so you wont be the first guy to relay it and therefore wont show up!

Sorry, I didn't understand you. What do you mean "ban blockchain"?

[K1773R]

you can ban blockchain so you wont be the first guy to relay it and therefore wont show up!

Sorry, I didn't understand you. What do you mean "ban blockchain"?

ban blockchain.info's node

[matthewh3]

With my patch you can run your wallet using i2p only ("-onlynet=native_i2p" option) or in a mixed mode. If you run the client in the mixed mode, your wallet will be like a gate between i2p bitcoin subnet and the rest net. If you run the client using i2p only, you have to communicate with the gates run in the mixed mode (maybe indirectly). Otherwise, your wallet will be separated from the rest net.

Let's say wallet1 and wallet3 running in i2p-only mode. And wallet2 running in mixed mode (gate).

Code:

|wallet1|  <-----I2P----->  |wallet2| <---clear internet---> (others)
   ^-- I2P--> |wallet3| <--I2P--^

In this case wallet1, wallet2 and wallet3 will communicate only through I2P. Wallet1 and wallet3 cannot communicate with the rest bitcoin net directly. But wallet2 will retranslate their transactions to the rest net. If wallet2 is down, wallet1 and wallet3 will be separated from the rest network. Some people help me and run their clients in the mixed mode with a static I2P-address. I add their I2P-addresses to source files as seed-nodes. That allows other people use the "i2p only" mode and do not fear to be separated from main bitcoin network.

As I know, blockchain shows IP-address of a node which first retranslate a transction. So I guess it will be an IP of a gate-node. Anyway no one can to know you real IP if you use "i2p only" mode. Moreover, you can firewall all your network connections except i2p-connections and your wallet will work.

Thanks for the simple explanation, so gateway nodes will always be needed to the clearnet blockchain.  I think there's room for an alt-coin where its blockhain solely only exists inside the I2p network.  It could still be used on clearnet sites that acted as I2p proxies.

[justusranvier]

Is there any way to compile bitcoind using this patch instead of bitcoin-qt?