BIP 0324 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/83a1afd985984862/bip-0324.mediawiki

2024-10-09T19:18:59Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/83a1afd985984862/bip-0324.mediawiki

← Older revision		Revision as of 19:18, 9 October 2024
Line 11:		Line 11:
	Pieter Wuille <bitcoin-dev@wuille.net>		Pieter Wuille <bitcoin-dev@wuille.net>
	Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0324		Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0324
	Status: ~~Draft~~		Status: Final
	Type: Standards Track		Type: Standards Track
	Created: 2019-03-08		Created: 2019-03-08
Line 388:		Line 388:
	# Receive, decode, and ignore version packet.		# Receive, decode, and ignore version packet.
	# This includes skipping decoys and authenticating the received garbage.		# This includes skipping decoys and authenticating the received garbage.
	v2_receive_packet(peer, aad=received_garbage)		v2_receive_packet(peer, aad=received_garbage[:-16])
	return		return
	else:		else:

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/e918b50731397872/bip-0324.mediawiki

2023-09-29T08:04:34Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/e918b50731397872/bip-0324.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/7004ad1a825a0422/bip-0324.mediawiki

2023-09-21T01:56:40Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/7004ad1a825a0422/bip-0324.mediawiki

← Older revision		Revision as of 01:56, 21 September 2023
Line 116:		Line 116:
	#** May send up to 4095<ref name="why_4095_garbage">'''How was the limit of 4095 bytes garbage chosen?''' It is a balance between having sufficient freedom to hide information, and allowing it to be large enough so that the necessary 64 bytes of public key is small compared to it on the one hand, and bandwidth waste on the other hand.</ref> bytes of arbitrary data after their public key, called '''garbage''', providing a form of shapability and avoiding a recognizable pattern of exactly 64 bytes.<ref name="why_garbage">'''Why does the affordance for garbage exist in the protocol?''' The garbage strings after the public keys are needed for shapability of the handshake. Neither peer can send decoy packets before having received at least the other peer's public key, i.e., neither peer can send more than 64 bytes before having received 64 bytes.</ref>		#** May send up to 4095<ref name="why_4095_garbage">'''How was the limit of 4095 bytes garbage chosen?''' It is a balance between having sufficient freedom to hide information, and allowing it to be large enough so that the necessary 64 bytes of public key is small compared to it on the one hand, and bandwidth waste on the other hand.</ref> bytes of arbitrary data after their public key, called '''garbage''', providing a form of shapability and avoiding a recognizable pattern of exactly 64 bytes.<ref name="why_garbage">'''Why does the affordance for garbage exist in the protocol?''' The garbage strings after the public keys are needed for shapability of the handshake. Neither peer can send decoy packets before having received at least the other peer's public key, i.e., neither peer can send more than 64 bytes before having received 64 bytes.</ref>
	#* The responder:		#* The responder:
	#** Waits until one byte is received which does not match the 12 bytes consisting of the network magic followed by "version\x00". If the first 12 bytes do match, the connection is treated as using the v1 protocol instead.<ref name="why_no_prefix_check">'''What if a v2 initiator's public key starts accidentally with these 12 bytes?''' This is so unlikely (probability of ''2<sup>-96</sup>'') to happen randomly in the v2 protocol that the initiator does not need to specifically avoid it.</ref><ref>Bitcoin Core versions <=0.4.0 and >=22.0 ignore valid P2P messages that are received prior to a VERSION message. Bitcoin Core versions between 0.4.0 and 22.0 assign a misbehavior score to the peer upon receiving such messages. v2 clients implementing this proposal will interpret any message other than VERSION received as the first message to be the initiation of a v2 connection, and will result in disconnection for v1 initiators that send any message type other than VERSION as the first message. We are not aware of any implementations where this could pose a problem.</ref>		#** Waits until one byte is received which does not match the 16 bytes consisting of the network magic followed by "version\x00\x00\x00\x00\x00". If the first 16 bytes do match, the connection is treated as using the v1 protocol instead.<ref name="why_no_prefix_check">'''What if a v2 initiator's public key starts accidentally with these 16 bytes?''' This is so unlikely (probability of ''2<sup>-128</sup>'') to happen randomly in the v2 protocol that the initiator does not need to specifically avoid it. The optional detection of wrong-network v1 peers has a probability of ''2<sup>-96</sup>'', which is still negligible compared to random network failures.</ref><ref>Bitcoin Core versions <=0.4.0 and >=22.0 ignore valid P2P messages that are received prior to a VERSION message. Bitcoin Core versions between 0.4.0 and 22.0 assign a misbehavior score to the peer upon receiving such messages. v2 clients implementing this proposal will interpret any message other than VERSION received as the first message to be the initiation of a v2 connection, and will result in disconnection for v1 initiators that send any message type other than VERSION as the first message. We are not aware of any implementations where this could pose a problem.</ref>
			#** If the first 4 received bytes do not match the network magic, but the 12 bytes after that do match the version message encoding above, implementations may interpret this as a v1 peer of a different network, and disconnect them.
	#** Similarly generates a random ephemeral private key and sends a corresponding 64-byte ElligatorSwift-encoded public key to the initiator.		#** Similarly generates a random ephemeral private key and sends a corresponding 64-byte ElligatorSwift-encoded public key to the initiator.
	#** Similarly may send up to 4095 bytes of garbage data after their public key.		#** Similarly may send up to 4095 bytes of garbage data after their public key.
