Bitcoin client with I2P patch | Bitcointalksearch.org

donschoe

full member

Activity: 157

Merit: 100

Hello Coins

Quote from: justusranvier on January 30, 2015, 01:21:27 PM

For this to really happen the network protocol needs to allow for 256 bit peer addresses.

Is this an issue?

justusranvier

legendary

Activity: 1400

Merit: 1013

For this to really happen the network protocol needs to allow for 256 bit peer addresses.

matthewh3

legendary

Activity: 1372

Merit: 1003

I believe Anoncoin forked the patch and are now working on a C++ I2p router with the Monero team - https://geti2p.net/en/blog/post/2014/08/15/The-privacy-solutions-project

fsb4000

legendary

Activity: 1400

Merit: 1000

Quote from: vertoe on January 28, 2015, 05:34:53 AM

Hi, I wonder why you dont submit this patch to bitcoin core? Did you try that or recommended I2P integration?

He didn't try...

Quote from: laanwj

There is a bitcoin fork that works on I2P, I am not sure what the status of it is, and he has never tried to get the changes upstream:
https://bitcointalksearch.org/topic/bitcoin-client-with-i2p-patch-151181

https://github.com/bitcoin/bitcoin/issues/2091#issuecomment-42650077

vertoe

hero member

Activity: 518

Merit: 505

Hi, I wonder why you dont submit this patch to bitcoin core? Did you try that or recommended I2P integration?

Paperweight

jr. member

Activity: 41

Merit: 41

Thank you for this!

meeh

hero member

Activity: 490

Merit: 500

:)

Quote from: matthewh3 on March 08, 2014, 09:06:11 AM

Have Anoncoin copied this patch?

Yes our implementation originates from this patch. You can also see giv's copyright in the i2psam library at the source code for example.

matthewh3

legendary

Activity: 1372

Merit: 1003

Have Anoncoin copied this patch?

Quote from: meeh on October 12, 2013, 07:18:07 AM

What/Howto I2P

Here are some parameters:

Code:

-i2psessionname= - name of an I2P session. If it is not specified, value will be "Anoncoin-client"
-samhost= - address of the SAM bridge host. If it is not specified, value will be "127.0.0.1"
-samport= - port number of the SAM bridge host. If it is not specified, value will be "7656".
-mydestination= - 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.

Your client will act as a gateway between I2P and clearnet if you don't add -onlynet=i2p

If you have used your Anoncoin client on clearnet before, you might need to delete peers.dat if you don't get any connections.

To use the wallet on I2P do the following:

