BIP324 (P2P encryption) was merged

[Kruw]

This is an exciting non consensus level upgrade that makes Bitcoin much more robust against nation state level attacks.  Before, it was transparent to your ISP that you are using Bitcoin because of how it talks to other nodes.  With the new v2 P2P protocol version, your traffic is encrypted and uses a pseudorandom pattern.

This proposal aims to achieve the following properties:

    Confidentiality against passive attacks: A passive attacker having recorded a v2 P2P bytestream (without timing and fragmentation information) must not be able to determine the plaintext being exchanged by the nodes.
    Observability of active attacks: A session ID identifying the encrypted channel uniquely is derived deterministically from a Diffie-Hellman negotiation. An active man-in-the-middle attacker is forced to incur a risk of being detected as peer operators can compare session IDs manually, or using optional authentication methods possibly introduced in future protocol versions.
    Pseudorandom bytestream: A passive attacker having recorded a v2 P2P bytestream (without timing information and fragmentation information) must not be able to distinguish it from a uniformly random bytestream.
    Shapable bytestream: It should be possible to shape the bytestream to increase resistance to traffic analysis (for example, to conceal block propagation), or censorship avoidance.[4]
    Forward secrecy: An eavesdropping attacker who compromises a peer's sessions secrets should not be able to decrypt past session traffic, except for the latest few packets.
    Upgradability: The proposal provides an upgrade path using transport versioning which can be used to add features like authentication, PQC handshake upgrade, etc. in the future.
    Compatibility: v2 clients will allow inbound v1 connections to minimize risk of network partitions.
    Low overhead: the introduction of a new P2P transport protocol should not substantially increase computational cost or bandwidth for nodes that implement it, compared to the current protocol.

https://github.com/bitcoin/bitcoin/pull/28331

[1714303643]

1714303643

[1714303643]

1714303643

[1714303643]

1714303643

[Faisal2202]

Did not know about this upgrade, but now due to this topic, I realize how important BPI324 is. As I did some research on my own. And found out it is still under development from 2019 and if it really has that much potential then I hope it will be completed soon. But the funny thing is, I am not a Core user or a node user, or have to do anything with validations, conformation, miner, etc. Just saying.

But still, it will help the overall ecosystem of BTC and it will help the users like me. I will bookmark this, for further knowledge that others will post here.

[hugeblack]

we finally has a https-like encryption to Bitcoin  

The most important development in my opinion is that by relying on the session ID, we will have guaranteed that there is no malicious man-in-the-middle by matching the ID with the real user, in addition to the possibility of adding future authentication pairs and increasing the risk of knowing about the passive attack.

Did not know about this upgrade, but now due to this topic, I realize how important BPI324 is. As I did some research on my own. And found out it is still under development from 2019 and if it really has that much potential then I hope it will be completed soon. But the funny thing is, I am not a Core user or a node user, or have to do anything with validations, conformation, miner, etc. Just saying.

But still, it will help the overall ecosystem of BTC and it will help the users like me. I will bookmark this, for further knowledge that others will post here.

 1) You or anyone can submit a BIP proposal and some discussion about it is captured and published in the Bitcoin Core GitHub and only then needs approval and implementation.
 2) Approval may take some time and many stages of experimentation and implementation, for example https://github.com/bitcoin/bitcoin/pull/28374
 3) Then it will either be withdrawn or rejected. For example, in the past there was earlier BIP-151, which was withdrawn when BIP324 was added.
 4) according to Improvement, whether it is compatible with the old nodes and here is a softfork or not, and we need a hardfork that will determine the execution time.
 5) it is implemented in some wallets to reach a large part of Softwares

For example, even the BIP 39 upgrade (mnemonic backup aka wallet seeds) is not used by Bitcoin Core.

[Hamza2424]

That's good news, now there's less reliance towards Tor and VPN to hide Bitcoin traffic. Although looking at https://bip324.com, which now redirect to https://github.com/bitcoin/bitcoin/issues/27634 shows there are few unmerged PR.

