📅 Original date posted:2016-06-28
📝 Original message:Hi Eric
Sorry for not directly addressing your points.
I try to be more precise in this follow up email:
> I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
I think the bloom filter SPV usecase is not "pure client-server". SPV
clients could request from/broadcast to multiple "trusted nodes".
Trusted nodes could be nodes where the operators have shared
identities/keys in advance over a different channel.
Further private p2p extensions (lets say a p2p form of the estimatefee
command) are something which needs to be discussed first and not
something that is encouraged or outlined in BIP151.
> It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.
I don't see reasons why BIP151 could weaken the security of the P2P
network. Can you point out some specific concerns?
> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.
BIP151 does not rely on identities. BIP151 does not use persisted keys
(only ephemeral keys). The authentication/identity system needs to be
described in a another BIP.
But correct, BIP151 without a form of authentication/identity management
is vulnerable to all sorts of MITM attacks and that's why I think BIP151
must be deployed together with an p2p authentication scheme.
Scope creeping and the risks of overspecifying is the main reason to
focus on the "pure encryption part" in BIP151.
Thanks
---
</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/20160628/404f4808/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:51:49
in reply to nevent1q…zgqv
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:51:49Event JSON
{
"id": "e704b2202929964634b984464c40bf410f38e96764386c79042116516067443c",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160309,
"kind": 1,
"tags": [
[
"e",
"d0e8bb25d553b30c0cc0d96d85855c267cf10b5981dd5042024df41c59046cbd",
"",
"root"
],
[
"e",
"caa45d64a15737f4875f854baab8d6bf33b7ca1bc14d4a78c30c0d460ae87486",
"",
"reply"
],
[
"p",
"62dd2acf551a4b84c7633b4123d4143c9fa10f2f194ac4d1f7a942e5b49c6e4d"
]
],
"content": "📅 Original date posted:2016-06-28\n📝 Original message:Hi Eric\n\nSorry for not directly addressing your points.\nI try to be more precise in this follow up email:\n\n\u003e I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).\n\nI think the bloom filter SPV usecase is not \"pure client-server\". SPV\nclients could request from/broadcast to multiple \"trusted nodes\".\nTrusted nodes could be nodes where the operators have shared\nidentities/keys in advance over a different channel.\n\nFurther private p2p extensions (lets say a p2p form of the estimatefee\ncommand) are something which needs to be discussed first and not\nsomething that is encouraged or outlined in BIP151.\n\n\u003e It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.\n\nI don't see reasons why BIP151 could weaken the security of the P2P\nnetwork. Can you point out some specific concerns?\n\n\n\u003e The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.\n\nBIP151 does not rely on identities. BIP151 does not use persisted keys\n(only ephemeral keys). The authentication/identity system needs to be\ndescribed in a another BIP.\nBut correct, BIP151 without a form of authentication/identity management\nis vulnerable to all sorts of MITM attacks and that's why I think BIP151\nmust be deployed together with an p2p authentication scheme.\n\nScope creeping and the risks of overspecifying is the main reason to\nfocus on the \"pure encryption part\" in BIP151.\n\nThanks\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/20160628/404f4808/attachment.sig\u003e",
"sig": "59a5bcb66b1d87af0399068795f87323d9025fa60268dd18f454a1c442d7a6aa5852360ccc07ec1337e00fd46a6a6e3dd9f10453d5c22574bdaf0ad8271d4725"
}