Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2016-06-28 📝 Original message:Hi Eric Sorry for not ...
📅 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>;
📝 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>;