we finally has a https-like encryption to Bitcoin 

With small exception lack of SSL/TLS certificate due to Bitcoin decentralized nature.

Hmm, on the stairs of Privacy, A good development but in mitigating this risk VPN & Tor can be considerable still, using a full node on the priority can be more helpful and people ignore the mixing service most of the time while going through the transaction Mixers can boost your privacy rate, I don't think so their service costs much.

I think it's very important for privacy-conscious Bitcoin users to be aware of the risks of data breaches. Any sort of data breach can be used to track a user's Bitcoin transactions and identify their holdings. This could have serious privacy implications, so safety comes first, as it could allow attackers to target users for theft or other forms of harm. Don't let be yourself a target. 

[DaveF]

With small exception lack of SSL/TLS certificate due to Bitcoin decentralized nature.

That is always going to be the issue isn't it.

Either you have to trust someone and at that point you loose decentralization or you have to accept the fact that some things may be very difficult to the point of not being able to be done in a way that the average user can deal with.

Perhaps a namecoin like decentralized registry? But, that would
1) cost money
2) add a ton of complexity
3) add more bloat to the code
4) add more tx to the mempool / require more storage for the blockchain.

So although it would work, it's about as far from a good idea as you can get.

-Dave

[BlackHatCoiner]

This is good, but it shouldn't be considered equivalent to Tor. If Bitcoin is "banned" or whatever-- forbidden in general in your country, then you should absolutely not choose that over Tor. Just because the ISP cannot see the content you're sending over, it doesn't mean it can't figure out which IP addresses belong to Bitcoin nodes and make out you're running Bitcoin. This is trivial to do by recursively finding all reachable bitcoin nodes with getaddr.

[franky1]

nodes still ping/announce themselves in cleartext useragent data. advertising that they are a bitcoin node publicly..(they will still be accepting v1 connections).. meaning ISP's can still see who has a node. its just ISPs wont (for users that enable this feature) see what block/tx data is being relayed on the outbound but still able to see the data on the inbound

also the funny part is for some who complain(falsely) about bitcoin being broke because of data broadcast amounts per month/computational resources used by a node, this feature actually uses more data and computation resources. so this also means if devs are happy to send more bloat per message, then the concern for network data loads/computation is not a big deal, compared to what certain people pretend..

[Weezenhofnar]

"Wow, this upgrade is totally mind-blowing!  It's like Bitcoin leveling up to superhero status against nation state snooping! The old way, your ISP could sniff out your Bitcoin moves, but now, with v2 P2P protocol, it's all super-secret squirrel stuff.  Encrypting traffic and going all pseudorandom - that's some next-level ninja tech right there!  Love how Bitcoin keeps evolving, making it tough for the big players to mess around. Kudos to the devs!

[DaveF]

IMO relying on external system (namecoin) should be avoided. Storing such registration data (e.g. self-signed cert and associated IP) should be stored on blockchain, even if it bloat Bitcoin mempool.

I was not saying use namecoin, but incorporate something LIKE namecoin naming system into BTC so you could get ETFbitcoin.btc and sign something that shows your node(s) are yours.
But, the code bloat would be BEYOND crazy so it's not worth it at the moment.

I'm sure there is a way to do this and that people are working on it as we discuss it. But, who knows how long it will take.

Tossing ideas around is still fun.

-Dave

[Kruw]

"Wow, this upgrade is totally mind-blowing!  It's like Bitcoin leveling up to superhero status against nation state snooping! The old way, your ISP could sniff out your Bitcoin moves, but now, with v2 P2P protocol, it's all super-secret squirrel stuff.  Encrypting traffic and going all pseudorandom - that's some next-level ninja tech right there!  Love how Bitcoin keeps evolving, making it tough for the big players to mess around. Kudos to the devs!

Yes, I suppose I could have made the OP text more exciting, but P2P networking is not an area I'm especially knowledgeable in.