Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2016-06-28 📝 Original message:Hi Eric > I haven't seen ...
📅 Original date posted:2016-06-28
📝 Original message:Hi Eric
> I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it.
>
> 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).
>
> 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.
>
> 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.
In my opinion, the question should be "why would you _not_ encrypt".
1) Transaction censorship
ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed
transactions. Regardless if you are a miner or a validation/wallet node.
2) Peer censorship
MITM can remove or add entries from a "addr" message.
3) Fingerprinting
ISPs or any other MITM can intercept/inject fingerprinting relevant
messages like "mempool" to analyze the bitcoin network.
4) SPV
For obvious reasons regarding BF (see BIP or above).
5) Goundwork for a "client-server" model over the P2P channel
Fee estimation, bloom-filters, or any other message type that requires
authentication.
I would not reduce BIP151 to only solve the BF privacy/censorship problem.
If we agree that censorship-resistance is one of the main properties of
Bitcoin, then we should definitively use a form of end-to-end encryption
between nodes. Built into the network layer.
There are plenty of other options to solve this problem. stunnel,
Bernsteins CurveCP, VPN, etc. which are available since years.
But the reality has shown that most bitcoin traffic is still unencrypted.
Example: IIRC non of the available SPV wallets can "speak" on of the
possible encryption techniques. Encrypting traffic below the application
layer is extremely hard to set up for non-experienced users.
On top of that, encryption allows us to drop the SHA256 checksum per p2p
message which should result in a better performance on the network layer
once BIP151 is deployed.
I agree that BIP151 _must_ be deployed together with an authentication
scheme (I'm working on that) to protect again MITM during encryption
initialization.
---
</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/4b67008b/attachment.sig>;
📝 Original message:Hi Eric
> I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it.
>
> 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).
>
> 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.
>
> 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.
In my opinion, the question should be "why would you _not_ encrypt".
1) Transaction censorship
ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed
transactions. Regardless if you are a miner or a validation/wallet node.
2) Peer censorship
MITM can remove or add entries from a "addr" message.
3) Fingerprinting
ISPs or any other MITM can intercept/inject fingerprinting relevant
messages like "mempool" to analyze the bitcoin network.
4) SPV
For obvious reasons regarding BF (see BIP or above).
5) Goundwork for a "client-server" model over the P2P channel
Fee estimation, bloom-filters, or any other message type that requires
authentication.
I would not reduce BIP151 to only solve the BF privacy/censorship problem.
If we agree that censorship-resistance is one of the main properties of
Bitcoin, then we should definitively use a form of end-to-end encryption
between nodes. Built into the network layer.
There are plenty of other options to solve this problem. stunnel,
Bernsteins CurveCP, VPN, etc. which are available since years.
But the reality has shown that most bitcoin traffic is still unencrypted.
Example: IIRC non of the available SPV wallets can "speak" on of the
possible encryption techniques. Encrypting traffic below the application
layer is extremely hard to set up for non-experienced users.
On top of that, encryption allows us to drop the SHA256 checksum per p2p
message which should result in a better performance on the network layer
once BIP151 is deployed.
I agree that BIP151 _must_ be deployed together with an authentication
scheme (I'm working on that) to protect again MITM during encryption
initialization.
---
</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/4b67008b/attachment.sig>;