Why use Elligator Swift Encoding in BIP 324?

External question — Bitcoin Stack Exchange Author: Bala Original post: https://bitcoin.stackexchange.com/questions/130887 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. What is the reason for using Elligator Swift encoding in BIP-324? I gather that it is used to prevent fingerprinting. Is there any other reason?

External answer — Bitcoin Stack Exchange Author: Pieter Wuille Original post: https://bitcoin.stackexchange.com/a/130888 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I gather that it is used to prevent fingerprinting. Is there any other reason ? Indeed. The goal is raising the cost of automatic filtering of Bitcoin connections, and providing the ability (though unused for now), or at least simplify, make the protocol mimic another protocol (e.g. HTTPS), also called "parroting". From BIP-324 : In addition, the bytestream on the wire is made pseudorandom (i.e., indistinguishable from uniformly random bytes) to a passive eavesdropper. ... A pseudorandom bytestream excludes identification techniques based on pattern matching, and makes it easier to shape the bytestream in order to mimic other protocols used on the Internet. This raises the cost of a connection censoring firewall, forcing them to either resort to a full MitM attack, or operate on a more obvious allowlist basis, rather than a blocklist basis. And: Why have a pseudorandom bytestream when traffic analysis is still possible? Traffic analysis, e.g., observing packet lengths and timing, as well as active attacks can still reveal that the Bitcoin v2 P2P protocol is in use. Nevertheless, a pseudorandom bytestream raises the cost of fingerprinting the protocol substantially, and may force some intermediaries to attack any protocol they cannot identify, causing collateral cost. A pseudorandom bytestream is not self-identifying. Moreover, it is unopinionated and thus a canonical choice for similar protocols. As a result, Bitcoin P2P traffic will be indistinguishable from traffic of other protocols which make the same choice (e.g., obfs4 and a recently proposed cTLS extension). Moreover, traffic shapers and protocol wrappers (for example, making the traffic look like HTTPS or SSH) can further mitigate traffic analysis and active attacks but are out of scope for this proposal.