1. Download and install I2P ( www.geti2p.net ), then start it. (It will run as a daemon, so don't expect any window)
2. Wait a minute or two, then navigate to http://127.0.0.1:7657/configclients
3. Make sure to start the "SAM application bridge" (Tip: After starting it, check it for autostart and save configuration)
4. In run (enter the start menu and type run on windows Vista/7) type %appdata%
5. Open or create the Anoncoin folder
6. Create/edit the anoncoin.conf file
7. make sure to set the following options: rpcuser, rpcpassword and onlynet=i2p
8. (Optional) you can set i2p=1 instead of onlynet=i2p

Example:
rpcuser=someone
rpcpassword=super_secret_password
onlynet=i2p

Note: The I2P router uses a little time to integrate into the I2P network, so you might not get a connection before I2P have runned for about 5-10minutes.

https://bitcointalksearch.org/topic/m.3324938

If so how difficult would it be to port to other coins?

isbe

newbie

Activity: 13

Merit: 0

Quote from: justusranvier on December 24, 2013, 06:08:08 PM

Is there any plan to move this patch into the main repository any time soon?

Maybe start incrementally by moving the peers.dat format changes first?

That would be terrific..

justusranvier

legendary

Activity: 1400

Merit: 1013

Is there any plan to move this patch into the main repository any time soon?

Maybe start incrementally by moving the peers.dat format changes first?

K1773R

legendary

Activity: 1792

Merit: 1008

/dev/null

Quote from: matthewh3 on October 27, 2013, 02:18:35 AM

Quote from: giv on October 25, 2013, 03:48:41 PM

You do not need to run patched bitcoind before bitcoin-qt. Bitcoin-qt should work immediately, if it doesn't then probably there is a bug. Under which OS do you have this problem?

Xubuntu, it does work maybe I didn't follow the OP's instructions correctly?

did you enable the SAM bridge in i2p? if not, you have to!

giv

sr. member

Activity: 254

Merit: 251

Update 24 Dec 2013
Migrated to 0.8.6.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on October 25, 2013, 03:48:41 PM

You do not need to run patched bitcoind before bitcoin-qt. Bitcoin-qt should work immediately, if it doesn't then probably there is a bug. Under which OS do you have this problem?

Xubuntu, it does work maybe I didn't follow the OP's instructions correctly?

giv

sr. member

Activity: 254

Merit: 251

You do not need to run patched bitcoind before bitcoin-qt. Bitcoin-qt should work immediately, if it doesn't then probably there is a bug. Under which OS do you have this problem?

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on October 25, 2013, 10:41:41 AM

Quote from: matthewh3 on October 24, 2013, 09:29:15 AM

I don't if it that I needed to restart the patched wallet a few times after a fresh install. Or if I had to start the bitcoind patch first before starting the bitcoin-qt patch and getting it to connect to I2p peers only for the first time. Or did I miss that in the OP instructions?

Sorry I don't quite understand. Please reword you message.

When you have just installed/run i2p, it may discard new connections while it's integrating in the network. If you have troubles, please describe step-by-step how can I reproduce it.

Sorry - I don't know if it that I needed to restart the patched wallet a few times after a fresh install. Or if I had to start the bitcoind patch first before starting the bitcoin-qt patch and getting it to connect to I2p peers only for the first time. Or did I miss that in the OP instructions? - it is working now but I don't know if that it just needed restarting a few times or if I needed to to run the bitcoind patch first before starting the bitcoin-qt patch and getting it to to connect to only I2p peers for the first time.

giv

sr. member

Activity: 254

Merit: 251

Quote from: matthewh3 on October 24, 2013, 09:29:15 AM

I don't if it that I needed to restart the patched wallet a few times after a fresh install. Or if I had to start the bitcoind patch first before starting the bitcoin-qt patch and getting it to connect to I2p peers only for the first time. Or did I miss that in the OP instructions?

Sorry I don't quite understand. Please reword you message.

When you have just installed/run i2p, it may discard new connections while it's integrating in the network. If you have troubles, please describe step-by-step how can I reproduce it.

matthewh3

legendary

Activity: 1372

Merit: 1003

I don't if it that I needed to restart the patched wallet a few times after a fresh install. Or if I had to start the bitcoind patch first before starting the bitcoin-qt patch and getting it to connect to I2p peers only for the first time. Or did I miss that in the OP instructions?

matthewh3

legendary

Activity: 1372

Merit: 1003

I think you need to work on making the wallet easier to install for newbies to attract more users. Like a single Windows .exe or .deb for the whole wallet maybe with I2p combined too.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: K1773R on September 17, 2013, 03:14:09 AM

Quote from: matthewh3 on September 16, 2013, 05:17:47 PM

Quote from: giv on September 15, 2013, 03:40:04 AM

This update does not influence to connections. But last few days I has only 1-2 connections. I don't know what happened with other nodes, but my nodes are working fine.
Try to rerun you client. If it doesn't help, try to manually add nodes by the 'addnode' command with the following addresses:

Code:

bhqfvosghsfdbi3qubnk3ro6juklz5w7b6l3x6mibkxzzk3mob5a.b32.i2p
z5pg37axylu7wuncppbzvwxawb5mo3euxuwbyi2s2um7bhnl3caa.b32.i2p
ofa7kfuqewnxyqiadnsj6ibcwtj6ndcabwcfabljmuyol2pussaa.b32.i2p
mzvsw6bwae6ul33b5zege5xie2cevno6vgik6nrb6lw74cn3wmdq.b32.i2p

After the update manger on Xubuntu downloaded the official updates then I ran your exe's it works OK. Just got three I2p peers within five minutes.

Edit: Soon up to four peers.

exe's? are you running it in wine? wtf...

OK patches that run as executables.

K1773R

legendary

Activity: 1792

Merit: 1008

/dev/null

Quote from: matthewh3 on September 16, 2013, 05:17:47 PM

Quote from: giv on September 15, 2013, 03:40:04 AM

This update does not influence to connections. But last few days I has only 1-2 connections. I don't know what happened with other nodes, but my nodes are working fine.
Try to rerun you client. If it doesn't help, try to manually add nodes by the 'addnode' command with the following addresses:

Code:

bhqfvosghsfdbi3qubnk3ro6juklz5w7b6l3x6mibkxzzk3mob5a.b32.i2p
z5pg37axylu7wuncppbzvwxawb5mo3euxuwbyi2s2um7bhnl3caa.b32.i2p
ofa7kfuqewnxyqiadnsj6ibcwtj6ndcabwcfabljmuyol2pussaa.b32.i2p
mzvsw6bwae6ul33b5zege5xie2cevno6vgik6nrb6lw74cn3wmdq.b32.i2p

After the update manger on Xubuntu downloaded the official updates then I ran your exe's it works OK. Just got three I2p peers within five minutes.

Edit: Soon up to four peers.

exe's? are you running it in wine? wtf...

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on September 15, 2013, 03:40:04 AM

This update does not influence to connections. But last few days I has only 1-2 connections. I don't know what happened with other nodes, but my nodes are working fine.
Try to rerun you client. If it doesn't help, try to manually add nodes by the 'addnode' command with the following addresses:

Code:

bhqfvosghsfdbi3qubnk3ro6juklz5w7b6l3x6mibkxzzk3mob5a.b32.i2p
z5pg37axylu7wuncppbzvwxawb5mo3euxuwbyi2s2um7bhnl3caa.b32.i2p
ofa7kfuqewnxyqiadnsj6ibcwtj6ndcabwcfabljmuyol2pussaa.b32.i2p
mzvsw6bwae6ul33b5zege5xie2cevno6vgik6nrb6lw74cn3wmdq.b32.i2p

After the update manger on Xubuntu downloaded the official updates then I ran your exe's it works OK. Just got three I2p peers within five minutes.

Edit: Soon up to four peers.

justusranvier

legendary

Activity: 1400

Merit: 1013

I'm seeing this problem with listen=1 and maxconnections=256 set in bitcoin.conf

My node will end up with 3-4 peers, none of them I2P, and it will drop the SAM connection so that the I2P node no longer creates the tunnels, which prevents incoming I2P connections.

The only way I can get any native I2P connections at all is to run the node with onlynet=native_i2p

giv

sr. member

Activity: 254

Merit: 251

Quote from: justusranvier on September 16, 2013, 02:20:45 AM

I've noticed that I frequently check my peer list and find no i2p peers unless I use -onlynet-native_i2p, but I'd like to also use other peer types.

Quote from: giv on August 18, 2013, 10:57:55 AM

If you run the patched client in mixed mode, most probably it will use only ip-addresses for outgoing connections. That's why. The bitcoin-client has a pool of known addresses. Selecting of address is a pseudorandom process. At now there are hundreds (at first start) and thousands (after syncing with other clients) known ip-addresses and only several I2P-addresses in the pool. By default only 8 outgoing connections are allowed. So probability of selecting an i2p-address is less than 1%.
If you want to run the program in mixed mode, but want to connect with some i2p-nodes (for tests or other purposes) you have to add an i2p-node manually with "-addnode=" option. Also you may publish your i2p-address or PM me and others can connect to your client. In such case you will see his connections as incoming.

Of course, if your i2p-address changes you should publish the new address again. Obviously, it's inconveniently, so I suggest to use a static i2p-address in this case.
Also if you use the '-tor'/'proxy' options (or appropriate settings in gui) you should use the '-listen' option if you want to accept incoming i2p-connections, because the '-tor'/'proxy' options disable the '-listen' option by default.

justusranvier

legendary

Activity: 1400

Merit: 1013

I've noticed that I frequently check my peer list and find no i2p peers unless I use -onlynet-native_i2p, but I'd like to also use other peer types.

giv

sr. member

Activity: 254

Merit: 251

If you get one of these messages:
"... coin database inconsistencies found"
and/or
"Do you want to rebuild the block database now?",
please DO NOT redownload/reindex the blocks (it will just waste your time, especially via i2p).
It is known issue and it's resolved in the 0.8.5 release. So just update your wallet to 0.8.5, if you still didn't do that
More info here:
https://bitcointalksearch.org/topic/bitcoin-qt-bitcoind-version-085-released-293307
https://bitcointalksearch.org/topic/all-bitcoind-bitcoin-qt-nodes-failing-to-come-up-workaround-inside-290922

giv

sr. member

Activity: 254

Merit: 251

This update does not influence to connections. But last few days I has only 1-2 connections. I don't know what happened with other nodes, but my nodes are working fine.
Try to rerun you client. If it doesn't help, try to manually add nodes by the 'addnode' command with the following addresses:

Code:

bhqfvosghsfdbi3qubnk3ro6juklz5w7b6l3x6mibkxzzk3mob5a.b32.i2p
z5pg37axylu7wuncppbzvwxawb5mo3euxuwbyi2s2um7bhnl3caa.b32.i2p
ofa7kfuqewnxyqiadnsj6ibcwtj6ndcabwcfabljmuyol2pussaa.b32.i2p
mzvsw6bwae6ul33b5zege5xie2cevno6vgik6nrb6lw74cn3wmdq.b32.i2p

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on September 13, 2013, 08:12:32 AM

Update 13 Sep 2013
Migrated to 0.8.5.

I downloaded your two new (linux) executables and ran them but I can't seem to get any peers any more. Is there a method to updating?

giv

sr. member

Activity: 254

Merit: 251

Update 13 Sep 2013
Migrated to 0.8.5.

giv

sr. member

Activity: 254

Merit: 251

Four nodes it is ok. Today I have only 4-5 nodes too. Of course the more peers the better, but 3-5 peers are enough to send/receive a transaction to the rest net with admissible speed.
Judging by I2P stats your ports are still closed. If you open the ports you'll see smth like this:

Code:

Peers
Active:	1329 / 3850

But if you can't open them it's nothing. Probably in this case your i2p-connection will be a little bit slower or less stable, but nothing serious.

If your wallet is always running with a static i2p-address you can send your public i2p-address to me and I'll add it as seed-node in my code if you want.

matthewh3

legendary

Activity: 1372

Merit: 1003

All day yesterday and so far today I've been connected to four peers in I2p only mode. Here are my I2p stats

Code:

Peers
Active:	26 / 205
Fast:	19
High capacity:	89
Integrated:	445
Known:	507

Bandwidth in/out
3 sec:	2.93 / 2.95 KBps
5 min:	2.30 / 3.80 KBps
Total:	3.83 / 3.38 KBps
Used:	19.57 MB / 17.54 MB

Tunnels
Exploratory:	6
Client:	6
Participating:	0
Share ratio:	0.00

Congestion
Job lag:	0
Message delay:	99 ms
Backlog:	0

Is four connections right or are my I2p stats low. I mostly use a VPN to connect to the internet so not sure if I can forward any ports?

Edit: Its gone to and stayed at three peers now. Here are my I2p connection stats -

Code:

Peers
Active:	12 / 202
Fast:	18
High capacity:	45
Integrated:	453
Known:	517

Bandwidth in/out
3 sec:	1.73 / 2.04 KBps
5 min:	2.94 / 2.98 KBps
Total:	3.52 / 3.27 KBps
Used:	43.06 MB / 40.38 MB

Tunnels
Exploratory:	7
Client:	8
Participating:	1
Share ratio:	0.03

Congestion
Job lag:	0
Message delay:	560 ms
Backlog:

2nd edit: Four nodes now.

giv

sr. member

Activity: 254

Merit: 251

For auto-starting the patched client try to delete the ~/.config/autostart/bitcoin.desktop file or open it in any text editor and fix a path to your client. If you will run the vanilla client after that it will rewrite this file again.
I need output of bitcoind/bitcoin-qt to determine why you have only one connection. I have 4-6 peers for today in my wallet. Even if you connect to one node it should give addresses of other nodes to you.
Oh, I see you have a few i2p-peers (Active: 14 / 113). Most probably your ports are closed. In this case I2P works very slow and unstable. You can see the port number at http://127.0.0.1:7657/confignet. Try to open the i2p-port in your firewall or router.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on August 19, 2013, 11:07:19 AM

What do you mean "the wrong version"?

The default bitcoind you suggested I was running when I couldn't connect to any I2p peers. Also all today I've only been connected to one I2p peer?

giv

sr. member

Activity: 254

Merit: 251

What do you mean "the wrong version"?

matthewh3

legendary

Activity: 1372

Merit: 1003

When I set bitcoin-qt to auto-start in settings it starts the wrong version and I get no I2p connections but the I2p settings are there in the wallet like before? I have to start bitcoin-qt from your executable on each boot.

giv

sr. member

Activity: 254

Merit: 251

Usually there are 5-7 i2p-nodes. At least 3 of them are running in mixed mode (working as gateways).

matthewh3

legendary

Activity: 1372

Merit: 1003

Thanks now connected Grin

with five I2p nodes tho it was up to six before. How many I2p nodes are they in total on average and how many nodes acting as gateways?

giv

sr. member

Activity: 254

Merit: 251

ok, i2p is working. Run the patched bitcoin-qt/bitcoind in console and post output (to this thread or to PM).

Quote from: matthewh3 on August 18, 2013, 06:43:53 AM

I try running bitcoind from the command line but it says itys not installed even tho I've excuted bitcoind from your download and bitcoin-qt can connect to the normal network.

Seems like you trying to run default bitcoind. Try to run the patched bitcoind explicitly, smth like /path/to/the/patched/client/bitcond. It should work.

If you run the patched client in mixed mode, most probably it will use only ip-addresses for outgoing connections. That's why. The bitcoin-client has a pool of known addresses. Selecting of address is a pseudorandom process. At now there are hundreds (at first start) and thousands (after syncing with other clients) known ip-addresses and only several I2P-addresses in the pool. By default only 8 outgoing connections are allowed. So probability of selecting an i2p-address is less than 1%.
If you want to run the program in mixed mode, but want to connect with some i2p-nodes (for tests or other purposes) you have to add an i2p-node manually with "-addnode=" option. Also you may publish your i2p-address or PM me and others can connect to your client. In such case you will see his connections as incoming. The client can accept incoming connections even it already has maximum of outgoing connections. If you have a permanent i2p-address and your wallet is running most time I can add your i2p-address to a source code as seed-node in the next releases if you want.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on August 17, 2013, 04:01:51 PM

First of all, check that i2p is working, try to open any i2p-site. Then check that SAM is enabled and running. If it is ok, check the log at ~/.bitcoin/debug.log and check the output of bitcoind/bitcoin-qt. Which mode (i2p-only or mixed) do you use? Do you use any command-line options?

I2p peers

Active:   14 / 113
Fast:   12
High capacity:   73
Integrated:   42
Known:   136

And can login to Susimail. Sam bridges are running and set to start on start up. There's loads of data in - ~/.bitcoin/debug.log.

Code:

CTxMemPool::accept() : accepted 0bc9997a50f94788fe9a410a1bba53f6c59c0a2f65f0db787956384cbb16d48d (poolsz 1704)
received getdata for: tx 0bc9997a50f94788fe9a410a1bba53f6c59c0a2f65f0db787956384cbb16d48d
CTxMemPool::accept() : accepted 46445598b5c66558043736038ee706d01ea093b69adf97bde50c4b36216dea3e (poolsz 1705)
received getdata for: tx 46445598b5c66558043736038ee706d01ea093b69adf97bde50c4b36216dea3e
CTxMemPool::accept() : accepted 8b1788ebd001456a67eb44040bbbf07a8e80dbafe902b6b89c085aed4b5c09e5 (poolsz 1706)
CTxMemPool::accept() : accepted 207c62c0cbd38a29b541a684339de0d073509559f6ce37375dfd037c95e30a3d (poolsz 1707)
Added 1 addresses from 216.228.163.130: 75 tried, 13534 new
CTxMemPool::accept() : accepted f99df6a709e60d22349eb3302ada59228c7b2d6d826bfbec64b41666153cbd38 (poolsz 1708)
CTxMemPool::accept() : accepted eeb80cfa0f35a952359ced22431a86529136025f727137021a98653cf980751a (poolsz 1709)
CTxMemPool::accept() : accepted 61531b804904c0311deb627557f1d4abdf0ebb7c07aec6846c9c4cca3c41821c (poolsz 1710)
CTxMemPool::accept() : accepted 623a36310e06570fa53b3b3b3a9b2ee42476750c05c606202ab4db18fc66fe92 (poolsz 1711)
CTxMemPool::accept() : accepted 413ca1836bbad36d8e9ef27b1079c79e5e94eeebb821d327880cbefbbf673ae7 (poolsz 1712)
CTxMemPool::accept() : accepted 951f037967e0959339415be85aff8b7f73b675d61736f058158493e122f3d0c3 (poolsz 1713)
CTxMemPool::accept() : accepted 6595510b852e0d2de6443f1996401783197b97760ac59e7bb6743277758e4e17 (poolsz 1714)
CTxMemPool::accept() : accepted 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b (poolsz 1715)
received getdata for: tx 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b
received getdata for: tx 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b
received getdata for: tx 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b
received getdata for: tx 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b
received getdata for: tx 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b
received getdata for: tx 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b
received getdata for: tx 093e8be388afa3a039ec622d0f6aece029b5e581eebe91afce71f08d911c225b
Added 1 addresses from 64.53.128.12: 75 tried, 13533 new
CTxMemPool::accept() : accepted bc7219f5453ebffe9b417b8fa2b26a13e0c00edd5bd9f29a4892f635b82570dc (poolsz 1716)
Added 1 addresses from 184.5.141.187: 75 tried, 13533 new
CTxMemPool::accept() : accepted cc0753e9503b285862b54138dc82e752f8b15325690388b631e190aaa4ac2787 (poolsz 1717)
CTxMemPool::accept() : accepted 904b28e4c9adf6f8836a3cbe1575c0c5763f3985095202a69cfbf4064e4029e9 (poolsz 1718)
CTxMemPool::accept() : accepted b229631eef5c2e44b9ecd7a91efc047636fdaf18db5cb67669fdcf32f2bb93c8 (poolsz 1719)
CTxMemPool::accept() : accepted f38937a941d2cf18247720c96243f38da8bf67dde181f364303f88b1d11939a6 (poolsz 1720)
received getdata for: tx f38937a941d2cf18247720c96243f38da8bf67dde181f364303f88b1d11939a6
CTxMemPool::accept() : accepted 467a70695d4898ce999bb0e6b1c5d624c6b4203eabbeb9d798fae5cee89de687 (poolsz 1721)
CTxMemPool::accept() : accepted ff31ba027f16d32477661ce8321cba58a3e9022eeb455b2092733e11f3e766c2 (poolsz 1722)
CTxMemPool::accept() : accepted da6da98d0f0ec2b4f9134e536d61228a5fae8a482be08b212588844c79e47d5a (poolsz 1723)
CTxMemPool::accept() : accepted 0c4cc357bda01e6be8d82691ff5df363f1336fd105db9ac4be2e80f047a7396c (poolsz 1724)
CTxMemPool::accept() : accepted 90d559f9f89838424fcf67108b0e1181f0b2a5c8325d01a4d30f9e7a9a94cccd (poolsz 1725)
received getdata for: tx 90d559f9f89838424fcf67108b0e1181f0b2a5c8325d01a4d30f9e7a9a94cccd
CTxMemPool::accept() : accepted 599f619825bd51e7f1a2097e2999896a5753cf471689a18ae4b61d83cee717d7 (poolsz 1726)
CTxMemPool::accept() : accepted 82ec6eed19482a1672133fbe3c8e3ba121a63b55b486b84184ce3fe907861aec (poolsz 1727)
Added 1 addresses from 216.228.163.130: 75 tried, 13534 new
stored orphan tx c4a23c658858718d8caf6ca06b08fc472a78fb500e7678f112d9aaa87fcf9b54 (mapsz 9973)
CTxMemPool::accept() : accepted 42b497cfad304cc466d2ca79c7299f31f230d603dc21ca6065ecb4e88ffc3356 (poolsz 1728)
CTxMemPool::accept() : accepted c4a23c658858718d8caf6ca06b08fc472a78fb500e7678f112d9aaa87fcf9b54 (poolsz 1729)
   accepted orphan tx c4a23c658858718d8caf6ca06b08fc472a78fb500e7678f112d9aaa87fcf9b54
CTxMemPool::accept() : accepted 5da90cbb8ebbd08c953653fda77165fc8261550839179fc9c2a971f47e35f9d0 (poolsz 1730)
received getdata for: tx c4a23c658858718d8caf6ca06b08fc472a78fb500e7678f112d9aaa87fcf9b54
CTxMemPool::accept() : accepted 35d59e84bdd4749f2431405d90b4e1c5e118136b67d5519bad33cccb5f67e9bf (poolsz 1731)
CTxMemPool::accept() : accepted 34a20bcd9c41ebe18b8785983199b8ff148b84d2eca9f6ef3682d8863fdc0033 (poolsz 1732)
CTxMemPool::accept() : accepted e4eeb421afca38dde3aa3b9a107d248c565aac4c2194e3d91a6ddaf879321791 (poolsz 1733)
CTxMemPool::accept() : accepted a6e2a1159cfdb7ba160a593f060a61aa8a9c814f53359de1a5a8f43edfd080f8 (poolsz 1734)
CTxMemPool::accept() : accepted 3a27f9240f234cda72cb218bc5d056857f29bddf2251e7c8ebc4fe03c3494492 (poolsz 1735)
CTxMemPool::accept() : accepted efcb663564f39f4204a6ac0b9c96ff6551d2f7b3f6e4744dcd6a887c45a36c75 (poolsz 1736)
CTxMemPool::accept() : accepted 30e3273b8c76d4a84fceb90fc13370dbc59e3774ce04bab71b3e303fb0c8dd1d (poolsz 1737)
CTxMemPool::accept() : accepted cdecb31400c21bdbdfe64149a05f665a5534f24c6b27b85246c90accb809f474 (poolsz 1738)

In mixed mode I can onnect to normal peers but not I2p ones. In I2p only mode can't connect to any nodes. I try running bitcoind from the command line but it says itys not installed even tho I've excuted bitcoind from your download and bitcoin-qt can connect to the normal network.

giv

sr. member

Activity: 254

Merit: 251

First of all, check that i2p is working, try to open any i2p-site. Then check that SAM is enabled and running. If it is ok, check the log at ~/.bitcoin/debug.log and check the output of bitcoind/bitcoin-qt. Which mode (i2p-only or mixed) do you use? Do you use any command-line options?

matthewh3

legendary

Activity: 1372

Merit: 1003

I followed your instructions for the (X)ubuntu install and I2p is running but I've had no I2p connections still after running it for over two hours now Huh

intellivision

newbie

Activity: 31

Merit: 0

Quote from: giv on July 23, 2013, 08:31:42 AM

Quote from: intellivision on July 22, 2013, 10:59:12 PM

Any chance of a binary for OSX being released in the future?
I'm willing to beta test this if you need someone.

Sorry, but it's very unlikely. I don't have any Apple devices.
But you can try to build a binary from the source files. My patch doesn't add any additional dependencies, so if you can build an original client, you can build a patched client.

Well, I can't compile anything myself since I messed up GCC some time ago on this install, but you could try building it on PureDarwin (http://www.puredarwin.org/)

Also, would you consider working on a bundled Bitcoin-i2p bundle which includes both programs self contained, only uses the daemon for the wallet, and starts and stops the service when the wallet is open and closed?

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: giv on July 23, 2013, 08:31:42 AM

Quote from: intellivision on July 22, 2013, 10:59:12 PM

Any chance of a binary for OSX being released in the future?
I'm willing to beta test this if you need someone.

Sorry, but it's very unlikely. I don't have any Apple devices.

There working VMware images of various versions of OSX floating around the 'net, or so I've heard.

giv

sr. member

Activity: 254

Merit: 251

Quote from: intellivision on July 22, 2013, 10:59:12 PM

Any chance of a binary for OSX being released in the future?
I'm willing to beta test this if you need someone.

Sorry, but it's very unlikely. I don't have any Apple devices.
But you can try to build a binary from the source files. My patch doesn't add any additional dependencies, so if you can build an original client, you can build a patched client.

intellivision

newbie

Activity: 31

Merit: 0

Any chance of a binary for OSX being released in the future?
I'm willing to beta test this if you need someone.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on July 11, 2013, 02:26:46 PM

Quote from: matthewh3 on July 04, 2013, 01:58:51 PM

Now that flattr accepting funding through bitcoin have you thought of setting up a flattr profile for the project. So that the project can receive regular funding. I'd be happy to set up a subscription.

I know a little about Flattr. Can I withdraw money from Flattr in bitcoins?

I'm not sure if that's possible yet but its bitcoin friendly. Flattr is about micro-donations with subscriptions if chosen. The BTC0.0001 minimum transaction fee makes donations below BTC0.0050 pretty much pointless. So it could attract donations you'd otherwise miss out on.

giv

sr. member

Activity: 254

Merit: 251

Update 11 Jul 2013
Migrated to 0.8.3.

giv

sr. member

Activity: 254

Merit: 251

Quote from: matthewh3 on July 04, 2013, 01:58:51 PM

Now that flattr accepting funding through bitcoin have you thought of setting up a flattr profile for the project. So that the project can receive regular funding. I'd be happy to set up a subscription.

I know a little about Flattr. Can I withdraw money from Flattr in bitcoins?

matthewh3

legendary

Activity: 1372

Merit: 1003

Now that flattr accepting funding through bitcoin have you thought of setting up a flattr profile for the project. So that the project can receive regular funding. I'd be happy to set up a subscription.

giv

sr. member

Activity: 254

Merit: 251

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.

Changes from 0.8.3 mainline will be added soon.

fran2k

hero member

Activity: 784

Merit: 500

Brilliant initiative, please keep this work on.

I'm also amazed this had s so little impact on the forum. Seems like no one is using i2p.

giv

sr. member

Activity: 254

Merit: 251

Sure. I will update as soon as possible.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: giv on June 04, 2013, 05:19:11 PM

Thanks. I think my project is too raw to add to mainline. The next steps are further developing. I preparing a new release now. But it moves forward slower than I wish.

Can you at least update this patch to to 0.8.3?

giv

sr. member

Activity: 254

Merit: 251

Quote from: btc4ever on June 01, 2013, 11:43:21 PM

This is pretty neat. Thanks for your work, and I hope to see it in mainline. So what are the next steps towards that goal? Sounds like writing up a BIP and discussion on dev list. Is that happening?

Thanks. I think my project is too raw to add to mainline. The next steps are further developing. I preparing a new release now. But it moves forward slower than I wish.

giv

sr. member

Activity: 254

Merit: 251

Tunnels are OK. There are too little peers in i2p. Sometimes there are 5-7 peers, sometimes 1-2.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: giv on June 04, 2013, 04:05:49 PM

Using an old wallet.dat should be OK (if you're using the same BerkleyDB version). The problem is in a peers.dat, because I serialize ip+i2p addresses into it, but a standard client serializes ip only. That cause deadlock when the patched client trying to deserialize addresses from an old peers.dat database, and vice-versa.

That's what I meant.

So far the node is only able to maintain 1-2 native_i2p connections. Is that only because there aren't many peers to connect to, or could the number of tunnels for the i2p connection need to be adjusted?

giv

sr. member

Activity: 254

Merit: 251

Using an old wallet.dat should be OK (if you're using the same BerkleyDB version). The problem is in a peers.dat, because I serialize ip+i2p addresses into it, but a standard client serializes ip only. That cause deadlock when the patched client trying to deserialize addresses from an old peers.dat database, and vice-versa.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: giv on June 04, 2013, 05:39:29 AM

I have at least 3 i2p-connections at now. Are you sure that your i2p-router is running? What do you see in stdout and in a bitcoin log? Are you using any command line options?

I was using an old ~~wallet.dat~~ peers.dat, which was causing the deadlocks described in the OP. Now that I deleted that it's working.

giv

sr. member

Activity: 254

Merit: 251

Quote from: justusranvier on June 03, 2013, 08:46:42 PM

I have a bitcoind runnning at

Code:

7jdke2swvteso3yji3amkfidaa4ggvsngltmiucsiutmouyiphfa.b32.i2p

but I can not seem to connect to any other i2p nodes.

I have at least 3 i2p-connections at now. Are you sure that your i2p-router is running? What do you see in stdout and in a bitcoin log? Are you using any command line options?

justusranvier

legendary

Activity: 1400

Merit: 1013

I have a bitcoind runnning at

Code:

7jdke2swvteso3yji3amkfidaa4ggvsngltmiucsiutmouyiphfa.b32.i2p

but I can not seem to connect to any other i2p nodes.

btc4ever

sr. member

Activity: 321

Merit: 250

This is pretty neat. Thanks for your work, and I hope to see it in mainline. So what are the next steps towards that goal? Sounds like writing up a BIP and discussion on dev list. Is that happening?

giv

sr. member

Activity: 254

Merit: 251

Of course, if the protocol will have needed field, there will no need the service anymore.
When I wrote this patch there was no way to do that, but if protocol will be changed I will change my code and will remove the service.

Pieter Wuille

legendary

Activity: 1072

Merit: 1189

Quote from: giv on May 27, 2013, 11:32:46 AM

If I understand correctly you talking about PROTOCOL_VERSION constant in version.h.
My first thought was change version of protocol too, but I rejected this idea.
At now protocol is 70001. Let's sasy we increased version of the protocol and our protocol is 70002. But the bitcoin developers release a new version of bitcoin with protocol version 80000. So I have to increase it again, or my client will send to a vanilla client too low version and the vanilla client may reject a connection from my client. At new version I'll have to increase again and again and again...

Obviously I mean getting a extended_address into mainline (that will need a BIP and maybe a bit of discussion on bitcoin-development, though), after a certain protocol number. That doesn't mean it actually needs support for any extended address, just support for the serialization in the addr packet. I've been wanting such an extension for a while, but never did any work that would make it useful. That would also mean you're not in a completely separate I2P island, as any nodes can (but not necessarily will) relay your I2P addresses across the rest of the network.

Using the service bit doesn't actually help if you mean you can do it without coordinating with other node implementations, as there may be a point where your service bit gets used for something else. My point is that no matter what, it's better to coordinate a bit (and people aren't opposed to supporting new transport protocols, afaik), and you don't actually need a service bit for this, as it's trivially discoverable by being on a different network altogether already.

giv

sr. member

Activity: 254

Merit: 251

Quote from: Pieter Wuille on May 27, 2013, 10:07:03 AM

I don't think there's a need to use a service flag for this. We could just bump the P2P protocol version number to support extended-length addresses (though we should do things like cjdns at the same time; I'd also like to see host keys in the protocol, but that's a far larger change).

If I understand correctly you talking about PROTOCOL_VERSION constant in version.h.
My first thought was change version of protocol too, but I rejected this idea.
At now protocol is 70001. Let's sasy we increased version of the protocol and our protocol is 70002. But the bitcoin developers release a new version of bitcoin with protocol version 80000. So I have to increase it again, or my client will send to a vanilla client too low version and the vanilla client may reject a connection from my client. At new version I'll have to increase again and again and again...
Let's say we strongly increase version, for ex. 999000. At this case we don't need to increase it every time as the bitcoin developers release a new version. But there're potential vulnerability, if the bitcoin developers implement a new super feature in the protocol.
For ex., they released following code

Code:

if (pfrom->nVersion > MIN_PROTO_SUPER_FEATURE_VERSION)
{
    SendToPeerSuperFeatureInfo(pfrom);
}

where MIN_PROTO_SUPER_FEATURE_VERSION == 70001 and pfrom is my patched client. In this case my patched client send to the vanilla client version 999000 and this condition become truth and the vanilla client send to me (or wait to receive from me) some info, but I don't have this info and I don't expect it, because my client is not support this feature yet. This may cause an undefined behaviour of my client.
In any cases I have to increase version of protocol or change my code if the bitcoin developers change version of the protocol. And if I will do that ASAP, users of my patch still may not be updated for a long time and be threatened.

So I found the only way to be in safe and do not change proto version every time is a new service flag. In this case I can make automatic merging with main bitcoin tree, and don't afraid of any problems with protocol.

Pieter Wuille

legendary

Activity: 1072

Merit: 1189

I don't think there's a need to use a service flag for this. We could just bump the P2P protocol version number to support extended-length addresses (though we should do things like cjdns at the same time; I'd also like to see host keys in the protocol, but that's a far larger change).

giv

sr. member

Activity: 254

Merit: 251

Quote from: justusranvier on May 26, 2013, 03:08:17 PM

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

Yes, this patch is applicable for bitcoind. You may use my build scripts, in this case you will get bitcoin-qt and bitcoind binaries. Or you may try to build bitcoind by yourself with a make-file. See make files:
for native linux
for windows crosscompilation under linux
Use USE_NATIVE_I2P=1 flag to activate I2P functionality.
Example:

Code:

make -C bitcoin-qt/src -f makefile.unix USE_NATIVE_I2P=1

justusranvier

legendary

Activity: 1400

Merit: 1013

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

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on April 09, 2013, 07:55:30 AM

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.

K1773R

legendary

Activity: 1792

Merit: 1008

/dev/null

Quote from: giv on April 10, 2013, 01:08:44 AM

Quote from: K1773R on April 09, 2013, 02:23:34 PM

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

giv

sr. member

Activity: 254

Merit: 251

Quote from: wumpus on April 10, 2013, 12:31:35 AM

Quote from: giv on April 09, 2013, 01:02:47 PM

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.

Quote from: K1773R on April 09, 2013, 02:23:34 PM

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"?

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: giv on April 09, 2013, 01:02:47 PM

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.

K1773R

legendary

Activity: 1792

Merit: 1008

/dev/null

Quote from: giv on April 09, 2013, 07:55:30 AM

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!

giv

sr. member

Activity: 254

Merit: 251

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.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

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

sr. member

Activity: 254

Merit: 251

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

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

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

sr. member

Activity: 254

Merit: 251

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.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: giv on April 07, 2013, 03:48:28 PM

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 Huh

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 Grin

giv

sr. member

Activity: 254

Merit: 251

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

legendary

Activity: 1372

Merit: 1003

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

r.willis

jr. member

Activity: 42

Merit: 11

This is excellent. You did right thing.

giv

sr. member

Activity: 254

Merit: 251

Update 28 Mar 2013
Merged with 0.8.1

Herbert

hero member

Activity: 488

Merit: 500

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

naima53

hero member

Activity: 616

Merit: 502

English-speaking community is not interested in such a substantial improvement of BTC-client (open source)? I'm shocked. Sad

It seems that for him it was announced the bounty?

giv

sr. member

Activity: 254

Merit: 251

reserved

giv

sr. member

Activity: 254

Merit: 251

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://bitcointalksearch.org/topic/i2p-bitcoin-138588

(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\\Application data\Bitcoin (for Win XP) | C:\Users\\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= - name of an I2P session. If it is not specified, value will be "Bitcoin-client"
-samhost= - address of the SAM bridge host. If it is not specified, value will be "127.0.0.1"
-samport= - port number of the SAM bridge host. If it is not specified, value will be "7656".
-mydestination= - 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 /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

Topic: Bitcoin client with I2P patch (Read 21527 times)