Line 140:		Line 141:
	To avoid the recognizable pattern of first messages being at least 64 bytes, a future backwards-compatible upgrade to this protocol may allow both peers to send their public key + garbage + garbage terminator in multiple rounds, slicing those bytes up into messages arbitrarily, as long as progress is guaranteed.<ref name="handshake_progress">'''How can progress be guaranteed in a backwards-compatible way?''' In order to guarantee progress, it must be ensured that no deadlock occurs, i.e., no state is reached in which each party waits for the other party indefinitely. For example, any upgrade that adheres to the following conditions will guarantee progress:		To avoid the recognizable pattern of first messages being at least 64 bytes, a future backwards-compatible upgrade to this protocol may allow both peers to send their public key + garbage + garbage terminator in multiple rounds, slicing those bytes up into messages arbitrarily, as long as progress is guaranteed.<ref name="handshake_progress">'''How can progress be guaranteed in a backwards-compatible way?''' In order to guarantee progress, it must be ensured that no deadlock occurs, i.e., no state is reached in which each party waits for the other party indefinitely. For example, any upgrade that adheres to the following conditions will guarantee progress:

	* The initiator must start by sending at least as many bytes as necessary to mismatch the magic/version 12 bytes prefix.		* The initiator must start by sending at least as many bytes as necessary to mismatch the magic/version 16 bytes prefix.
	* The responder must start sending after having received at least one byte that mismatches that 12-byte prefix.		* The responder must start sending after having received at least one byte that mismatches that 16-byte prefix.
	* As soon as either party has received the other peer's garbage terminator, or has received 4095 bytes of garbage, they must send their own garbage terminator. (When either of these conditions is met, the other party has nothing to respond with anymore that would be needed to guarantee progress otherwise.)		* As soon as either party has received the other peer's garbage terminator, or has received 4095 bytes of garbage, they must send their own garbage terminator. (When either of these conditions is met, the other party has nothing to respond with anymore that would be needed to guarantee progress otherwise.)
	* Whenever either party receives any nonzero number of bytes, while not having sent their garbage terminator completely yet, they must send at least one byte in response without waiting for more bytes.		* Whenever either party receives any nonzero number of bytes, while not having sent their garbage terminator completely yet, they must send at least one byte in response without waiting for more bytes.
