📅 Original date posted:2016-03-27
📝 Original message:On Sun, Mar 27, 2016 at 5:49 AM Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > I guess my question didn't get across.
> >
> > Why would you want to make your usecase do connections over the
> > peer2peer
> > (net.cpp) connection at all?
> >
> > Mixing messages that are being sent to everyone and encrypted
> > messages is
> > asking for trouble.
> > Making your private connection out-of-band would work much better.
> >
> >
> > I agree doing it out-of-band is the easiest solution for people who need
> > this privacy right now, but I do like the idea of adding this feature as
> > the number of SPV wallets is going to increase. I think the best way to
> > organize things would be to give encrypted messages their own port
> > number, similar to how http vs. https works.
>
> I'm not sure if different ports would make sense. I can't see a benefit
> (happy if someone can convince me).
> How would this affect p2p address management (address relay)? Wouldn't
> this require to extend the current address message to support two port
> numbers?
>
> I'm assuming clients that connect with encryption don't want to use
unencrypted connections, and are only interested in other peers that
support encryption. From their perspective, it is quite inefficient to get
a generic list of peers and then have to connect to each one searching for
those that accept encryption. If we use port numbers, we can assume any
connection that comes on the encrypted port is only interested in encrypted
communication, so a getaddr to an encrypted port would only return a list
of other encryption-capable peers.
This isn't an issue if the plan is to require all peers to support
encryption, and we assume the majority of the network will upgrade before
too long.
>
> > We don't want two networks to develop, separated by which nodes support
> > encryption and which don't, so ideally nodes would rebroadcast messages
> > they receive on both (encrypted and non-encrypted) channels. This would
> > essentially double the required bandwidth of the network, which is
> > something to think about.
>
> It can be the same "p2p network". The only difference would be, that
> once two peers has negotiated encryption, the whole traffic between
> _these two peers_, and _only_ these two pears, would be encrypted (would
> _not_ affect traffic to/from other peers).
>
>
You're right, there would not be an increase in bandwidth. Please forget I
said that :) But following the logic I wrote above, it would be possible
for peers to become segregated (those who require encryption would only
connect to each other). It wouldn't be a problem as long as there are
enough peers that provide both encrypted and non-encrypted connections; or,
as I said above, if we can assume every peer will support it. Maybe the
issues I'm thinking of are just growing pains that will be solved once the
majority of people upgrade?
> A simplified example:
> 1. Peer Alice connects to peer Bob
> 2. Alice asks Bob: "lets do encrypted communication, here is my session
> pubkey"
> 3. Bob also supports encryption and answers "Yes, let's do this, here is
> my session pubkey"
> 4. Alice tells Bob (encrypted now): "Perfect. Here I prove that I'm
> Alice by signing the session ID with my identity pubkey"
> 5. Bob checks his "authorized-peers" database and look-up Alices pubkey
> and verifies the signatures.
> 6. Bob tells Alice: "Good! I trust you now Alice, here is my identity
> pubkey with a signature of our session-ID"
> 7. Alice looks up Bobs pubkey in her "known-peers" database and verifies
> the signature.
> 8. Alice response to bob: "Perfect. Indeed, you are Bob!"
> ---
> At this point, the communication is encrypted and the identities has
> been verified (MITM protection).
>
>
> (simplified negotiation [only one-way, missing dh explanation, missing
> KDF, session-ID, cipher suite nego., missing re-keying, etc.])
>
>
> </jonas>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20160327/30bc800e/attachment.html>;
James MacWhyte [ARCHIVE] /
npub12t…pye9h
2023-06-07 17:49:59
in reply to nevent1q…mytg
Author Public Key
npub12tjaqer27049ejmvf0f3yd7kq6p93gg6ecavgrczge4rlzf59y5q2pye9hPublished at
2023-06-07 17:49:59Event JSON
{
"id": "2549c95ea69fab6f3767cbf4c002dc7cf75ef20f49b3c2d3fd0f845377a376f2",
"pubkey": "52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928",
"created_at": 1686160199,
"kind": 1,
"tags": [
[
"e",
"1c87d471b2f2da141b64e0a9c480b3ca53986e57331a196cd0234d6c8fb75484",
"",
"root"
],
[
"e",
"3a8f2550c4fd1efcf195ec157821a11720bd3d74d5e63dc8ff8d4957a2e0a7b3",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2016-03-27\n📝 Original message:On Sun, Mar 27, 2016 at 5:49 AM Jonas Schnelli via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e \u003e I guess my question didn't get across.\n\u003e \u003e\n\u003e \u003e Why would you want to make your usecase do connections over the\n\u003e \u003e peer2peer\n\u003e \u003e (net.cpp) connection at all?\n\u003e \u003e\n\u003e \u003e Mixing messages that are being sent to everyone and encrypted\n\u003e \u003e messages is\n\u003e \u003e asking for trouble.\n\u003e \u003e Making your private connection out-of-band would work much better.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e I agree doing it out-of-band is the easiest solution for people who need\n\u003e \u003e this privacy right now, but I do like the idea of adding this feature as\n\u003e \u003e the number of SPV wallets is going to increase. I think the best way to\n\u003e \u003e organize things would be to give encrypted messages their own port\n\u003e \u003e number, similar to how http vs. https works.\n\u003e\n\u003e I'm not sure if different ports would make sense. I can't see a benefit\n\u003e (happy if someone can convince me).\n\u003e How would this affect p2p address management (address relay)? Wouldn't\n\u003e this require to extend the current address message to support two port\n\u003e numbers?\n\u003e\n\u003e I'm assuming clients that connect with encryption don't want to use\nunencrypted connections, and are only interested in other peers that\nsupport encryption. From their perspective, it is quite inefficient to get\na generic list of peers and then have to connect to each one searching for\nthose that accept encryption. If we use port numbers, we can assume any\nconnection that comes on the encrypted port is only interested in encrypted\ncommunication, so a getaddr to an encrypted port would only return a list\nof other encryption-capable peers.\n\nThis isn't an issue if the plan is to require all peers to support\nencryption, and we assume the majority of the network will upgrade before\ntoo long.\n\n\n\u003e\n\u003e \u003e We don't want two networks to develop, separated by which nodes support\n\u003e \u003e encryption and which don't, so ideally nodes would rebroadcast messages\n\u003e \u003e they receive on both (encrypted and non-encrypted) channels. This would\n\u003e \u003e essentially double the required bandwidth of the network, which is\n\u003e \u003e something to think about.\n\u003e\n\u003e It can be the same \"p2p network\". The only difference would be, that\n\u003e once two peers has negotiated encryption, the whole traffic between\n\u003e _these two peers_, and _only_ these two pears, would be encrypted (would\n\u003e _not_ affect traffic to/from other peers).\n\u003e\n\u003e\nYou're right, there would not be an increase in bandwidth. Please forget I\nsaid that :) But following the logic I wrote above, it would be possible\nfor peers to become segregated (those who require encryption would only\nconnect to each other). It wouldn't be a problem as long as there are\nenough peers that provide both encrypted and non-encrypted connections; or,\nas I said above, if we can assume every peer will support it. Maybe the\nissues I'm thinking of are just growing pains that will be solved once the\nmajority of people upgrade?\n\n\n\u003e A simplified example:\n\u003e 1. Peer Alice connects to peer Bob\n\u003e 2. Alice asks Bob: \"lets do encrypted communication, here is my session\n\u003e pubkey\"\n\u003e 3. Bob also supports encryption and answers \"Yes, let's do this, here is\n\u003e my session pubkey\"\n\u003e 4. Alice tells Bob (encrypted now): \"Perfect. Here I prove that I'm\n\u003e Alice by signing the session ID with my identity pubkey\"\n\u003e 5. Bob checks his \"authorized-peers\" database and look-up Alices pubkey\n\u003e and verifies the signatures.\n\u003e 6. Bob tells Alice: \"Good! I trust you now Alice, here is my identity\n\u003e pubkey with a signature of our session-ID\"\n\u003e 7. Alice looks up Bobs pubkey in her \"known-peers\" database and verifies\n\u003e the signature.\n\u003e 8. Alice response to bob: \"Perfect. Indeed, you are Bob!\"\n\u003e ---\n\u003e At this point, the communication is encrypted and the identities has\n\u003e been verified (MITM protection).\n\u003e\n\u003e\n\u003e (simplified negotiation [only one-way, missing dh explanation, missing\n\u003e KDF, session-ID, cipher suite nego., missing re-keying, etc.])\n\u003e\n\u003e\n\u003e \u003c/jonas\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160327/30bc800e/attachment.html\u003e",
"sig": "d963c1f34857051711f880115bba8f7f0f4b0b8f82e6a31b9ae19a2e94247c61d78773a09837d3f269c682b1d6e85c6eb85161f9760f8891ac1d02bc0b4a32f9"
}