Topic: Bitcoin client with I2P patch - page 4. (Read 21461 times)

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.

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.

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
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.

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).

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:

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

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.

ban blockchain.info's node

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.

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

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.

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

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.

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.

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

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.

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.

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.

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).
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 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 

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.

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

This is excellent. You did right thing.