📅 Original date posted:2016-03-27
📝 Original message:> 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?
> 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).
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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160327/0d52fd3e/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:49:58
in reply to nevent1q…zhr9
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:49:58Event JSON
{
"id": "3a8f2550c4fd1efcf195ec157821a11720bd3d74d5e63dc8ff8d4957a2e0a7b3",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160198,
"kind": 1,
"tags": [
[
"e",
"1c87d471b2f2da141b64e0a9c480b3ca53986e57331a196cd0234d6c8fb75484",
"",
"root"
],
[
"e",
"cacf5e6b890e6e585b435ed08e5f6e8ee058387f19fd26f9262fccbc7a9324ae",
"",
"reply"
],
[
"p",
"52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928"
]
],
"content": "📅 Original date posted:2016-03-27\n📝 Original message:\u003e I guess my question didn't get across.\n\u003e \n\u003e Why would you want to make your usecase do connections over the\n\u003e peer2peer\n\u003e (net.cpp) connection at all?\n\u003e \n\u003e Mixing messages that are being sent to everyone and encrypted\n\u003e messages is\n\u003e asking for trouble.\n\u003e Making your private connection out-of-band would work much better.\n\u003e \n\u003e \n\u003e I agree doing it out-of-band is the easiest solution for people who need\n\u003e this privacy right now, but I do like the idea of adding this feature as\n\u003e the number of SPV wallets is going to increase. I think the best way to\n\u003e organize things would be to give encrypted messages their own port\n\u003e number, similar to how http vs. https works.\n\nI'm not sure if different ports would make sense. I can't see a benefit\n(happy if someone can convince me).\nHow would this affect p2p address management (address relay)? Wouldn't\nthis require to extend the current address message to support two port\nnumbers?\n\n\n\u003e We don't want two networks to develop, separated by which nodes support\n\u003e encryption and which don't, so ideally nodes would rebroadcast messages\n\u003e they receive on both (encrypted and non-encrypted) channels. This would\n\u003e essentially double the required bandwidth of the network, which is\n\u003e something to think about.\n\nIt can be the same \"p2p network\". The only difference would be, that\nonce two peers has negotiated encryption, the whole traffic between\n_these two peers_, and _only_ these two pears, would be encrypted (would\n_not_ affect traffic to/from other peers).\n\nA simplified example:\n1. Peer Alice connects to peer Bob\n2. Alice asks Bob: \"lets do encrypted communication, here is my session\npubkey\"\n3. Bob also supports encryption and answers \"Yes, let's do this, here is\nmy session pubkey\"\n4. Alice tells Bob (encrypted now): \"Perfect. Here I prove that I'm\nAlice by signing the session ID with my identity pubkey\"\n5. Bob checks his \"authorized-peers\" database and look-up Alices pubkey\nand verifies the signatures.\n6. Bob tells Alice: \"Good! I trust you now Alice, here is my identity\npubkey with a signature of our session-ID\"\n7. Alice looks up Bobs pubkey in her \"known-peers\" database and verifies\nthe signature.\n8. Alice response to bob: \"Perfect. Indeed, you are Bob!\"\n---\nAt this point, the communication is encrypted and the identities has\nbeen verified (MITM protection).\n\n\n(simplified negotiation [only one-way, missing dh explanation, missing\nKDF, session-ID, cipher suite nego., missing re-keying, etc.])\n\n\n\u003c/jonas\u003e\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160327/0d52fd3e/attachment.sig\u003e",
"sig": "d27213cb54016555a4df9beacd5011bb3fb8ba854c599ebefe2bac0ec61308fca52c3feb14053fec8042866f344f1925a61ec975d1ed449cb4b129232358343f"
}