📅 Original date posted:2016-03-26
📝 Original message:On Sat, Mar 26, 2016 at 1:34 AM Tom via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Friday 25 Mar 2016 19:43:00 Jonas Schnelli via bitcoin-dev wrote:
> > An encrypted channel together with a trusted full node would finally
> > allow to have a secure and save SPV communication.
>
> 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.
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.
> > > Also, you didn't actually address the attack-vector.
> >
> > Which attack-vector?
>
> The statistical attack I mentioned earlier. Which comes from knowing which
> plain text messages are being sent over the encrypted channel, So as long
> as
> you keep saying you want to encrypt data that identical copies of are being
> sent to other nodes at practically the same time, you will keep being
> vulnerable to that.
>
>
> _______________________________________________
> 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/20160326/e2a0f1f0/attachment.html>;
James MacWhyte [ARCHIVE] /
npub12t…pye9h
2023-06-07 17:49:58
in reply to nevent1q…gk5g
Author Public Key
npub12tjaqer27049ejmvf0f3yd7kq6p93gg6ecavgrczge4rlzf59y5q2pye9hPublished at
2023-06-07 17:49:58Event JSON
{
"id": "cacf5e6b890e6e585b435ed08e5f6e8ee058387f19fd26f9262fccbc7a9324ae",
"pubkey": "52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928",
"created_at": 1686160198,
"kind": 1,
"tags": [
[
"e",
"1c87d471b2f2da141b64e0a9c480b3ca53986e57331a196cd0234d6c8fb75484",
"",
"root"
],
[
"e",
"aaa9e258377a25973906e715eaf6ca2058e1e8acf1b5b339f989c206accac4a8",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2016-03-26\n📝 Original message:On Sat, Mar 26, 2016 at 1:34 AM Tom via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Friday 25 Mar 2016 19:43:00 Jonas Schnelli via bitcoin-dev wrote:\n\u003e \u003e An encrypted channel together with a trusted full node would finally\n\u003e \u003e allow to have a secure and save SPV communication.\n\u003e\n\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 peer2peer\n\u003e (net.cpp) connection at all?\n\u003e\n\u003e Mixing messages that are being sent to everyone and encrypted messages is\n\u003e asking for trouble.\n\u003e Making your private connection out-of-band would work much better.\n\u003e\n\u003e\nI agree doing it out-of-band is the easiest solution for people who need\nthis privacy right now, but I do like the idea of adding this feature as\nthe number of SPV wallets is going to increase. I think the best way to\norganize things would be to give encrypted messages their own port number,\nsimilar to how http vs. https works.\n\nWe don't want two networks to develop, separated by which nodes support\nencryption and which don't, so ideally nodes would rebroadcast messages\nthey receive on both (encrypted and non-encrypted) channels. This would\nessentially double the required bandwidth of the network, which is\nsomething to think about.\n\n\n\u003e \u003e \u003e Also, you didn't actually address the attack-vector.\n\u003e \u003e\n\u003e \u003e Which attack-vector?\n\u003e\n\u003e The statistical attack I mentioned earlier. Which comes from knowing which\n\u003e plain text messages are being sent over the encrypted channel, So as long\n\u003e as\n\u003e you keep saying you want to encrypt data that identical copies of are being\n\u003e sent to other nodes at practically the same time, you will keep being\n\u003e vulnerable to that.\n\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/20160326/e2a0f1f0/attachment.html\u003e",
"sig": "d356f86778abb286e8faca50edf8945fa3e87ef6cd806191214ba23d3f16dafec81a538a3d1aab520f81d4c71d2bfced041b600f670f890b2bcd840bc341d8f9"
}