Re: [bitcoin-dev] v3 onion services
There is effort ongoing to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. There are various posts on this ML under the title “addrv2”. Further review and contributions to that effort is, as always, welcome. > On Nov 17, 2019, at 00:05, Mr. Lee Chiffre via bitcoin-dev > wrote: > > Right now bitcoin client core supports use of tor hidden service. It > supports v2 hidden service. I am in progress of creating a new bitcoin > node which will use v3 hidden service instead of v2. I am looking at > bitcoin core and btcd to use. Do any of these or current node software > support the v3 onion addresses for the node address? What about I2P > addresses? If not what will it take to get it to support the longer > addresses that is used by i2p and tor v3? > > > -- > lee.chif...@secmail.pro > PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] v3 onion services
Blockchain Commons is using v3 tor authentication for remote clients controlling a full node created using our Bitcoin Standup project (currently only macOS but more platforms coming): https://github.com/BlockchainCommons/Bitcoin-Standup Docs at: https://github.com/BlockchainCommons/Bitcoin-Standup#tor-v3-authentication-using-standup-and-fullynoded Video demonstrating securing remote connection of a full node to the iOS wallet Fully Noded: https://youtu.be/pSm2VftTCBI More details on v3 authentication at: https://github.com/AnarchoTechNYC/meta/wiki/Connecting-to-an-authenticated-Onion-service#connecting-to-authenticated-version-3-onion-services — Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] v3 onion services
For those perhaps not so well versed in the operation of Bitcoin (and Bitcoin Core) with Tor, connectivity through the outgoing connection to other nodes is all accomplished via the socks5 proxy which enables all current gossip and the distribution of the nodes own transactions to other nodes. This is a full connectivity feature. For listening, Bitcoin Core instructs Tor to create an ephemeral hidden service which, depending on the various factors, may be currently v2 only or v3 (future implementation). This is not necessary for the functionality of node connectivity in any way and is only used to allow for hidden listening so that other nodes connecting out on the onion can connect privately without hopping on the public internet at all and without exposing the nodes public IP or ports as listening (no port forwarding required and no listing on nodes list with public IP). It is currently possible for many nodes to exist as onion only nodes. For the time being, although I did wonder myself, the use of v3 ephemeral service is not a requirement of operation on Bitcoin and hardly adds anything to security especially if we enable transient onion listening (a feature proposal is currently waiting for consideration/approval on bitcoin-core-dev and GitHub), however, eventually it will be essential to make use of the v3 ephemeral service as the v2 service support will, as I understand, eventually be dropped from the Tor network. I do not know if there are any current distinct plans. My opinion is, v3 support is a nice idea but hardly urgent yet. Good luck if it ends up with an ack as I suspect some of the changes required will be complex and this may be perhaps the best reason to begin on it while there is interest. Regards, LORD HIS EXCELLENCY JAMES HRMH From: bitcoin-dev on behalf of s7r via bitcoin-dev Sent: Monday, 18 November 2019 2:35 AM To: Mr. Lee Chiffre ; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] v3 onion services Mr. Lee Chiffre via bitcoin-dev wrote: > Right now bitcoin client core supports use of tor hidden service. It > supports v2 hidden service. I am in progress of creating a new bitcoin > node which will use v3 hidden service instead of v2. I am looking at > bitcoin core and btcd to use. Do any of these or current node software > support the v3 onion addresses for the node address? What about I2P > addresses? If not what will it take to get it to support the longer > addresses that is used by i2p and tor v3? > > Hello, Yes, that is correct. Currently at present moment only v2 onion services are supported. Bitcoin Core is limited at 128 bit 'addresses' in the p2p protocol, so it requires a rework of the p2p protocol. v3 onion services are whole ed25519 public keys, base32 encoded with .onion at the end. Same reason applies to I2P 'address types' as well. However, I am not an expert in I2P and don't actually know how many bitcoin full nodes might exist in I2P. See: https://github.com/bitcoin/bitcoin/issues/9214 https://github.com/bitcoin/bitcoin/issues/2091 For the default `ADD_ONION` feature, the onion service key was downgraded to explicitly RSA1024 (legacy, v2 onion services) to ensure the feature still works out of the box: https://github.com/bitcoin/bitcoin/pull/9234 If you want a Tor only full node, you are best to use v2 onion services for now. Why do you need the bitcoin node to explicitly have a v3 onion address? You can have a service that is accessible to the general public as a v3 onion service, and in the back uses a bitcoin full node that uses v2 onion service to talk to other nodes. The v2 onion service bitcoin network is extended fairly. You can use in the same torrc (Tor configuration file), implicitly same Tor process/daemon simultaneously v2 and v3 onion services by setting HiddenServiceVersion parameter after every HiddenServiceDir parameter. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] v3 onion services
Mr. Lee Chiffre via bitcoin-dev wrote: > Right now bitcoin client core supports use of tor hidden service. It > supports v2 hidden service. I am in progress of creating a new bitcoin > node which will use v3 hidden service instead of v2. I am looking at > bitcoin core and btcd to use. Do any of these or current node software > support the v3 onion addresses for the node address? What about I2P > addresses? If not what will it take to get it to support the longer > addresses that is used by i2p and tor v3? > > Hello, Yes, that is correct. Currently at present moment only v2 onion services are supported. Bitcoin Core is limited at 128 bit 'addresses' in the p2p protocol, so it requires a rework of the p2p protocol. v3 onion services are whole ed25519 public keys, base32 encoded with .onion at the end. Same reason applies to I2P 'address types' as well. However, I am not an expert in I2P and don't actually know how many bitcoin full nodes might exist in I2P. See: https://github.com/bitcoin/bitcoin/issues/9214 https://github.com/bitcoin/bitcoin/issues/2091 For the default `ADD_ONION` feature, the onion service key was downgraded to explicitly RSA1024 (legacy, v2 onion services) to ensure the feature still works out of the box: https://github.com/bitcoin/bitcoin/pull/9234 If you want a Tor only full node, you are best to use v2 onion services for now. Why do you need the bitcoin node to explicitly have a v3 onion address? You can have a service that is accessible to the general public as a v3 onion service, and in the back uses a bitcoin full node that uses v2 onion service to talk to other nodes. The v2 onion service bitcoin network is extended fairly. You can use in the same torrc (Tor configuration file), implicitly same Tor process/daemon simultaneously v2 and v3 onion services by setting HiddenServiceVersion parameter after every HiddenServiceDir parameter. signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
