Bitcoin client with I2P patch

[giv]

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

[Pieter Wuille]

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]

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]

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]

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.

[btc4ever]

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?

[justusranvier]

I have a bitcoind runnning at

Code:

7jdke2swvteso3yji3amkfidaa4ggvsngltmiucsiutmouyiphfa.b32.i2p

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

[giv]

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]

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]

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]

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]

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

[giv]

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.

[justusranvier]

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]

Sure. I will update as soon as possible.

[fran2k]

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]

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.

[matthewh3]

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]

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?

[giv]

Update 11 Jul 2013
Migrated to 0.8.3.