Line 342:		Line 343:
	</pre>		</pre>

	The responder generates an ephemeral keypair for itself and derives the shared ECDH secret (using the first 64 received bytes) which enables it to instantiate the encrypted transport. It then sends 64 bytes of the unencrypted ElligatorSwift encoding of its own public key and its own <code>responder_garbage</code> also of length <code>garbage_len < 4096</code>. If the first 12 bytes received match the v1 prefix, the v1 protocol is used instead.		The responder generates an ephemeral keypair for itself and derives the shared ECDH secret (using the first 64 received bytes) which enables it to instantiate the encrypted transport. It then sends 64 bytes of the unencrypted ElligatorSwift encoding of its own public key and its own <code>responder_garbage</code> also of length <code>garbage_len < 4096</code>. If the first 16 bytes received match the v1 prefix, the v1 protocol is used instead.

	<pre>		<pre>
	TRANSPORT_VERSION = b''		TRANSPORT_VERSION = b''
	NETWORK_MAGIC = b'\xf9\xbe\xb4\xd9' # Mainnet network magic; differs on other networks.		NETWORK_MAGIC = b'\xf9\xbe\xb4\xd9' # Mainnet network magic; differs on other networks.
	V1_PREFIX = NETWORK_MAGIC + b'version\x00'		V1_PREFIX = NETWORK_MAGIC + b'version\x00\x00\x00\x00\x00'

	def respond_v2_handshake(peer, garbage_len):		def respond_v2_handshake(peer, garbage_len):
	peer.received_prefix = b""		peer.received_prefix = b""
	while len(peer.received_prefix) < 12:		while len(peer.received_prefix) < len(V1_PREFIX):
	peer.received_prefix += receive(peer, 1)		peer.received_prefix += receive(peer, 1)
	if peer.received_prefix[-1] != V1_PREFIX[len(peer.received_prefix) - 1]:		if peer.received_prefix[-1] != V1_PREFIX[len(peer.received_prefix) - 1]:
Line 367:		Line 368:
	received_prefix = b'' if initiating else peer.received_prefix		received_prefix = b'' if initiating else peer.received_prefix
	ellswift_theirs = receive(peer, 64 - len(received_prefix))		ellswift_theirs = receive(peer, 64 - len(received_prefix))
			if not initiating and ellswift_theirs[4:16] == V1_PREFIX[4:16]:
			# Looks like a v1 peer from the wrong network.
			disconnect(peer)
	ecdh_secret = v2_ecdh(peer.privkey_ours, ellswift_theirs, peer.ellswift_ours,		ecdh_secret = v2_ecdh(peer.privkey_ours, ellswift_theirs, peer.ellswift_ours,
	initiating=initiating)		initiating=initiating)
Line 558:		Line 562:
	\|-		\|-
	!+28		!+28
	\|<code>ADDRV2~~</code>\|\|<code>REQRECON</code>\|\|<code>SKETCH</code>\|\|<code>REQSKETCHEXT~~</code>		\|<code>ADDRV2</code>
	\|-		\|-
	~~!+32~~		!&geq;29
	~~\|<code>RECONCILDIFF</code>~~
	\|-
	!&geq;33
	\|\| colspan="4" \| (undefined)		\|\| colspan="4" \| (undefined)
	\|}		\|}

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/04a965681049ee77/bip-0324.mediawiki

2023-06-29T18:03:18Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/04a965681049ee77/bip-0324.mediawiki

← Older revision		Revision as of 18:03, 29 June 2023
Line 185:		Line 185:
	\| Initiator Responder \|		\| Initiator Responder \|
	\| \|		\| \|
	\| x, ellswift_X = ellswift_create(~~initiating=True~~) \|		\| x, ellswift_X = ellswift_create() \|
	\| \|		\| \|
	\| --- ellswift_X + initiator_garbage (initiator_garbage_len bytes; max 4095) ---> \|		\| --- ellswift_X + initiator_garbage (initiator_garbage_len bytes; max 4095) ---> \|
	\| \|		\| \|
	\| y, ellswift_Y = ellswift_create(~~initiating=False~~) \|		\| y, ellswift_Y = ellswift_create() \|
	\| ecdh_secret = v2_ecdh( \|		\| ecdh_secret = v2_ecdh( \|
	\| y, ellswift_X, ellswift_Y, initiating=False) \|		\| y, ellswift_X, ellswift_Y, initiating=False) \|
