most recent 30 from bitcoin.stackexchange.com 2025-08-06T08:28:10Z https://bitcoin.stackexchange.com/feeds/question/119369 https://creativecommons.org/licenses/by-sa/4.0/rdf https://bitcoin.stackexchange.com/q/119369 4 Loopite https://bitcoin.stackexchange.com/users/133916 2025-08-06T09:53:24Z 2025-08-06T14:06:51Z

<p>I recently saw the <a href="https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki" rel="nofollow noreferrer">BIP 324</a> proposal. It shows us there can be some privacy enhancement by using ECDH secrets and encryption algorithms such as ChaCha20 and AEAD-ChaCha20-Poly1305. The proposal includes:</p> <ul> <li>The length decriptor size is reduced to 3 Bytes.</li> <li>The command could be expressed as an ID (1 Byte) OR as characters (13 Bytes, by including the 0x00 byte selector).</li> </ul> <ol> <li>However, I don't fully understand <strong>the order</strong> in data will be structured. Can it be explained ?</li> <li>What algorithm will be applied to which data structure ? Because I can suppose the ChaCha20 is used in order to encrypt the payload size and AEAD-ChaCha20-Poly1305 to encrypt payload.</li> </ol>

https://bitcoin.stackexchange.com/questions/119369/bip324-encrypted-packet-structure/119372#119372 5 Pieter Wuille https://bitcoin.stackexchange.com/users/208 2025-08-06T13:37:17Z 2025-08-06T14:06:51Z

<p>In the new P2P transport protocol proposed in BIP324, after the handshake (which among other things establishes encryption keys), packets have the following structure:</p> <ul> <li>A 3-byte <strong>length descriptor</strong> (encrypted with FSChaCha20)</li> <li>An arbitrary-length <strong>ciphertext</strong> which is the encryption of a plaintext (encrypted with FSChaCha20Poly1305, which expands the data by 16 bytes in the process by adding a <a href="https://datatracker.ietf.org/doc/html/rfc8439#section-2.5" rel="nofollow noreferrer">Poly1305</a> authentication tag); the plaintext consists of: <ul> <li>A 1-byte <strong>header</strong> (which is used for signalling decoy data)</li> <li>A variable-length <strong>contents</strong> (whose length is described by the length descriptor). The contents consists of: <ul> <li>A 1-byte or 13-byte <strong>message type</strong> (e.g. version, verack, tx, inv, ...).</li> <li>A variable-length <strong>payload</strong> (the actual data sent in the message).</li> </ul> </li> </ul> </li> </ul> <p>So if you want everything flattened out, you get:</p> <ul> <li>3-byte encrypted length descriptor</li> <li>1-byte encrypted header</li> <li>1-byte or 13-byte encrypted message type</li> <li>variable length encrypted payload</li> <li>16-byte Poly1305 authentication tag</li> </ul> <p>However, only 2 separate encryption algorithm invocations are used per packet:</p> <ul> <li>The 3-byte length is encrypted using <a href="https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#rekeying-wrappers-fschacha20poly1305-and-fschacha20" rel="nofollow noreferrer">FSChaCha20</a>, which is a variant of the <a href="https://datatracker.ietf.org/doc/html/rfc8439#section-2.4" rel="nofollow noreferrer">ChaCha20 stream cipher</a> that rekeys every 224 messages.</li> <li>The header, message type, and payload are all encrypted together at once using <a href="https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#rekeying-wrappers-fschacha20poly1305-and-fschacha20" rel="nofollow noreferrer">FSChaCha20Poly1305</a>, which is a variant of the <a href="https://datatracker.ietf.org/doc/html/rfc8439#section-2.8" rel="nofollow noreferrer">ChaCha20Poly1305 AEAD</a> which rekeys every 224 messages.</li> </ul>

百度