📅 Original date posted:2014-01-15
📝 Original message:>
> 2) Secondly, we bump the protocol version, add a service flag and
> introduce a new P2P protocol command “tor?”. If a client sends a tor?
> message to a node that has the new service flag set, it will respond with a
> new “tor” message that contains a regular addr packet, with a single
> address, the IPv6-ified version of its hidden service name.
>
Rather than a separate message type that implies binding a clearnet IP to a
hidden service ID, why not add the service flag that the peer would like
Tor addresses, and the remote peer can then add IPv6-ified hidden service
addresses to "addr" messages? May need to modify the network address format
to include the ability to differentiate IPv6 clearnet vs. Tor addresses,
but then you remove the implication that a node has to give both public and
private IPs to a peer. If it's part of a batch of "addr"s, it could be my
own hidden service ID, but it could also be one that I learned from someone
else and is now propagating, for anyone to bootstrap with Tor hidden
service peers if they'd like.
Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140115/2f39ea14/attachment.html>;
Brooks Boyd [ARCHIVE] /
npub12h…vtmxa
2023-06-07 15:12:08
in reply to nevent1q…a9wu
Author Public Key
npub12hzwfhx9ptjf2f0va8qllc0h4tcvz5aaefvlvn9uq8z2ssrq027qtvtmxaPublished at
2023-06-07 15:12:08Event JSON
{
"id": "0166f84b46b172d38662eedfbedd0eca0d9ab4ad38abe16c8c77ec8b29780c70",
"pubkey": "55c4e4dcc50ae49525ece9c1ffe1f7aaf0c153bdca59f64cbc01c4a840607abc",
"created_at": 1686150728,
"kind": 1,
"tags": [
[
"e",
"611ceaa526b00a1109fcff43c9c84b86475a1a1e055ca0ce884283c7fc0d8b94",
"",
"root"
],
[
"e",
"40d9d263d00663e99198520cc91b85ed0f6e88018eed16a64764fc40efbbee0b",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-01-15\n📝 Original message:\u003e\n\u003e 2) Secondly, we bump the protocol version, add a service flag and\n\u003e introduce a new P2P protocol command “tor?”. If a client sends a tor?\n\u003e message to a node that has the new service flag set, it will respond with a\n\u003e new “tor” message that contains a regular addr packet, with a single\n\u003e address, the IPv6-ified version of its hidden service name.\n\u003e\n\n\nRather than a separate message type that implies binding a clearnet IP to a\nhidden service ID, why not add the service flag that the peer would like\nTor addresses, and the remote peer can then add IPv6-ified hidden service\naddresses to \"addr\" messages? May need to modify the network address format\nto include the ability to differentiate IPv6 clearnet vs. Tor addresses,\nbut then you remove the implication that a node has to give both public and\nprivate IPs to a peer. If it's part of a batch of \"addr\"s, it could be my\nown hidden service ID, but it could also be one that I learned from someone\nelse and is now propagating, for anyone to bootstrap with Tor hidden\nservice peers if they'd like.\n\nBrooks\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140115/2f39ea14/attachment.html\u003e",
"sig": "ba00c45aa77189242e30ad48c8c59df28d87f194be848a2741ed452796c405478ad11c1fbba38c9cbb66e9b590472b6347c5cca9436f81fbb8814ec883a6f041"
}