Line 337:		Line 337:
	<pre>		<pre>
	def initiate_v2_handshake(peer, garbage_len):		def initiate_v2_handshake(peer, garbage_len):
	peer.privkey_ours, peer.ellswift_ours = ellswift_create(~~initiating=True~~)		peer.privkey_ours, peer.ellswift_ours = ellswift_create()
	peer.sent_garbage = rand_bytes(garbage_len)		peer.sent_garbage = rand_bytes(garbage_len)
	send(peer, peer.ellswift_ours + peer.sent_garbage)		send(peer, peer.ellswift_ours + peer.sent_garbage)
Line 354:		Line 354:
	peer.received_prefix += receive(peer, 1)		peer.received_prefix += receive(peer, 1)
	if peer.received_prefix[-1] != V1_PREFIX[len(peer.received_prefix) - 1]:		if peer.received_prefix[-1] != V1_PREFIX[len(peer.received_prefix) - 1]:
	peer.privkey_ours, peer.ellswift_ours = ellswift_create(~~initiating=False~~)		peer.privkey_ours, peer.ellswift_ours = ellswift_create()
	peer.sent_garbage = rand_bytes(garbage_len)		peer.sent_garbage = rand_bytes(garbage_len)
	send(peer, ellswift_Y + peer.sent_garbage)		send(peer, ellswift_Y + peer.sent_garbage)

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9c34b24ecb962ad3/bip-0324.mediawiki

2023-04-28T09:08:38Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9c34b24ecb962ad3/bip-0324.mediawiki

