LORD HIS EXCELLENCY JAMES HRMH [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-18 📝 Original message:The Tor team encourages ...
📅 Original date posted:2019-11-18
📝 Original message:The Tor team encourages active participating Tor nodes, preferably exit/ middle/guard nodes and not only client nodes, which is actually a significant part of the reason that the documentation I put together in Bitcoin.SE does not deal much with configuration tweaking Tor; as out of the box Tor participates actively in the Tor network.
As for applications other than web browsing, i is simply not true to suggest that Tor is implemented solely for web browsing and I suppose that this view has come about because of the Tor browser, an attempt to engage more active Tor nodes while providing an OOB privacy solution to simplify setup for the not-so-technical. As just one example of other uses, you will note the Tor configuration item `LongLivedPorts` and its implications. No, it is completely not necessary to tweak this option for Bitcoin although you may.
I encourage you to forward these comments to the Tor mailing list.
>I really don't think that the Tor network is designed and adapted to support bitcoin nodes, using it for something else than browsing is just a workaround and I would be surprised that the Tor project team contradicts this and/or encourage this use
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Monday, 18 November 2019 10:59 PM
To: Matt Corallo <lf-lists at mattcorallo.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>; Mr. Lee Chiffre <lee.chiffre at secmail.pro>
Cc: fontainedenton at googlemail.com <fontainedenton at googlemail.com>
Subject: Re: [bitcoin-dev] v3 onion services
As I briefly sketched here before I think that a better long term solution would be to link the bitcoin traffic with something like node-Tor (https://github.com/Ayms/node-Tor)
Much more light (the whole code not minified is only ~1MB), not using tons of libraries prone to security/maintenance issues, easy to use/configure/maintain and you don't need the (heavy/complicate) onions RDV concepts and addresses, which in addition is useless for bitcoin
As simple as a duplex stream bitcoin.pipe(node-Tor) inside servers or browsers (difficult to imagine full nodes and the blocks inside browsers but why not one day, so for light clients probably implementing part of the bitcoin protocol like https://peersm.com/wallet, for now it's a standalone offline webapp but of course it would be interesting to connect it in a secure way to bitcoin nodes to retrieve info from the utxo set and send txs for example since it's not obvious for users to create their txs in its current form)
This would be a separate network using the Tor protocol over TCP, WebSockets and WebRTC, making it possible also for browsers to relay the traffic, probably the nodes discovery (to get the keys) could be linked to the bitcoin peer discovery system (we just have to add the onion key to the peer profile, and maybe long term id key), anyway that's simple to setup, and probably for a p2p network 2 hops will be enough
I really don't think that the Tor network is designed and adapted to support bitcoin nodes, using it for something else than browsing is just a workaround and I would be surprised that the Tor project team contradicts this and/or encourage this use
Le 18/11/2019 à 00:42, Matt Corallo via bitcoin-dev a écrit :
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 <bitcoin-dev at lists.linuxfoundation.org><mailto:bitcoin-dev at lists.linuxfoundation.org> 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.chiffre at secmail.pro<mailto:lee.chiffre at secmail.pro>
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191118/c266cf38/attachment.html>;
📝 Original message:The Tor team encourages active participating Tor nodes, preferably exit/ middle/guard nodes and not only client nodes, which is actually a significant part of the reason that the documentation I put together in Bitcoin.SE does not deal much with configuration tweaking Tor; as out of the box Tor participates actively in the Tor network.
As for applications other than web browsing, i is simply not true to suggest that Tor is implemented solely for web browsing and I suppose that this view has come about because of the Tor browser, an attempt to engage more active Tor nodes while providing an OOB privacy solution to simplify setup for the not-so-technical. As just one example of other uses, you will note the Tor configuration item `LongLivedPorts` and its implications. No, it is completely not necessary to tweak this option for Bitcoin although you may.
I encourage you to forward these comments to the Tor mailing list.
>I really don't think that the Tor network is designed and adapted to support bitcoin nodes, using it for something else than browsing is just a workaround and I would be surprised that the Tor project team contradicts this and/or encourage this use
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Monday, 18 November 2019 10:59 PM
To: Matt Corallo <lf-lists at mattcorallo.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>; Mr. Lee Chiffre <lee.chiffre at secmail.pro>
Cc: fontainedenton at googlemail.com <fontainedenton at googlemail.com>
Subject: Re: [bitcoin-dev] v3 onion services
As I briefly sketched here before I think that a better long term solution would be to link the bitcoin traffic with something like node-Tor (https://github.com/Ayms/node-Tor)
Much more light (the whole code not minified is only ~1MB), not using tons of libraries prone to security/maintenance issues, easy to use/configure/maintain and you don't need the (heavy/complicate) onions RDV concepts and addresses, which in addition is useless for bitcoin
As simple as a duplex stream bitcoin.pipe(node-Tor) inside servers or browsers (difficult to imagine full nodes and the blocks inside browsers but why not one day, so for light clients probably implementing part of the bitcoin protocol like https://peersm.com/wallet, for now it's a standalone offline webapp but of course it would be interesting to connect it in a secure way to bitcoin nodes to retrieve info from the utxo set and send txs for example since it's not obvious for users to create their txs in its current form)
This would be a separate network using the Tor protocol over TCP, WebSockets and WebRTC, making it possible also for browsers to relay the traffic, probably the nodes discovery (to get the keys) could be linked to the bitcoin peer discovery system (we just have to add the onion key to the peer profile, and maybe long term id key), anyway that's simple to setup, and probably for a p2p network 2 hops will be enough
I really don't think that the Tor network is designed and adapted to support bitcoin nodes, using it for something else than browsing is just a workaround and I would be surprised that the Tor project team contradicts this and/or encourage this use
Le 18/11/2019 à 00:42, Matt Corallo via bitcoin-dev a écrit :
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 <bitcoin-dev at lists.linuxfoundation.org><mailto:bitcoin-dev at lists.linuxfoundation.org> 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.chiffre at secmail.pro<mailto:lee.chiffre at secmail.pro>
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191118/c266cf38/attachment.html>;