← Older revision		Revision as of 09:08, 28 April 2023
Line 400:		Line 400:
	** <code>aead_chacha20_poly1305_encrypt(key, nonce, aad, plaintext)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''plaintext'', and returns a byte array ''ciphertext'', 16 bytes longer than the plaintext.		** <code>aead_chacha20_poly1305_encrypt(key, nonce, aad, plaintext)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''plaintext'', and returns a byte array ''ciphertext'', 16 bytes longer than the plaintext.
	** <code>aead_chacha20_poly1305_decrypt(key, nonce, aad, ciphertext)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''ciphertext'', and returns either a byte array ''plaintext'' (16 bytes shorter than the ciphertext), or ''None'' in case the ciphertext was not a valid ChaCha20Poly1305 encryption of any plaintext with the specified ''key'', ''nonce'', and ''aad''.		** <code>aead_chacha20_poly1305_decrypt(key, nonce, aad, ciphertext)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''ciphertext'', and returns either a byte array ''plaintext'' (16 bytes shorter than the ciphertext), or ''None'' in case the ciphertext was not a valid ChaCha20Poly1305 encryption of any plaintext with the specified ''key'', ''nonce'', and ''aad''.
	* The '''ChaCha20 Block Function''' is specified in [https://datatracker.ietf.org/doc/html/rfc8439#section-2.8 RFC 8439 section 2.3]. It is a pseudorandom function (PRF) taking a 256-bit key, 96-bit nonce, and 32-bit counter, and outputs 64 pseudorandom bytes. It is the underlying building block on which ChaCha20 (and ultimately, ChaCha20Poly1305) is built. In what follows:		* The '''ChaCha20 Block Function''' is specified in [https://datatracker.ietf.org/doc/html/rfc8439#section-2.3 RFC 8439 section 2.3]. It is a pseudorandom function (PRF) taking a 256-bit key, 96-bit nonce, and 32-bit counter, and outputs 64 pseudorandom bytes. It is the underlying building block on which ChaCha20 (and ultimately, ChaCha20Poly1305) is built. In what follows:
	** <code>chacha20_block(key, nonce, count)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', and an integer ''count'' in range ''0..2<sup>32</sup>-1'', and returns a byte array of length 64.		** <code>chacha20_block(key, nonce, count)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', and an integer ''count'' in range ''0..2<sup>32</sup>-1'', and returns a byte array of length 64.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/99ae9d9373b33281/bip-0324.mediawiki

2023-03-17T02:58:37Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/99ae9d9373b33281/bip-0324.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/1a632a38751b24bb/bip-0324.mediawiki

2023-02-03T04:39:59Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/1a632a38751b24bb/bip-0324.mediawiki

← Older revision		Revision as of 04:39, 3 February 2023
Line 251:		Line 251:
	** If ''case & 2 = 0'':		** If ''case & 2 = 0'':
	*** If ''lift_x(-x - u)'' succeeds, return ''None''.		*** If ''lift_x(-x - u)'' succeeds, return ''None''.
	*** Let ''v = x'' ~~if ''case & 1 = 0''; let ''v = -x - u (mod p)'' otherwise~~.		*** Let ''v = x''.
	*** Let ''s = -(u<sup>3</sup> + 7)/(u<sup>2</sup> + uv + v<sup>2</sup>) (mod p)''.		*** Let ''s = -(u<sup>3</sup> + 7)/(u<sup>2</sup> + uv + v<sup>2</sup>) (mod p)''.
	** If ''case & 2 = 2'':		** If ''case & 2 = 2'':
Line 257:		Line 257:
	*** If ''s = 0'', return ''None''.		*** If ''s = 0'', return ''None''.
	*** Let ''r'' be the square root of ''-s(4(u<sup>3</sup> + 7) + 3u<sup>2</sup>s) (mod p).''<ref name="modsqrt">'''How to compute a square root mod ''p''?''' Due to the structure of ''p'', a candidate for the square root of ''a'' mod ''p'' can be computed as ''x = a<sup>(p+1)/4</sup> mod p''. If ''a'' is not a square mod ''p'', this formula returns the square root of ''-a mod p'' instead, so it is necessary to verify that ''x<sup>2</sup> mod p = a''. If that is the case ''-x mod p'' is a solution too, but we define "the" square root to be equal to that expression (the square root will therefore always be a square itself, as ''(p+1)/4'' is even). This algorithm is a specialization of the [https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm Tonelli-Shanks algorithm].</ref> Return ''None'' if it does not exist.		*** Let ''r'' be the square root of ''-s(4(u<sup>3</sup> + 7) + 3u<sup>2</sup>s) (mod p).''<ref name="modsqrt">'''How to compute a square root mod ''p''?''' Due to the structure of ''p'', a candidate for the square root of ''a'' mod ''p'' can be computed as ''x = a<sup>(p+1)/4</sup> mod p''. If ''a'' is not a square mod ''p'', this formula returns the square root of ''-a mod p'' instead, so it is necessary to verify that ''x<sup>2</sup> mod p = a''. If that is the case ''-x mod p'' is a solution too, but we define "the" square root to be equal to that expression (the square root will therefore always be a square itself, as ''(p+1)/4'' is even). This algorithm is a specialization of the [https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm Tonelli-Shanks algorithm].</ref> Return ''None'' if it does not exist.
	*** If ''case & 1 = 1'':		** If ''case & 1 = 1'' and ''r = 0'', return ''None''.
	**** If ''r = 0'', return ''None~~''.~~
	**** let ''r = -r (mod p)''.
	*** Let ''v = (-u + r/s)/2''.		*** Let ''v = (-u + r/s)/2''.
	** Let ''w'' be the square root of ''s (mod p)''. Return ''None'' if it does not exist.		** Let ''w'' be the square root of ''s (mod p)''. Return ''None'' if it does not exist.
	** If ''case & 4 = 4'', ~~let~~ ''w = -w (~~mod p~~)''.		** If ''case & 5 = 0'', return ''-w(u(1 - c)/2 + v)''.
	** ~~Return~~ ''w(u(c - 1)/2 - v)''.		** If ''case & 5 = 1'', return ''w(u(1 + c)/2 + v)''.
			** If ''case & 5 = 4'', return ''w(u(1 - c)/2 + v)''.
			** If ''case & 5 = 5'', return ''-w(u(1 + c)/2 + v)''.

	The overall ''XElligatorSwift'' algorithm, matching the name used in the paper, then uses this inverse to randomly''<ref name="ellswift_helps_parroting">'''Can the ElligatorSwift encoding be used to construct public key encodings that satisfy a certain structure (and not pseudorandom)?''' The algorithm chooses the first 32 bytes (i.e., the value ''u'') and then computes a corresponding ''t'' such that the mapping to the curve point holds. In general, picking ''u'' from a uniformly random distribution provides pseudorandomness. But we can also fix any of the 32 bytes in ''u'', and the algorithm will still find a corresponding ''t''. The fact that it is possible to fix the first 32 bytes, combined with the garbage bytes in the handshake, provides a limited but very simple method of parroting other protocols such as [https://tls13.xargs.org/ TLS 1.3], which can be deployed by one of the peers without explicit support from the other peer. More general methods of parroting, e.g., introduced by defining new protocol or a protocol upgrade, are not precluded.</ref> sample encodings of ''x'':		The overall ''XElligatorSwift'' algorithm, matching the name used in the paper, then uses this inverse to randomly''<ref name="ellswift_helps_parroting">'''Can the ElligatorSwift encoding be used to construct public key encodings that satisfy a certain structure (and not pseudorandom)?''' The algorithm chooses the first 32 bytes (i.e., the value ''u'') and then computes a corresponding ''t'' such that the mapping to the curve point holds. In general, picking ''u'' from a uniformly random distribution provides pseudorandomness. But we can also fix any of the 32 bytes in ''u'', and the algorithm will still find a corresponding ''t''. The fact that it is possible to fix the first 32 bytes, combined with the garbage bytes in the handshake, provides a limited but very simple method of parroting other protocols such as [https://tls13.xargs.org/ TLS 1.3], which can be deployed by one of the peers without explicit support from the other peer. More general methods of parroting, e.g., introduced by defining new protocol or a protocol upgrade, are not precluded.</ref> sample encodings of ''x'':
Line 590:		Line 590:

	For development and testing purposes, we provide a collection of test vectors in CSV format, and a naive, highly inefficient, [[bip-0324/reference.py\|reference implementation]] of the relevant algorithms. This code is for demonstration purposes only:		For development and testing purposes, we provide a collection of test vectors in CSV format, and a naive, highly inefficient, [[bip-0324/reference.py\|reference implementation]] of the relevant algorithms. This code is for demonstration purposes only:
	* [[bip-0324/~~xelligatorswift_test_vectors~~.csv\|XElligatorSwift vectors]] give examples of ElligatorSwift-encoded public keys, and the X coordinate they map to.		* [[bip-0324/ellswift_decode_test_vectors.csv\|XElligatorSwift decoding vectors]] give examples of ElligatorSwift-encoded public keys, and the X coordinate they map to.
	* [[bip-0324/~~xswiftec_test_vectors~~.csv\|~~XSwiftEC~~ vectors]] give examples of ''(u, x)'' pairs, and the various ''t'' values that ''xswiftec_inv'' maps them to.		* [[bip-0324/xswiftec_inv_test_vectors.csv\|XSwiftECInv vectors]] give examples of ''(u, x)'' pairs, and the various ''t'' values that ''xswiftec_inv'' maps them to.
	* [[bip-0324/packet_encoding_test_vectors.csv\|Packet encoding vectors]] illustrate the lifecycle of the authenticated encryption scheme proposed in this document.		* [[bip-0324/packet_encoding_test_vectors.csv\|Packet encoding vectors]] illustrate the lifecycle of the authenticated encryption scheme proposed in this document.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/2361582f0b921977/bip-0324.mediawiki

2023-01-05T00:59:58Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/2361582f0b921977/bip-0324.mediawiki

Show changes