Skip to content

Latest commit

 

History

History
748 lines (560 loc) · 75.3 KB

04-onion-routing.md

File metadata and controls

748 lines (560 loc) · 75.3 KB
Raw

BOLT #4: Onion Routing Protocol

Overview

This document describes the construction of an onion routed packet that is used to route a payment from a origin node to a final node, over a number of intermediate nodes, called hops.

The routing schema is based on the Sphinx construction, and is extended with a per-hop payload.

Intermediate nodes forwarding the message can verify the integrity of the packet, and can learn about which node they should forward the packet to. They cannot learn about which other nodes, besides their predecessor or successor, are part of this route, nor can they learn the length of the route and their position within it. The packet is obfuscated at each hop, so that a network level attacker cannot associate packets belonging to the same route, i.e., packets belonging to a route do not share any identifying information. Notice that this does not preclude the possibility to associate packets by performing a traffic analysis.

The route is constructed by the sender, which knows a public key of each intermediate node. Knowing the intermediate node's public key allows the sender to create a shared secret using ECDH for each intermediate node, including the final recipient. The shared secret is then used to generate a pseudo-random stream of bytes to obfuscate the packet, and a number of keys used to encrypt the payload and compute HMACs ensuring integrity at each hop.

This specification describes version 0 of the packet format and routing mechanism. Should a node receive a higher version packet that it does not implement it MUST report a route failure to the sending node and discard the packet.

Conventions

There are a number of conventions we will adhere to throughout the document:

  • The maximum route length is limited to 20 hops.
  • Nodes are addressed using 20 byte identifiers. These are computed from the node's public key, in accordance to the Bitcoin address creation, as RIPEMD160(SHA256(pubkey)) where pubkey is the serialized compressed public key of the node. Refer to OP_HASH160 for details.
  • HMAC: the integrity verification of the packet is based on Keyed-Hash Message Authentication Code as defined by the FIPS 198 Standard/RFC 2104, using SHA256 as hashing algorithm. The resulting HMAC is then truncated at 20 bytes in order to reduce the overhead.
  • Elliptic Curve: for all computations involving elliptic curves, the Bitcoin curve, secp256k1, is used.
  • Pseudo-Random Stream: ChaCha20 is used to generate a pseudo-random byte stream. For the generation we use a fixed null-nonce (0x0000000000000000), a key derived from a shared secret and a 0x00-byte stream of the desired output size as message.
  • We use the terms hop and node interchangeably.
  • A peer is a direct neighbor of the processing node in the overlay network.

Key Generation

A number of encryption and verification keys are derived from the shared secret:

  • rho: used as key when generating the pseudo-random byte stream used to obfuscate the routing information.
  • gamma: used as key when generating the pseudo-random byte stream used to obfuscate the per-hop payloads.
  • mu: used during the HMAC generation.

The key generation takes a key-type (rho=0x72686F, gamma=0x67616d6d61 or mu=0x6d75) and a 32 byte secret as inputs and returns a 32 byte key.

Keys are generated by computing an HMAC, with SHA256 as hashing algorithm, using the key-type, i.e., rho, mu or gamma, as HMAC-key and the 32 byte shared secret as the message. The resulting HMAC is then returned as the key.

Notice that the key-type does not include a C-style 0x00 termination-byte, e.g., the length of the gamma key-type is 5 bytes, not 6.

Pseudo Random Byte Stream

The pseudo-random byte stream is used to obfuscate the packet at each hop of the path, so that each hop may only recover the address of the next hop as well as the HMAC for the next hop. The pseudo-random byte stream is generated by encrypting a 0x00-byte stream of the required length with ChaCha20, initialized with a key derived from the shared secret and a zero-nonce (0x00000000000000). The use of a fixed nonce is safe since the keys are never reused.

Packet Structure

The packet consists of 2 parts:

  • The fixed size header containing meta information about the packet and the routing information necessary to forward the message.
  • A fixed size per-hop payload containing information for each hop as they forward the message.

The overall structure of the packet is depicted below. The network format of the packet consists of the individual parts being serialized into one continguous byte-stream and then transferred to the recipient of the packet. Due to the fixed size of the packet it does not need to be prefixed by its length when transferred over a connection.

+--------+-----------------+
| header | per-hop payload |
+--------+-----------------+

The header is a fixed 854 byte array containing the necessary information for each hop to identify the next hop, and verify the integrity of the packet. It consists of a version byte, a 33 byte compressed secp256k1 public key, used during the shared secret generation, a 20 byte HMAC used to verify the packet's integrity and an 800 byte routing information field. For this specification the version byte has a constant value of 0x00.

+------------------+-----------------------+-----------------+------------...-----------+
| Version (1 byte) | Public Key (33 bytes) | HMAC (20 bytes) | Routing Info (800 bytes) |
+------------------+-----------------------+-----------------+------------...-----------+

The routing info field is a structure that holds obfuscated versions of the next hop's address and the associated HMAC. It is 800 bytes long, i.e., 20 byte MAC and 20 byte address times 20 hops, and has the following structure:

+-------------+----------+-------------+----------+-----+--------+
| n_1 address | n_1 HMAC | n_2 address | n_2 HMAC | ... | filler |
+-------------+----------+-------------+----------+-----+--------+

Where the filler consists of obfuscated deterministically generated padding. For details about how the filler is generated please see below. In addition, every (address, HMAC)-pair is incrementally obfuscated at each hop.

The per-hop payloads has a similar structure:

+-------------+-------------+-------------+-----+------------+
| n_1 payload | n_2 payload | n_3 payload | ... | hop filler |
+-------------+-------------+-------------+-----+------------+

With the hopfiller being constructed in the same way as the routing info filler and each payload being incrementally obfuscated at each hop.

Per Hop Payload Format

Using the per-hop-payload, the sender is able to precisely specify the path and structure of the HTLC's forwarded at each hop. As the per-hop-payload is protected under the packet-wide HMAC, the information within the per-hop-payload is fully authenticated with each pair-wise relationship between the HTLC sender, and each intermediate node in the path. Using this end-to-end authentication, forwarding nodes are able to ensure that the incoming node didn't forward an ill-crafted HTLC by cross-checking the HTLC parameters with the values as specified within the per-hop-payload.

The format of the per-hop-payload for a version 0 packet is as follows:

+----------------+--------------------------+-------------------------------+--------------------------------------------+
| realm (1 byte) | amt_to_forward (8 bytes) | outgoing_cltv_value (4 bytes) | unused_with_v0_version_on_header (7 bytes) |
+----------------+--------------------------+-------------------------------+--------------------------------------------+

Field Description:

  • realm - The realm (chain) link that the outgoing HTLC should be forwarded on. Within a version 0 packet, this field currently carries no meaning as cross-chain forwarding has not yet been fully specified.

  • amt_to_forward - The amount in milli-satoshi to forward to the next (outgoing) hop specified within the routing information.

    This value MUST factor in the computed fee for this particular hop. When processing an incoming Sphinx packet along with the HTLC message it's encapsulated within, if the following inequality doesn't hold, then the HTLC should be rejected as it indicates a prior node in the path has deviated from the specified paramters:

    incoming_htlc_amt - fee >= amt_to_forward

    Where fee is calculated according to the receving node's advertised fee schema as described in BOLT 7.

  • outgoing_cltv_value - The CLTV value that the outgoing HTLC carrying the packet should have.

    cltv-expiry - cltv-expiry-delta = outgoing_cltv_value

    Inclusion of this field allows a node to both authenticate the information specified by the original sender and the paramaters of the HTLC forwarded, and ensure the original sender is using the current cltv-expiry-delta value. If the values don't correspond, then the HTLC should be failed+rejected as this indicates the incoming node has tampered with the intended HTLC values, or the origin has an obsolete cltv-expiry-delta value.

Nodes forwarding HTLC's MUST construct the outgoing HTLC as specified within the per-hop-payload. Otherwise, deviation from the specified HTLC parameters may lead to extraneous routing failure.

Packet Construction

Assuming a sender node n_0 wants to route a packet to a final recipient n_r. The sender computes a route {n_0, n_1, ..., n_{r-1}, n_r}, where n_0 is the sender itself and n_r is the final recipient. The nodes n_i and n_{i+1} MUST be peers in the overlay network. The sender gathers the public keys for n_1 to n_r and generates a random 32 byte sessionkey. Optionally the sender may pass in associated data, i.e., data that the packet commits to, but is not included in the packet itself. Associated data will be included in the HMACs and has to match the associated data provided during integrity verification at each hop.

For each node the sender computes an ephemeral public key, a shared secret and a blinding factor. The blinding factor is used at each hop to blind the ephemeral public key for the next hop. The node receiving the header will perform ECDH with the ephemeral public key and its private key to derive the same shared secret. However, when generating the packet we do not have access to the node's private key. Hence, we use the commutative property of multiplication and blind the node's public key with all previous blinding factors and perform ECDH using the node's blinded public key and the sessionkey.

The transformations at hop k are given by the following:

  • The shared secret ss_k is computed by first blinding the node's public key nodepk_k with all previous blinding factors {b_1, ..., b_{k-1}}, if any, and then executing ECDH with the blinded public key and the sessionkey.
  • The blinding factor is the SHA256 hash of the concatenation between the node's public key nodepk_k and the hop's shared secret ss_k. Before concatenation the node's public key is serialized in the compressed format.
  • The ephemeral public key epk_k is computed by blinding the previous hop's ephemeral public key epk_{k-1} with the previous hop's blinding factor b_{k-1}.

This recursive algorithm is initialized by setting the first hop's (k=1) ephemeral public key to the public key corresponding with the sessionkey, i.e., secp256k1 is used to derive a public key for the randomly selected sessionkey.

The sender then iteratively computes the ephemeral public keys, shared secrets and blinding factors for nodes {n_2, ..., n_r}.

Once the sender has all the required information it can construct the packet. Constructing a packet routed over r hops requires r 32 byte ephemeral public keys, r 32 byte shared secrets, r 32 byte blinding factors and r 20 byte per-hop payloads. The construction returns one 1254 byte packet and the first hop's address.

The packet construction is performed in reverse order of the route, i.e., the last hop's operations are applied first.

The per-hop payload is initialized with 400 0x00 bytes. The routing info is initialized with 800 0x00 bytes. The next address and the HMAC are initialized to 20 0x00 bytes each.

Two fillers are generated with the shared secrets: a routing info filler with 40 byte hopsize and a per-hop payload filler with 20 byte hopsize. See below for details on filler generation.

For each hop in the route in reverse order the sender applies the following operations:

  • It generates a rho-key, mu-key and a gamma-key using the hop's shared secret.
  • The routing info field is right-shifted by 40 bytes, discarding the last 40 bytes that exceed the 800 bytes. The address is copied into the first 20 bytes of the routing info and the HMAC is copied into the following 20 bytes. The rho-key is used to generate 800 bytes of pseudo-random byte stream and applied with XOR to the routing info field. Should this be the last hop, i.e., the first iteration, then the tail of the routing info field is overwritten with the routing info filler.
  • The per-hop payload field is right-shifted by 20 bytes, and the last 20 bytes discarded, resulting in 400 bytes of per-hop payload. The current hop's per-hop payload is copied into the first 20 bytes. The gamma-key is used to generate 400 bytes of pseudo-random byte stream which are then applied using XOR to the per-hop payloads field. Should this be the last hop then the tail of the per-hop payloads field is overwritten with the per-hop payload filler.
  • The next HMAC is computed over the concatenated routing info, per-hop payload and associated data, with the mu-key as HMAC-key.
  • The next address is computed from the current node's public key using the Bitcoin address hash derivation.

The final value for the HMAC is the HMAC as it should be sent to the first hop.

The packet generation returns the serialized packet, consisting of the version byte, the ephemeral pubkey for the first hop, the HMAC for the first hop, the obfuscated routing info and the obfuscated per-hop payload.

The following code implements the packet construction in Go:

func ConstructPacket(paymentPath []*btcec.PublicKey, sessionKey *btcec.PrivateKey,
	rawHopPayloads [][]byte) ([]byte) {
	numHops := len(paymentPath)
	
	ephemeralpks := make([]*btcec.PublicKey, numHops)
	sharedsecrets := make([][sha256.Size]byte, numHops)
	blindingfactors := make([][sha256.Size]byte, numHops)

	ephemeralpks[0] = sessionKey.PubKey()
	sharedsecrets[0] = sha256.Sum256(btcec.GenerateSharedSecret(sessionKey, paymentPath[0]))
	blindingfactors[0] = computeBlindingFactor(ephemeralpks[0], sharedsecrets[0][:])

	for i := 1; i <= numHops-1; i++ {
		ephemeralpks[i] = blindGroupElement(ephemeralpks[i-1], blindingfactors[i-1][:])
		bpk := blindGroupElement(paymentPath[i], sessionKey.D.Bytes())
		sharedsecrets[i] = sha256.Sum256(multiScalarMult(bpk, blindingfactors[:i]).X.Bytes())
		blindingfactors[i] = computeBlindingFactor(ephemeralpks[i], sharedsecrets[i][:])
	}

	filler := generate_filler("rho", numHops, 2*20, sharedsecrets)
	hopfiller := generate_filler("gamma", numHops, 20, sharedsecrets)

	// Initialize all of these to 0x00-arrays
	var header [20 * 40]byte
	var hoppayloads [20 * 20]byte
	var next_hmac [20]byte
	var next_address [20]byte

	// Compute header in reverse path order
	for i := numHops - 1; i >= 0; i-- {
		rhoKey := generateKey("rho", sharedsecrets[i])
		gammaKey := generateKey("gamma", sharedsecrets[i])
		piKey := generateKey("pi", sharedsecrets[i])
		muKey := generateKey("mu", sharedsecrets[i])

		// Shift and obfuscate header
		stream := generateStream(rhoKey, numStreamBytes)
		rightShift(header[:], 2*20)
		copy(header[:], next_address[:])
		copy(header[20:], next_hmac[:])
		xor(header[:], header[:], streamBytes[:routingInfoSize])

		// Shift and obfuscate per-hop payload
		stream = generateStream(gammaKey, uint(len(hoppayloads)))
		rightShift(hoppayloads[:], 20)
		copy(hoppayloads[:], rawHopPayloads[i])
		xor(hoppayloads[:], hoppayloads[:], hopStreamBytes)

		// Add fillers if this is the last hop
		if i == numHops-1 {
			copy(header[len(header)-len(filler):], filler)
			copy(hoppayloads[len(hoppayloads)-len(hopfiller):], hopfiller)
		}
		cipher, _ := chacha20.New(piKey[:], bytes.Repeat([]byte{0x00}, 8))

		next_hmac = ComputeMac(muKey, append(append(header[:], hoppayloads[:]...), onion[:]...))
		next_address = btcutil.Hash160(paymentPath[i].SerializeCompressed())
	}
	
	// Assemble packet
	var packet [2258]byte
	version = []byte{0x00}
	copy(packet[:], version)
	copy(packet[1:], ephemeralpks[0].SerializeCompressed())
	copy(packet[34:], next_hmac)
	copy(packet[54:], header)
	copy(packet[854:], hoppayloads)
	
	return packet
}

Packet Forwarding

Upon receiving a packet, a node compares the version byte of the packet with its supported versions and aborts otherwise. This specification is limited to version 0 packets and the structure of future versions may change. The receiving node then splits the packet into its fields.

The node MUST check that the ephemeral public key is on the secp256k1 curve. Should this not be the case the node MUST abort processing the packet and report a route failure to the sender.

The node then computes the shared secret as described below, using the private key corresponding to its public key and the ephemeral key from the packet. The node MUST keep a log of previously used shared secrets. Should the shared secret already be in the log it MUST abort processing the packet and report a route failure, since this is likely a replay attack, otherwise the shared secret is added to the log.

The shared secret is used to compute a mu-key. The node then computes the HMAC of the packet, starting from byte 54, which corresponds to the routing info, per-hop payloads and associated data, using the mu-key. The resulting HMAC is compared with the HMAC from the packet. Should the computed HMAC and the HMAC from the packet differ then the node MUST abort processing and report a route failure. Comparison of the computed HMAC and the HMAC from the packet MUST be time-constant to avoid leaking information.

At this point the node can generate a rho-key and a gamma-key.

The routing info is deobfuscated and the information about the next hop is extracted. In order to do so the node copies the routing info field, appends 40 0x00 bytes and generates 840 pseudo-random bytes using the rho-key and applies it using XOR to the copy of the routing information. The first 20 bytes of the resulting routing info are the address of the next hop, followed by the 20 byte HMAC. The routing info for the outgoing packet, destined for the next hop, consists of the 800 bytes starting at byte 40.

The per-hop payload is deobfuscated in a similar way. The node creates a copy of the per-hop payloads field and appends 20 0x00 bytes of padding. It generates 420 bytes of pseudo-random bytes using the gamma-key and applies it using XOR to the padded copy of the per-hop payloads. The first 20 bytes of the padded copy are the node's per-hop payload, while the remaining 400 bytes are the per-hop payload destined for the next hop.

A special HMAC value of 20 0x00 bytes indicates that the currently processing hop is the intended recipient and that the packet should not be forwarded.

Should the HMAC not indicate route termination and the next hop be a peer of the current node, then the new packet is assembled by blinding the ephemeral key with the current node's public key and shared secret, and serializing the routing info and per-hop payload. The resulting packet is then forwarded to the addressed peer. The addressed peer MUST be a direct neighbor of the node processing the packet. Should the processing node not have a peer with the matching address, then it MUST drop the packet and signal a route failure.

Shared secret

The sender performs ECDH with each hop of the route in order to establish a secret. For each message a new sessionkey is generated. The sessionkey is a 32 byte EC private key. The shared secret creation receives a public key and a 32 byte secret as input and returns a 32 byte secret as output.

In the packet generation phase the secret is the sessionkey and the public key is the node's public key, blinded with all previous blinding factors. In the pocessing phase the secret is the node's private key and the public key is the ephemeral public key from the packet, which has been incrementally blinded by the predecessors.

The public key is multiplied by the secret, using to the secp256k1 curve. The DER compressed representation of the multiplication result is serialized and hashed using SHA256. The resulting hash is returned as the shared secret. Notice that this is the ECDH variant implemented in libsecp256k1.

Filler Generation

Upon receiving a packet, each node extracts the information destined for that node from the route info and the per-hop payload. The extraction is done by deobfuscating and left-shifting the field. This would make the field shorter at each hop, allowing an attacker to deduce the route length. For this reason the field is padded before forwarding. Since the padding is part of the HMAC the sender will have to generate an identical padding in order to compute the HMACs correctly for each hop. The filler is also used to pad the field-length in case the selected route is shorter than the maximum allowed route length.

We call the number of bytes extracted from the field hopsize. In case of the route info the hopsize is 40 bytes (20 bytes address and 20 bytes HMAC), while in the case of the per-hop payload it is 20 bytes.

Before deobfuscating the field, the node pads the field with hopsize 0x00 bytes, such that the total length of the field is (20 + 1) * hopsize. It then generates the pseudo-random byte stream of matching length and applies it with XOR to the field. This deobfuscates the information destined for it, and simultaneously obfuscates the added 0x00-bytes at the end.

In order to compute the correct HMAC, the sender has to generate the field's state at the hop. This also includes the incrementally obfuscated padding added by each hop. The incrementally obfuscated padding is called the filler.

The following code shows how the filler is generated:

func generateFiller(key string, numHops int, hopSize int, sharedSecrets [][sharedSecretSize]byte) []byte {
	fillerSize := uint((numMaxHops + 1) * hopSize)
	filler := make([]byte, fillerSize)

	// The last hop does not obfuscate, it's not forwarding anymore.
	for i := 0; i < numHops-1; i++ {

		// Left-shift the field
		copy(filler[:], filler[hopSize:])

		// Zero-fill the last hop
		copy(filler[len(filler)-hopSize:], bytes.Repeat([]byte{0x00}, hopSize))

		// Generate pseudo-random byte stream
		streamKey := generateKey(key, sharedSecrets[i])
		streamBytes := generateCipherStream(streamKey, fillerSize)

		// Obfuscate
		xor(filler, filler, streamBytes)
	}

	// Cut filler down to the correct length (numHops+1)*hopSize
	// bytes will be prepended by the packet generation.
	return filler[(numMaxHops-numHops+2)*hopSize:]
}

Notice that this implementation is for demonstration purposes only, the filler can be generated much more efficiently. The last hop does not obfuscate the filler since it will not forward the packet and will not extract an HMAC for any followup hops.

Blinding EC Points

In order to vary the ephemeral public key (the EC point) between hops, it is blinded at each hop. The inputs for the blinding process are the EC point to be blinded, the node's public key and a 32 byte shared secret, while the output is a single EC point, representing the blinded element.

Blinding is done by computing a blinding factor from the node's public key and the shared secret for that hop. The blinding factor is the result of serializing the node's public key into its compressed format, appending the shared secret and computing the SHA256 hash. The blinded EC point then is the result of the scalar multiplication between the EC point and the blinding factor.

Returning Errors

The protocol includes a simple mechanism to return encrypted error messages to the origin node. The returned messages may either be failures reported by any intermediate hop, or the final node. The format of the forward packet is not usable for the return path, since no node other than the origin has the required information. Note that these error messages are not reliable, as they are not placed on-chain in the case of node failure.

Intermediate hops store the shared secret from the forward path and reuse it to obfuscate the error packet on each hop. In addition each node locally stores the previous hop it received the forward packet from, in order to determine where to send an eventual return packet. The node returning the message builds a return packet consisting of the following fields:

  1. data:
    • [20:hmac]
    • [2:failure-len]
    • [failure-len:failuremsg]
    • [2:pad-len]
    • [pad-len:pad]

Where hmac is an HMAC authenticating the remainder of the packet, with a key using the above key generation with key type "um", failuremsg is defined below, and pad as extra bytes to conceal length.

The node SHOULD set pad such that the failure-len plus pad-len is equal to 128. This is 28 bytes longer than then the longest currently-defined message.

The node then generates a new key, using the key type ammag. This key is then used to generate a pseudo-random stream, which is then applied to the packet using XOR.

The obfuscation step is repeated by every node on the return path. Upon receiving a packet the node will generate its ammag, generate the pseudo-random byte stream and apply it to the packet before forwarding.

The origin node detects that it is the final hop of the return message since it was the origin of the corresponding forward packet. Having the shared secrets of all intermediate nodes it can unwrap the packet until the HMAC is a valid HMAC for the packet, which also identifies the sender of the return message.

The association between forward and return packet is handled outside of the protocol, e.g., by association to an HTLC in a payment channel.

Failure Messages

The failure message encapsulated in failuremsg has identical format to a normal message: two byte type (failure-code) followed by data suitable for that type. The following failure-code values are supported. A node MUST select one of these codes when creating an error message, and MUST include the appropriate data.

In the case of more than one error, a node SHOULD select the first one listed.

The top byte of failure-code can be read as a set of flags:

  • 0x8000 (BADONION): unparsable onion, encrypted by previous node.
  • 0x4000 (PERM): permanent failure (otherwise transient)
  • 0x2000 (NODE): node failure (otherwise channel)
  • 0x1000 (UPDATE): new channel update enclosed

Any node MAY return one of the following errors:

If the realm byte is unknown:

  1. type: PERM|1 (invalid_realm)

If an otherwise unspecified transient error occurs for the entire node:

  1. type: NODE|2 (temporary_node_failure)

If an otherwise unspecified permanent error occurs for the entire node:

  1. type: PERM|NODE|2 (permanent_node_failure)

If a node has requirement advertised in its node_announcement features which were not present in the onion:

  1. type: PERM|NODE|3 (required_node_feature_missing)

A forwarding node MAY return one of the following errors, the final node MUST NOT:

If the onion version byte is unknown:

  1. type: BADONION|PERM|4 (invalid_onion_version)
  2. data:
    • [32:sha256-of-onion]

If the onion HMAC is incorrect:

  1. type: BADONION|PERM|5 (invalid_onion_hmac)
  2. data:
    • [32:sha256-of-onion]

If the ephemeral key in the onion is unparsable:

  1. type: BADONION|PERM|6 (invalid_onion_key)
  2. data:
    • [32:sha256-of-onion]

If an otherwise unspecified transient error occurs for the outgoing channel (eg. peer unresponsive, channel capacity reached):

  1. type: 7 (temporary_channel_failure)

If an otherwise unspecified permanent error occurs for the outgoing channel (eg. channel (recently) closed):

  1. type: PERM|8 (permanent_channel_failure)

If the outgoing channel has requirement advertised in its channel_announcement features which were not present in the onion:

  1. type: PERM|9 (required_channel_feature_missing)

If the next peer specified by the onion is not known:

  1. type: PERM|10 (unknown_next_peer)

If the HTLC does not reach the current minimum amount, we tell them the amount of the incoming HTLC and the current channel setting for the outgoing channel:

  1. type: UPDATE|11 (amount_below_minimum)
  2. data:
    • [4:htlc-msat]
    • [2:len]
    • [len:channel_update]

If the HTLC does not pay sufficient fee, we tell them the amount of the incoming HTLC and the current channel setting for the outgoing channel:

  1. type: UPDATE|12 (fee_insufficient)
  2. data:
    • [4:htlc-msat]
    • [2:len]
    • [len:channel_update]

If outgoing_cltv_value does not match theupdate_add_htlc's cltv-expiry minus cltv-expiry-delta for the outgoing channel, we tell them the cltv-expiry and the current channel setting for the outgoing channel:

  1. type: UPDATE|13 (incorrect_cltv_expiry)
  2. data:
    • [4:cltv-expiry]
    • [2:len]
    • [len:channel_update]

If the ctlv-expiry is too near, we tell them the the current channel setting for the outgoing channel:

  1. type: UPDATE|14 (expiry_too_soon)
  2. data:
    • [2:len]
    • [len:channel_update]

The final node may return one of the following errors, intermediate nodes MUST NOT:

If the payment hash has already been paid, the final node MAY treat the payment hash as unknown, or may succeed in accepting the HTLC. If the payment hash is unknown, the final node MUST fail the HTLC:

  1. type: PERM|15 (unknown_payment_hash)

If the amount paid is less than the amount expected, the final node MUST fail the HTLC. If the amount paid is more than twice the amount expected, the final node SHOULD fail the HTLC. This allows the sender to reduce information leakage by altering the amount, without allowing accidental gross overpayment:

  1. type: PERM|16 (incorrect_payment_amount)

If the cltv-expiry is too low, the final node MUST fail the HTLC:

  1. type: 17 (final_expiry_too_soon)

Receiving Failure Codes

A node MUST ignore any extra bytes in failuremsg.

If node sending the error is the final node:

  • If the PERM bit is set, the origin node SHOULD fail the payment, otherwise it MAY retry the payment if the error code is understood and valid. (In particular, final_expiry_too_soon can occur if the block height has changed since sending, temporary_node_failure could resolve within a few seconds).

Otherwise, the node sending the error is an intermediate node:

  • If the NODE bit is set, the origin node SHOULD remove all channels connected with the sending node from consideration.
    • If the PERM bit is not set, the origin node SHOULD restore the channels as it sees new channel_updates.
  • Otherwise, if UPDATE is set, and the channel_update is valid and more recent than the channel_update used to send the payment:
    • The origin node MAY treat the channel_update as invalid if it should not have caused the failure.
    • Otherwise, the origin node SHOULD apply the channel_update.
    • The origin node MAY queue the channel_update for broadcast.
  • Otherwise, the origin node SHOULD eliminate the channel outgoing from the sending node from consideration.
    • If the PERM bit is not set, the origin node SHOULD restore the channel as it sees a new channel_update.
  • The origin node SHOULD then retry routing and sending the payment.

The origin node MAY use the data specified in the various types of failure for debugging purposes.

Test Vector

Packet Creation

The following is an in-depth trace of the packet creation, including intermediate data.

Parameters

pubkey[0] 0x02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619
pubkey[1] 0x0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c
pubkey[2] 0x027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007
pubkey[3] 0x032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991
pubkey[4] 0x02edabbd16b41c8371b92ef2f04c1185b4f03b6dcd52ba9b78d9d7c89c8f221145

nhops = 5/20
sessionkey = 0x4141414141414141414141414141414141414141414141414141414141414141
associated data = 0x4242424242424242424242424242424242424242424242424242424242424242

hop_payload[0] = 0x4141414141414141414141414141414141414141
hop_payload[1] = 0x4141414141414141414141414141414141414141
hop_payload[2] = 0x4141414141414141414141414141414141414141
hop_payload[3] = 0x4141414141414141414141414141414141414141
hop_payload[4] = 0x4141414141414141414141414141414141414141

Per-Hop Information

hop_shared_secret[0] = 0x53eb63ea8a3fec3b3cd433b85cd62a4b145e1dda09391b348c4e1cd36a03ea66
hop_blinding_factor[0] = 0x2ec2e5da605776054187180343287683aa6a51b4b1c04d6dd49c45d8cffb3c36
hop_ephemeral_pubkey[0] = 0x02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619

hop_shared_secret[1] = 0xa6519e98832a0b179f62123b3567c106db99ee37bef036e783263602f3488fae
hop_blinding_factor[1] = 0xbf66c28bc22e598cfd574a1931a2bafbca09163df2261e6d0056b2610dab938f
hop_ephemeral_pubkey[1] = 0x028f9438bfbf7feac2e108d677e3a82da596be706cc1cf342b75c7b7e22bf4e6e2

hop_shared_secret[2] = 0x3a6b412548762f0dbccce5c7ae7bb8147d1caf9b5471c34120b30bc9c04891cc
hop_blinding_factor[2] = 0xa1f2dadd184eb1627049673f18c6325814384facdee5bfd935d9cb031a1698a5
hop_ephemeral_pubkey[2] = 0x03bfd8225241ea71cd0843db7709f4c222f62ff2d4516fd38b39914ab6b83e0da0

hop_shared_secret[3] = 0x21e13c2d7cfe7e18836df50872466117a295783ab8aab0e7ecc8c725503ad02d
hop_blinding_factor[3] = 0x7cfe0b699f35525029ae0fa437c69d0f20f7ed4e3916133f9cacbb13c82ff262
hop_ephemeral_pubkey[3] = 0x031dde6926381289671300239ea8e57ffaf9bebd05b9a5b95beaf07af05cd43595

hop_shared_secret[4] = 0xb5756b9b542727dbafc6765a49488b023a725d631af688fc031217e90770c328
hop_blinding_factor[4] = 0xc96e00dddaf57e7edcd4fb5954be5b65b09f17cb6d20651b4e90315be5779205
hop_ephemeral_pubkey[4] = 0x03a214ebd875aab6ddfd77f22c5e7311d7f77f17a169e599f157bbcdae8bf071f4

Per-Packet Information

filler = 0x80b23adf2c3947dab3b92bb1c5f70fa32f866cc09aff45c5bc4da1ed291660791aa9a1c5d28fbf8f4ecb4bf7c0a9454c82923e24c7fd0d192ea8e2ead1f17388341f313915949b602d5de1f5cb94b77d42c7dfe84edc13cf9acf541e8243989d967e7d568f26f9209bb52d9f90bfa902f3ec6e3ae9d6215c432206cd3132b69257408002aa020f2fbae32a2d5abee0a3c9fd56329b033939cd6366fbb339aa14
hop_filler = 0x2e86897a3ae52daba4a5940cfc305ae15e9a0f8a8ac1033a15d8a14819acab6503c9df44cdaaf30629283e3458844a44a5c4bfdebdcb15fd3edb8e286124d7b47fa7a56bcc5655d2ad9809f108f238e5

Wrapping the Onion

rhokey[4] = 0x034e18b8cc718e8af6339106e706c52d8df89e2b1f7e9142d996acf88df8799b
gammakey[4] = 0x8b30d62d76ba081e833c88946d220e4471f9c3c943485e4ff5165eff71f0f7e6
mukey[4] = 0x8e45e5c61c2b24cb6382444db6698727afb063adecd72aada233d4bf273d975a
routing_info[4] (unencrypted) = 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
routing_info[4] (encrypted) = 0xf6adec5a586e005ccd8282b782ffe8efb6f3f0e2cee0283a71aa4d873686d7efeac03dcb113fd91113df4bb5d5e8c13cde4bd12eced21d367381fdc31efe09695d6ecc095083c1571d10ed076ee914745479dfedcab84efd3889e6375f544562ea4a6522035738a9ba1a9ab4204339569d3d0c217324f1d5f3a107e930ade50b913777d1140096e2b26ce47486b66a6740f026ae91429115e17270c5a542b4c82ce438725060248726956e7639da64a55cec00b61719383271e0ab97dafe44ad194e7338ea841bf25a505d0041eb53dc0d0e6c3f7986f6647ede9327467212a3ca5724ece8503bfaba3800372d747abe2c174cbc2da01dd967fc0bae56d2bc7184e1d5d823661b8ff06eb466d483d6fa69a4f8b592ebc3006b7c047055b12407925ea74c2bb09ca21f4bc9d39dc4a7237ef6facbb15f5ba56d8e2ab94ad24267bf85cea55b0605cd6260b4b0f17994a03e39bebfcad0834849b188e83bf5c954dc112d33b0fada26f25d76d53ec9b95ed344059a279719d5edc953a4de2b1cc4f47d5da090c3b0f4c7eef14830f9a2230bffb722f11fd2ea82c43d58261e5a868361262abbd81b9f1e6145562ed6765aac732e7d91bfff7716509d72314d46904bcc8053cfd1e3cd7824b4b6499bf8c77762275fa4f651d163a8701f02a5ca67bb7d37787a66d269d4079aa92a489493020b11d87791a3e3ef66780bd0007c8fa2782bac7a839b57e8ace7618a75fe03604097960d2236616d579207fb943c85bef4f804e7f13d7d78ff3aab0f7f440a3005a363f32c31567b8d64669a7ae0299b06b80e4d224d2d70b80077ff966cfb8c11cf763954f398c592ca619acc2e0e86dad54b9cfa47bc10520f3c9ba2e0d2e27e0ba8ef8ece3e71c8a1ff75fe0c8369a3555e42db30565b2e12a8e862d0f873bd781ebf8255372e540bf6fbf4c1dae200823144f8da8df82ccd41b1b678eb91a289b88c6ee5aff71d98b64e8b17e2027fcb6826c418dbdb51f06bec866d69d9554931412808bd90021be2e0dad1d1ececfdd41fcdf6f67b88ef09eb9edcc4c226e07bdfe86b8e50e3bf68b19c0c9e0bf9aaaaddb15bc05a5666733789fa6efde866a49d0329185d852dc84a7e16c4
hop_payloads[4] (unencrypted) = 0x41414141414141414141414141414141414141410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
hop_payloads[4] (encrypted) = 0xcf69f94f0e31d814586ea6d690198e746f5c806e1f254bf04e5599ee8ed8f75552757656fa8af360030a2faacd7bc9c95191bf9c39f513f37dd30883a7953bcfce094d980f91ab7e1cdd9db6b4e20e98c25b0baedf81e2cd8083c43dfbdbba2140ba311976d63f98158bba9cd88fa40b7261c640db1370b443fa9edfc88ada8e51315b128d90b1e6ce07e2c0d2927ba825ddc59c89ff188a41cbc8cbbac96d8c6f3131c7cfe1613e7a74f1b6d0e9e6061af4556a68f7931f351a98d18b7f2292b3ffb428f3263300fc280a60fda4bb8087cfeb5ae99f04e1f1958825b257e72e1407e13540967084a02317f2317ca53026e81bab9bf48c08f6e9ed2b2de567607648ce0e989ec68e6c72ed7de60d0caf55222f293e21ff76d2291522675e122e90c494a93568acdf76cca2ecadfe002736104a82102c8b634e9fefbcdda87ecc81e382281de95e10f3fd1c872f14d21db6ebcc1fed491172a55cff5ec9ec46b2fc30db860e806543be4dff0422eda7ca65a8c44f0b95dd4672ab2033d3b676f1c08aefe26cbdc10382c9452211a096e9
hmac_data[4] = 0xf6adec5a586e005ccd8282b782ffe8efb6f3f0e2cee0283a71aa4d873686d7efeac03dcb113fd91113df4bb5d5e8c13cde4bd12eced21d367381fdc31efe09695d6ecc095083c1571d10ed076ee914745479dfedcab84efd3889e6375f544562ea4a6522035738a9ba1a9ab4204339569d3d0c217324f1d5f3a107e930ade50b913777d1140096e2b26ce47486b66a6740f026ae91429115e17270c5a542b4c82ce438725060248726956e7639da64a55cec00b61719383271e0ab97dafe44ad194e7338ea841bf25a505d0041eb53dc0d0e6c3f7986f6647ede9327467212a3ca5724ece8503bfaba3800372d747abe2c174cbc2da01dd967fc0bae56d2bc7184e1d5d823661b8ff06eb466d483d6fa69a4f8b592ebc3006b7c047055b12407925ea74c2bb09ca21f4bc9d39dc4a7237ef6facbb15f5ba56d8e2ab94ad24267bf85cea55b0605cd6260b4b0f17994a03e39bebfcad0834849b188e83bf5c954dc112d33b0fada26f25d76d53ec9b95ed344059a279719d5edc953a4de2b1cc4f47d5da090c3b0f4c7eef14830f9a2230bffb722f11fd2ea82c43d58261e5a868361262abbd81b9f1e6145562ed6765aac732e7d91bfff7716509d72314d46904bcc8053cfd1e3cd7824b4b6499bf8c77762275fa4f651d163a8701f02a5ca67bb7d37787a66d269d4079aa92a489493020b11d87791a3e3ef66780bd0007c8fa2782bac7a839b57e8ace7618a75fe03604097960d2236616d579207fb943c85bef4f804e7f13d7d78ff3aab0f7f440a3005a363f32c31567b8d64669a7ae0299b06b80e4d224d2d70b80077ff966cfb8c11cf763954f398c592ca619acc2e0e86dad54b9cfa47bc10520f3c9ba2e0d2e27e0ba8ef8ece3e71c8a1ff75fe0c8380b23adf2c3947dab3b92bb1c5f70fa32f866cc09aff45c5bc4da1ed291660791aa9a1c5d28fbf8f4ecb4bf7c0a9454c82923e24c7fd0d192ea8e2ead1f17388341f313915949b602d5de1f5cb94b77d42c7dfe84edc13cf9acf541e8243989d967e7d568f26f9209bb52d9f90bfa902f3ec6e3ae9d6215c432206cd3132b69257408002aa020f2fbae32a2d5abee0a3c9fd56329b033939cd6366fbb339aa14cf69f94f0e31d814586ea6d690198e746f5c806e1f254bf04e5599ee8ed8f75552757656fa8af360030a2faacd7bc9c95191bf9c39f513f37dd30883a7953bcfce094d980f91ab7e1cdd9db6b4e20e98c25b0baedf81e2cd8083c43dfbdbba2140ba311976d63f98158bba9cd88fa40b7261c640db1370b443fa9edfc88ada8e51315b128d90b1e6ce07e2c0d2927ba825ddc59c89ff188a41cbc8cbbac96d8c6f3131c7cfe1613e7a74f1b6d0e9e6061af4556a68f7931f351a98d18b7f2292b3ffb428f3263300fc280a60fda4bb8087cfeb5ae99f04e1f1958825b257e72e1407e13540967084a02317f2317ca53026e81bab9bf48c08f6e9ed2b2de567607648ce0e989ec68e6c72ed7de60d0caf55222f293e21ff76d2291522675e122e90c494a93568acdf76cca2ecadfe002736104a82102c8b634e9fefbcdda87ecc2e86897a3ae52daba4a5940cfc305ae15e9a0f8a8ac1033a15d8a14819acab6503c9df44cdaaf30629283e3458844a44a5c4bfdebdcb15fd3edb8e286124d7b47fa7a56bcc5655d2ad9809f108f238e54242424242424242424242424242424242424242424242424242424242424242
hmac[4] = 0x9e658e791fd5818a9f252c5c5ae7bb67c0f93343

rhokey[3] = 0xcbe784ab745c13ff5cffc2fbe3e84424aa0fd669b8ead4ee562901a4a4e89e9e
gammakey[3] = 0x4468c27a9945114721d60edd711b636cccf4caa3422fbb253e1fc9987da89710
mukey[3] = 0x5052aa1b3d9f0655a0932e50d42f0c9ba0705142c25d225515c45f47c0036ee9
routing_info[3] (unencrypted) = 0x61e068f8204f315c5909db270f3b75278b89d6919e658e791fd5818a9f252c5c5ae7bb67c0f93343f6adec5a586e005ccd8282b782ffe8efb6f3f0e2cee0283a71aa4d873686d7efeac03dcb113fd91113df4bb5d5e8c13cde4bd12eced21d367381fdc31efe09695d6ecc095083c1571d10ed076ee914745479dfedcab84efd3889e6375f544562ea4a6522035738a9ba1a9ab4204339569d3d0c217324f1d5f3a107e930ade50b913777d1140096e2b26ce47486b66a6740f026ae91429115e17270c5a542b4c82ce438725060248726956e7639da64a55cec00b61719383271e0ab97dafe44ad194e7338ea841bf25a505d0041eb53dc0d0e6c3f7986f6647ede9327467212a3ca5724ece8503bfaba3800372d747abe2c174cbc2da01dd967fc0bae56d2bc7184e1d5d823661b8ff06eb466d483d6fa69a4f8b592ebc3006b7c047055b12407925ea74c2bb09ca21f4bc9d39dc4a7237ef6facbb15f5ba56d8e2ab94ad24267bf85cea55b0605cd6260b4b0f17994a03e39bebfcad0834849b188e83bf5c954dc112d33b0fada26f25d76d53ec9b95ed344059a279719d5edc953a4de2b1cc4f47d5da090c3b0f4c7eef14830f9a2230bffb722f11fd2ea82c43d58261e5a868361262abbd81b9f1e6145562ed6765aac732e7d91bfff7716509d72314d46904bcc8053cfd1e3cd7824b4b6499bf8c77762275fa4f651d163a8701f02a5ca67bb7d37787a66d269d4079aa92a489493020b11d87791a3e3ef66780bd0007c8fa2782bac7a839b57e8ace7618a75fe03604097960d2236616d579207fb943c85bef4f804e7f13d7d78ff3aab0f7f440a3005a363f32c31567b8d64669a7ae0299b06b80e4d224d2d70b80077ff966cfb8c11cf763954f398c592ca619acc2e0e86dad54b9cfa47bc10520f3c9ba2e0d2e27e0ba8ef8ece3e71c8a1ff75fe0c8380b23adf2c3947dab3b92bb1c5f70fa32f866cc09aff45c5bc4da1ed291660791aa9a1c5d28fbf8f4ecb4bf7c0a9454c82923e24c7fd0d192ea8e2ead1f17388341f313915949b602d5de1f5cb94b77d42c7dfe84edc13cf9acf541e8243989d967e7d568f26f9209bb52d9f90bfa902f3ec6e3ae9d6215c
routing_info[3] (encrypted) = 0x543ee05dd7a90c70597b420749b90aee1c4ae7baca3c963de3a4bd8655661a7afa3353a23fd9b06b0556d41a987f1ed24741ac1fdfb9257dd7590c139877d4c095f3da788df373d7be518e2683e7647d719cf38b30a78571d8bed7ec115b128680bbe9484706d295c8d8364b0569aeff9a805076b6d3c645e30b43b7fc5f182ecacd35de9d2168103a6b2a6657af64d4ceca94ff64f0b4fd2266fb32b054ad1cff6fa5654f490c42e99dea672486df885f26508b02495ee450f83fe8eaaf6388e708530fcfa2ece0e728e7b2607f357f5c6c1742f517ae0145bfecb71831020d42579ebeee4aa2d02eb08ca88f09b7131345626ea0d56765ab3d36c5836a53c3cdbe5d949929d9f8b87ee700d10c4b2aa5349f8fade9605c75cb16a2279d929f071d835055f7a0f230f3783a241c2a27e067d82e7cf844c31fa5f70c618054a7c77bd4c2830f88db96a8593ce3e0827f3dcb3bf0ed3d16616a9d08520445f8d33e56319813d81d2d2af1e9633bd7dd297a793e42ec7798ad7343422a9d4ff99e9b9e88ba4aa7118c0daac59b3b870d6a4f2ec2e8ccbe575a9134528fa5b00ec0accacd05d94dab37f98499695246ebfffa2ade28c993fdc9b6dd0524da2ea2d3df54b42b4fc073f13aac755968427939c5f419816c53cd2288f20db2e8e6ccc1158cbc7c22d9fa7b6e0f306e4c92b17193e4431c57353b668e0bf193184d63cb122986093408bb26d1216edc961e5d3a39ab2982889cd0b4827b7d86258fba91fac774a3eec847d8b20a5c88dbf4c93e5680b86c1825d25f7de696a99e3d5f12ca4aa574bbfa2a48f2fc25324f3a1e72270a897ef3066f545f903bc2aedae2ec45832f8e1b14d2dc5c8f48303a52b984d87f04c36ee937d059e34f5c438919458826235307231a14c49d10f8465e327b0c34b7d70c7c6abbb2359e75f043c8c461bbde4bc8df4185aabcb53e46513c9498a71be85927af90b255706ae8a1f1334c78d7dd2a64af9b57b36474d2a8e9f77424491b01af63289b5cef335f3470b3c79fcff1f5d568fc2e2074f34076898e55b8edb3073b29e60c4c2561e94e0a8aec7d38d7a3c85c51d383f75b38655e003a5914389bf3f58cb41d28e7c3104585
hop_payloads[3] (unencrypted) = 0x4141414141414141414141414141414141414141cf69f94f0e31d814586ea6d690198e746f5c806e1f254bf04e5599ee8ed8f75552757656fa8af360030a2faacd7bc9c95191bf9c39f513f37dd30883a7953bcfce094d980f91ab7e1cdd9db6b4e20e98c25b0baedf81e2cd8083c43dfbdbba2140ba311976d63f98158bba9cd88fa40b7261c640db1370b443fa9edfc88ada8e51315b128d90b1e6ce07e2c0d2927ba825ddc59c89ff188a41cbc8cbbac96d8c6f3131c7cfe1613e7a74f1b6d0e9e6061af4556a68f7931f351a98d18b7f2292b3ffb428f3263300fc280a60fda4bb8087cfeb5ae99f04e1f1958825b257e72e1407e13540967084a02317f2317ca53026e81bab9bf48c08f6e9ed2b2de567607648ce0e989ec68e6c72ed7de60d0caf55222f293e21ff76d2291522675e122e90c494a93568acdf76cca2ecadfe002736104a82102c8b634e9fefbcdda87ecc2e86897a3ae52daba4a5940cfc305ae15e9a0f8a8ac1033a15d8a14819acab6503c9df44cdaaf30629283e3458844a44a5c4bfdebdcb15fd3edb8e28
hop_payloads[3] (encrypted) = 0xfbbcd86bea2a44e2dd1444b477ebfd7ec83c85ef3201ae239e445dda5bc4bad26dd95a4d5aa6e059f26edcec6b67a59ca324c7036182d63ebb6b4a9f41333a4ad9df914c0703a386602c4ef6c7b69c1cd78650c5c9b84f55f14cd7e2c73564b1c0cdb3c439ef30fc1155ee1e1d626a6bf11ad3684c9bde881b72699d67ffa89ccdfc4ebf7ac264e720cadbe7e18d6b9dd55bdab238c5ef551300e4cf89bb54702a36ebe245a0093dfed709a714bf44aa42cd1f9f807162a5c9c0dcd07b33cf6f7341b8357078c14481a23a7f8d5543d9784246ba2cb0193947e7536d62ae1441b414ea42822436bcc83c0bb106dcfd4725ec81b118ca57b98fdc90af05255be9d1dae458a13d38eef5add527d5a3b9cd01e4c7bc0604d8134daffbff98729cd90873e60da2355b39f9fe13de5b9de808f5f19b14aa6270d2ae8cedace0ce4ed6ce3d61a26fae39cdd7635f32f4b99dc5e543f9fc238e2e50f1fba2dab31e4c8cba824e44700c339d711568f9afa9b20be4146ede472d6e3a4c8c3b36650e2edc0140b55cd9b2d88c82aa97b1848ebe43
hmac_data[3] = 0x543ee05dd7a90c70597b420749b90aee1c4ae7baca3c963de3a4bd8655661a7afa3353a23fd9b06b0556d41a987f1ed24741ac1fdfb9257dd7590c139877d4c095f3da788df373d7be518e2683e7647d719cf38b30a78571d8bed7ec115b128680bbe9484706d295c8d8364b0569aeff9a805076b6d3c645e30b43b7fc5f182ecacd35de9d2168103a6b2a6657af64d4ceca94ff64f0b4fd2266fb32b054ad1cff6fa5654f490c42e99dea672486df885f26508b02495ee450f83fe8eaaf6388e708530fcfa2ece0e728e7b2607f357f5c6c1742f517ae0145bfecb71831020d42579ebeee4aa2d02eb08ca88f09b7131345626ea0d56765ab3d36c5836a53c3cdbe5d949929d9f8b87ee700d10c4b2aa5349f8fade9605c75cb16a2279d929f071d835055f7a0f230f3783a241c2a27e067d82e7cf844c31fa5f70c618054a7c77bd4c2830f88db96a8593ce3e0827f3dcb3bf0ed3d16616a9d08520445f8d33e56319813d81d2d2af1e9633bd7dd297a793e42ec7798ad7343422a9d4ff99e9b9e88ba4aa7118c0daac59b3b870d6a4f2ec2e8ccbe575a9134528fa5b00ec0accacd05d94dab37f98499695246ebfffa2ade28c993fdc9b6dd0524da2ea2d3df54b42b4fc073f13aac755968427939c5f419816c53cd2288f20db2e8e6ccc1158cbc7c22d9fa7b6e0f306e4c92b17193e4431c57353b668e0bf193184d63cb122986093408bb26d1216edc961e5d3a39ab2982889cd0b4827b7d86258fba91fac774a3eec847d8b20a5c88dbf4c93e5680b86c1825d25f7de696a99e3d5f12ca4aa574bbfa2a48f2fc25324f3a1e72270a897ef3066f545f903bc2aedae2ec45832f8e1b14d2dc5c8f48303a52b984d87f04c36ee937d059e34f5c438919458826235307231a14c49d10f8465e327b0c34b7d70c7c6abbb2359e75f043c8c461bbde4bc8df4185aabcb53e46513c9498a71be85927af90b255706ae8a1f1334c78d7dd2a64af9b57b36474d2a8e9f77424491b01af63289b5cef335f3470b3c79fcff1f5d568fc2e2074f34076898e55b8edb3073b29e60c4c2561e94e0a8aec7d38d7a3c85c51d383f75b38655e003a5914389bf3f58cb41d28e7c3104585fbbcd86bea2a44e2dd1444b477ebfd7ec83c85ef3201ae239e445dda5bc4bad26dd95a4d5aa6e059f26edcec6b67a59ca324c7036182d63ebb6b4a9f41333a4ad9df914c0703a386602c4ef6c7b69c1cd78650c5c9b84f55f14cd7e2c73564b1c0cdb3c439ef30fc1155ee1e1d626a6bf11ad3684c9bde881b72699d67ffa89ccdfc4ebf7ac264e720cadbe7e18d6b9dd55bdab238c5ef551300e4cf89bb54702a36ebe245a0093dfed709a714bf44aa42cd1f9f807162a5c9c0dcd07b33cf6f7341b8357078c14481a23a7f8d5543d9784246ba2cb0193947e7536d62ae1441b414ea42822436bcc83c0bb106dcfd4725ec81b118ca57b98fdc90af05255be9d1dae458a13d38eef5add527d5a3b9cd01e4c7bc0604d8134daffbff98729cd90873e60da2355b39f9fe13de5b9de808f5f19b14aa6270d2ae8cedace0ce4ed6ce3d61a26fae39cdd7635f32f4b99dc5e543f9fc238e2e50f1fba2dab31e4c8cba824e44700c339d711568f9afa9b20be4146ede472d6e3a4c8c3b36650e2edc0140b55cd9b2d88c82aa97b1848ebe434242424242424242424242424242424242424242424242424242424242424242
hmac[3] = 0x2eac9c1505e9c6f73eb32ecdbbd2bfcf718710fd

rhokey[2] = 0x11bf5c4f960239cb37833936aa3d02cea82c0f39fd35f566109c41f9eac8deea
gammakey[2] = 0x17168db1e306f8d670b2a5f90b1986ab2287dafb61fb7007c62a8476ba105ab5
mukey[2] = 0xcaafe2820fa00eb2eeb78695ae452eba38f5a53ed6d53518c5c6edf76f3f5b78
routing_info[2] (unencrypted) = 0xcc1b07838e387deacd0e5232e1e8b49f4c29e4842eac9c1505e9c6f73eb32ecdbbd2bfcf718710fd543ee05dd7a90c70597b420749b90aee1c4ae7baca3c963de3a4bd8655661a7afa3353a23fd9b06b0556d41a987f1ed24741ac1fdfb9257dd7590c139877d4c095f3da788df373d7be518e2683e7647d719cf38b30a78571d8bed7ec115b128680bbe9484706d295c8d8364b0569aeff9a805076b6d3c645e30b43b7fc5f182ecacd35de9d2168103a6b2a6657af64d4ceca94ff64f0b4fd2266fb32b054ad1cff6fa5654f490c42e99dea672486df885f26508b02495ee450f83fe8eaaf6388e708530fcfa2ece0e728e7b2607f357f5c6c1742f517ae0145bfecb71831020d42579ebeee4aa2d02eb08ca88f09b7131345626ea0d56765ab3d36c5836a53c3cdbe5d949929d9f8b87ee700d10c4b2aa5349f8fade9605c75cb16a2279d929f071d835055f7a0f230f3783a241c2a27e067d82e7cf844c31fa5f70c618054a7c77bd4c2830f88db96a8593ce3e0827f3dcb3bf0ed3d16616a9d08520445f8d33e56319813d81d2d2af1e9633bd7dd297a793e42ec7798ad7343422a9d4ff99e9b9e88ba4aa7118c0daac59b3b870d6a4f2ec2e8ccbe575a9134528fa5b00ec0accacd05d94dab37f98499695246ebfffa2ade28c993fdc9b6dd0524da2ea2d3df54b42b4fc073f13aac755968427939c5f419816c53cd2288f20db2e8e6ccc1158cbc7c22d9fa7b6e0f306e4c92b17193e4431c57353b668e0bf193184d63cb122986093408bb26d1216edc961e5d3a39ab2982889cd0b4827b7d86258fba91fac774a3eec847d8b20a5c88dbf4c93e5680b86c1825d25f7de696a99e3d5f12ca4aa574bbfa2a48f2fc25324f3a1e72270a897ef3066f545f903bc2aedae2ec45832f8e1b14d2dc5c8f48303a52b984d87f04c36ee937d059e34f5c438919458826235307231a14c49d10f8465e327b0c34b7d70c7c6abbb2359e75f043c8c461bbde4bc8df4185aabcb53e46513c9498a71be85927af90b255706ae8a1f1334c78d7dd2a64af9b57b36474d2a8e9f77424491b01af63289b5cef335f3470b3c79fcff1f5d568fc2e2074f34076898e55b8edb3073b29e6
routing_info[2] (encrypted) = 0x2e35a3c0369a08fd883df9f7651251e7a4273045abb1994126b8b71360ad04d5d3a91c56e858cb08c57265095d8619d7eed42845c461800bd02cd04b82eb4f0854a7477335d2b2c10f774bced023d5b75e16afe2829e31e3c3f22a2fdb9679e326c714cf0b1d2f212478da1dd446cb3d2c55ac4987af605435a60afffe2ca41f9534823816602b6dbdd8deb2474bd26ae300009044b709aece6eaafa5a8c8e058c74c6c01be47e1c02569523e68b3c82cc8289dc4ed15d349d569b52fb4d4e04e3b5ec5c8f8143c16c5340b7477234935eee5a6de9f0286de2ee8993ea7fa1577e2a6fac0edec3a9d0b7a4b50c6c782734f8395d2b2f8c886c6f45fd1b8a4ef33d8211783093bb6ded77253953e1f43a3a2b42e23bb7a183688512e95bf3cc1b536eac95dc4cf713e4fbd2187f8156d3cc77b21ab2c23f0f1613daf4fe37ab1a9eea3d5babb179c81f18d8ce59508ba7d7ed8a8b46042dfbec5435f8adbd14f354fa26e95ed44126c2b69f85f0d65998e38f779f4c482137f370cfff420cac48dcc6cf0cab1048ad862ff1e2ef3944189d7ae824b27acc03d875f7d314c084ff17053151dca2bcacb841e49f39acd586b9a7526d6a6c3f27358014ac068ea9d8ad4241b2586e5b695a6aecbc2150d0c9e7ac5a86ec926e48778130ccc33d05f9527993cca297d4ea3c392da0c3bdbfc176c0aa3fcfcde16b1a3f5fbe356ee3802e3cefebb830d9d81c73ca4b1e52476b953c76458541de4ea37470774af44f9747468b44ec56b32ea9de90a9373b3acf9c5f2783ab808434034483000deb2ab6ae188ffdef49045fdeb323556ebd82685079f893176eee71b73155faf7c51198f1e79fbee3de8407ccf50c4893849d336878f09ee4a670fdbf9ad1e48c6993b3d9eca7e7152b4b0734aa18b5dc69430a3ffa13879eae033e33b5ef79b7bd7affb016f3da34f6b22fa83e39ea347e0912314a0a013ab6f794aee569d2e2478853ddb33fe4fe7b57df8063d2481c077a2b302a662b63f6259547ceee27fd0c65134780020a9376bff0edae13552421a83672687db5bacf2e63fabc13ece4e0ba8a44228662876e591ad6e8915b4d819aa329ef512a2b8650f6501ba5db46540d5b
hop_payloads[2] (unencrypted) = 0x4141414141414141414141414141414141414141fbbcd86bea2a44e2dd1444b477ebfd7ec83c85ef3201ae239e445dda5bc4bad26dd95a4d5aa6e059f26edcec6b67a59ca324c7036182d63ebb6b4a9f41333a4ad9df914c0703a386602c4ef6c7b69c1cd78650c5c9b84f55f14cd7e2c73564b1c0cdb3c439ef30fc1155ee1e1d626a6bf11ad3684c9bde881b72699d67ffa89ccdfc4ebf7ac264e720cadbe7e18d6b9dd55bdab238c5ef551300e4cf89bb54702a36ebe245a0093dfed709a714bf44aa42cd1f9f807162a5c9c0dcd07b33cf6f7341b8357078c14481a23a7f8d5543d9784246ba2cb0193947e7536d62ae1441b414ea42822436bcc83c0bb106dcfd4725ec81b118ca57b98fdc90af05255be9d1dae458a13d38eef5add527d5a3b9cd01e4c7bc0604d8134daffbff98729cd90873e60da2355b39f9fe13de5b9de808f5f19b14aa6270d2ae8cedace0ce4ed6ce3d61a26fae39cdd7635f32f4b99dc5e543f9fc238e2e50f1fba2dab31e4c8cba824e44700c339d711568f9afa9b20be4146ede472d6e3a4c8c3b36
hop_payloads[2] (encrypted) = 0x3d0e608d2eb771b3056c56e43aeb1ac7a4a9a72405d26c501ef22bee3b3f7ab029cc7e722fe4e40717fc497cacbc2a900095eee0544b72b3010ac9e88f2a2a5e1de9e7284b425da9df8a86d4000476c23c36be6b6ab9f4da864841c27b2890cb9013f34e5cb8d3365936339fbe557677958525dd30b4b9f97acf2951d38521e14b56941093eff81b558a173f27d2809733c82cd4dd9463db001ea986c1c73b61bb31d3788b9a212fe5ed37dc44338242d4fc6d555e74d377daa01081dd1f90c122d2b1ddbcd417d6fc911f305ff73a62866febdd2d6ce6b9d22cd822e310413901bff799987c9659363d2c9f75b554d5ff85e0f9ece32c80cd700b2f77342855fc8ac1fe285be72d364236b517cc300de84dcd2d8719f3a93140e6fc05c3d546a338cc37094c9986802c4bb65da4c2cb4d116255db5f04ce284e93f93602462f40c4529a2d084afe4c4d99f9d7e5bb657d491244e44974b7856532abe4486045a131b1a735d04ebbb11d6ec660cfca4230a8a5c604bbc712382a031a7c15f6ccb93ad39ffc41d70256fc02f310e39201
hmac_data[2] = 0x2e35a3c0369a08fd883df9f7651251e7a4273045abb1994126b8b71360ad04d5d3a91c56e858cb08c57265095d8619d7eed42845c461800bd02cd04b82eb4f0854a7477335d2b2c10f774bced023d5b75e16afe2829e31e3c3f22a2fdb9679e326c714cf0b1d2f212478da1dd446cb3d2c55ac4987af605435a60afffe2ca41f9534823816602b6dbdd8deb2474bd26ae300009044b709aece6eaafa5a8c8e058c74c6c01be47e1c02569523e68b3c82cc8289dc4ed15d349d569b52fb4d4e04e3b5ec5c8f8143c16c5340b7477234935eee5a6de9f0286de2ee8993ea7fa1577e2a6fac0edec3a9d0b7a4b50c6c782734f8395d2b2f8c886c6f45fd1b8a4ef33d8211783093bb6ded77253953e1f43a3a2b42e23bb7a183688512e95bf3cc1b536eac95dc4cf713e4fbd2187f8156d3cc77b21ab2c23f0f1613daf4fe37ab1a9eea3d5babb179c81f18d8ce59508ba7d7ed8a8b46042dfbec5435f8adbd14f354fa26e95ed44126c2b69f85f0d65998e38f779f4c482137f370cfff420cac48dcc6cf0cab1048ad862ff1e2ef3944189d7ae824b27acc03d875f7d314c084ff17053151dca2bcacb841e49f39acd586b9a7526d6a6c3f27358014ac068ea9d8ad4241b2586e5b695a6aecbc2150d0c9e7ac5a86ec926e48778130ccc33d05f9527993cca297d4ea3c392da0c3bdbfc176c0aa3fcfcde16b1a3f5fbe356ee3802e3cefebb830d9d81c73ca4b1e52476b953c76458541de4ea37470774af44f9747468b44ec56b32ea9de90a9373b3acf9c5f2783ab808434034483000deb2ab6ae188ffdef49045fdeb323556ebd82685079f893176eee71b73155faf7c51198f1e79fbee3de8407ccf50c4893849d336878f09ee4a670fdbf9ad1e48c6993b3d9eca7e7152b4b0734aa18b5dc69430a3ffa13879eae033e33b5ef79b7bd7affb016f3da34f6b22fa83e39ea347e0912314a0a013ab6f794aee569d2e2478853ddb33fe4fe7b57df8063d2481c077a2b302a662b63f6259547ceee27fd0c65134780020a9376bff0edae13552421a83672687db5bacf2e63fabc13ece4e0ba8a44228662876e591ad6e8915b4d819aa329ef512a2b8650f6501ba5db46540d5b3d0e608d2eb771b3056c56e43aeb1ac7a4a9a72405d26c501ef22bee3b3f7ab029cc7e722fe4e40717fc497cacbc2a900095eee0544b72b3010ac9e88f2a2a5e1de9e7284b425da9df8a86d4000476c23c36be6b6ab9f4da864841c27b2890cb9013f34e5cb8d3365936339fbe557677958525dd30b4b9f97acf2951d38521e14b56941093eff81b558a173f27d2809733c82cd4dd9463db001ea986c1c73b61bb31d3788b9a212fe5ed37dc44338242d4fc6d555e74d377daa01081dd1f90c122d2b1ddbcd417d6fc911f305ff73a62866febdd2d6ce6b9d22cd822e310413901bff799987c9659363d2c9f75b554d5ff85e0f9ece32c80cd700b2f77342855fc8ac1fe285be72d364236b517cc300de84dcd2d8719f3a93140e6fc05c3d546a338cc37094c9986802c4bb65da4c2cb4d116255db5f04ce284e93f93602462f40c4529a2d084afe4c4d99f9d7e5bb657d491244e44974b7856532abe4486045a131b1a735d04ebbb11d6ec660cfca4230a8a5c604bbc712382a031a7c15f6ccb93ad39ffc41d70256fc02f310e392014242424242424242424242424242424242424242424242424242424242424242
hmac[2] = 0x490b3846a1aff471cef546872a7e5a22a3f3f106

rhokey[1] = 0x450ffcabc6449094918ebe13d4f03e433d20a3d28a768203337bc40b6e4b2c59
gammakey[1] = 0xf14ea48360f5554106e2184043cff711877f985ca2b59d4871fb4770abf7fc05
mukey[1] = 0x05ed2b4a3fb023c2ff5dd6ed4b9b6ea7383f5cfe9d59c11d121ec2c81ca2eea9
routing_info[1] (unencrypted) = 0x331eb609f3aacffe680f86309d6b7470e7215b0c490b3846a1aff471cef546872a7e5a22a3f3f1062e35a3c0369a08fd883df9f7651251e7a4273045abb1994126b8b71360ad04d5d3a91c56e858cb08c57265095d8619d7eed42845c461800bd02cd04b82eb4f0854a7477335d2b2c10f774bced023d5b75e16afe2829e31e3c3f22a2fdb9679e326c714cf0b1d2f212478da1dd446cb3d2c55ac4987af605435a60afffe2ca41f9534823816602b6dbdd8deb2474bd26ae300009044b709aece6eaafa5a8c8e058c74c6c01be47e1c02569523e68b3c82cc8289dc4ed15d349d569b52fb4d4e04e3b5ec5c8f8143c16c5340b7477234935eee5a6de9f0286de2ee8993ea7fa1577e2a6fac0edec3a9d0b7a4b50c6c782734f8395d2b2f8c886c6f45fd1b8a4ef33d8211783093bb6ded77253953e1f43a3a2b42e23bb7a183688512e95bf3cc1b536eac95dc4cf713e4fbd2187f8156d3cc77b21ab2c23f0f1613daf4fe37ab1a9eea3d5babb179c81f18d8ce59508ba7d7ed8a8b46042dfbec5435f8adbd14f354fa26e95ed44126c2b69f85f0d65998e38f779f4c482137f370cfff420cac48dcc6cf0cab1048ad862ff1e2ef3944189d7ae824b27acc03d875f7d314c084ff17053151dca2bcacb841e49f39acd586b9a7526d6a6c3f27358014ac068ea9d8ad4241b2586e5b695a6aecbc2150d0c9e7ac5a86ec926e48778130ccc33d05f9527993cca297d4ea3c392da0c3bdbfc176c0aa3fcfcde16b1a3f5fbe356ee3802e3cefebb830d9d81c73ca4b1e52476b953c76458541de4ea37470774af44f9747468b44ec56b32ea9de90a9373b3acf9c5f2783ab808434034483000deb2ab6ae188ffdef49045fdeb323556ebd82685079f893176eee71b73155faf7c51198f1e79fbee3de8407ccf50c4893849d336878f09ee4a670fdbf9ad1e48c6993b3d9eca7e7152b4b0734aa18b5dc69430a3ffa13879eae033e33b5ef79b7bd7affb016f3da34f6b22fa83e39ea347e0912314a0a013ab6f794aee569d2e2478853ddb33fe4fe7b57df8063d2481c077a2b302a662b63f6259547ceee27fd0c65134780020a9376bff0edae13552421a83672687db5bacf2e63
routing_info[1] (encrypted) = 0x305be68dc0d0424035547c17654e87d9496e181326712eebd9c8f0f9b248c33ab9c0c66044663a7528e46d6675206755af6d409672f60d76855d16b935e341786f74ddfea1c0d38bc6437fbdcb8f4569b37af3bfc074725fdb6e830635798b9ac39c7fc1a1af72b1b0b546b7156940602a990161b85b012a930c26514c2ebcc12f291cba3ab57cc54a63f73eb5d9d6c72e818a97fc66b47dabe8777755b46991d3a583cc2bd22084f50a9ee429cab70c78023df846a9f2ca81bd7b9868856a0fcbefa6851775906836cf9af8c94b588339fe516c02c1f60975d77d1f6f33f9e06fffda84e82785c78dba5669ff389b13c7182ad32db117d8680c7a11aefc861830d1d3c14cd7e614a1207fe6592692e5b1f6175436a8dbe9afcb6202e4dbdbbcab7b6fe207e455ce4f12f69a22768399779206c7131088c304ea04238974595da78aaa9df210b21d8d48c557c85fe3dedb49ed8d1c01f0c8c02684524abb095bb80036e2994534991d5eee30333f051c6943ac0e6674fd42a5d7bcdc3110c8803603f35cdbd5083212f4af2a6b8058e03bce9274118b2ee75dac83c18ffe57571de73e25dea352b64936370454386437b81da0a5fe7e49b618c230d27c6bbffd430b140955ed95984dab0d2c77b45fa692058d950072dfc2d3961c93776bb06e8e07a088667b6ce7a6cec0b414a774116b89c74ff106838016c691dde0542bfe09d8723703eb4af35a4a3452ebca621ff53e070f68a63e236f011b5a21e4d65fb20c963a6747a2318ad887fc359125c7cce5521644293120a0edddb97c83708ceb0220a29e9c806711227a4450f97ec0c4b604b99ad73fa74361899202dfee18585132c1d33211a5acc9d260a6406fd89ecb4472fe68313eafca0abdc45f6dadc473a3c357478abcb9b6e0abd6a492d64b97594a51246fc0e15ed4956dd2b83d994f739e711b8d8a936d06d5dfc03d8817895da80016b594a5d0cf538ac7aec3cc29351f0879f7e6b50abd3e813a6f4f6563005e113d24d2e87f711499e8bc861ea9d56b4dbcb99387c3f1b85047211fa01dcfe4f3aff19dea18145fbc84925349f7b552314ab8ed4c491e392aed3b1f03eb79474c294b42e2eba1528da26450
hop_payloads[1] (unencrypted) = 0x41414141414141414141414141414141414141413d0e608d2eb771b3056c56e43aeb1ac7a4a9a72405d26c501ef22bee3b3f7ab029cc7e722fe4e40717fc497cacbc2a900095eee0544b72b3010ac9e88f2a2a5e1de9e7284b425da9df8a86d4000476c23c36be6b6ab9f4da864841c27b2890cb9013f34e5cb8d3365936339fbe557677958525dd30b4b9f97acf2951d38521e14b56941093eff81b558a173f27d2809733c82cd4dd9463db001ea986c1c73b61bb31d3788b9a212fe5ed37dc44338242d4fc6d555e74d377daa01081dd1f90c122d2b1ddbcd417d6fc911f305ff73a62866febdd2d6ce6b9d22cd822e310413901bff799987c9659363d2c9f75b554d5ff85e0f9ece32c80cd700b2f77342855fc8ac1fe285be72d364236b517cc300de84dcd2d8719f3a93140e6fc05c3d546a338cc37094c9986802c4bb65da4c2cb4d116255db5f04ce284e93f93602462f40c4529a2d084afe4c4d99f9d7e5bb657d491244e44974b7856532abe4486045a131b1a735d04ebbb11d6ec660cfca4230a8a5c604bbc712382a031a
hop_payloads[1] (encrypted) = 0x7c5b6d02dba0b36a1bfb803e9d53f664efe8e46e0408463ca0a267185bca823fdf8f84826abca3b645f0344d62fc1f4c37f8398d1d9857e7cead76a01e81c3cdea1451c3d25fe76c154c77a5965230f4597569e2c5a2f4d569a3060a5a5d65a16ea8272d2388bcdf90921d0020509bb0b64b2030c785775450ea841cd7746a497f33ad729db0b495cad6691e5f06610d697c748e8d88d54c7ff17c633afc5fb7f6d498d9fd9aa5c7f46db244eade5cab91d178dfddfc43b99be87f583a3fa63f8e9e3d3e601f166f42c5d5e4f1fec6ebb094c18af7f176f73c4c047d36066c74d1126dc834b68008317ca5606e9f869060244675ea8e73a28df54a7eab58cb5c2e677137c92bad3f014df4616152d17c9c15057cf89b6d8da51dd26debbfb6c814f9da9aaa2abaca07931074b1e3f3b069e22d517624c9e14f8c2ea36d3ed3c3adb1439f5b4501298ada44ff89f6da50e46b7e9420dce8496e2a825b5d2a21325674ca0b3514ebb954e04addaf897646e6f5081055b46df323b207a17a757b9e0af3f6e52af86f197f27ebddbd781186
hmac_data[1] = 0x305be68dc0d0424035547c17654e87d9496e181326712eebd9c8f0f9b248c33ab9c0c66044663a7528e46d6675206755af6d409672f60d76855d16b935e341786f74ddfea1c0d38bc6437fbdcb8f4569b37af3bfc074725fdb6e830635798b9ac39c7fc1a1af72b1b0b546b7156940602a990161b85b012a930c26514c2ebcc12f291cba3ab57cc54a63f73eb5d9d6c72e818a97fc66b47dabe8777755b46991d3a583cc2bd22084f50a9ee429cab70c78023df846a9f2ca81bd7b9868856a0fcbefa6851775906836cf9af8c94b588339fe516c02c1f60975d77d1f6f33f9e06fffda84e82785c78dba5669ff389b13c7182ad32db117d8680c7a11aefc861830d1d3c14cd7e614a1207fe6592692e5b1f6175436a8dbe9afcb6202e4dbdbbcab7b6fe207e455ce4f12f69a22768399779206c7131088c304ea04238974595da78aaa9df210b21d8d48c557c85fe3dedb49ed8d1c01f0c8c02684524abb095bb80036e2994534991d5eee30333f051c6943ac0e6674fd42a5d7bcdc3110c8803603f35cdbd5083212f4af2a6b8058e03bce9274118b2ee75dac83c18ffe57571de73e25dea352b64936370454386437b81da0a5fe7e49b618c230d27c6bbffd430b140955ed95984dab0d2c77b45fa692058d950072dfc2d3961c93776bb06e8e07a088667b6ce7a6cec0b414a774116b89c74ff106838016c691dde0542bfe09d8723703eb4af35a4a3452ebca621ff53e070f68a63e236f011b5a21e4d65fb20c963a6747a2318ad887fc359125c7cce5521644293120a0edddb97c83708ceb0220a29e9c806711227a4450f97ec0c4b604b99ad73fa74361899202dfee18585132c1d33211a5acc9d260a6406fd89ecb4472fe68313eafca0abdc45f6dadc473a3c357478abcb9b6e0abd6a492d64b97594a51246fc0e15ed4956dd2b83d994f739e711b8d8a936d06d5dfc03d8817895da80016b594a5d0cf538ac7aec3cc29351f0879f7e6b50abd3e813a6f4f6563005e113d24d2e87f711499e8bc861ea9d56b4dbcb99387c3f1b85047211fa01dcfe4f3aff19dea18145fbc84925349f7b552314ab8ed4c491e392aed3b1f03eb79474c294b42e2eba1528da264507c5b6d02dba0b36a1bfb803e9d53f664efe8e46e0408463ca0a267185bca823fdf8f84826abca3b645f0344d62fc1f4c37f8398d1d9857e7cead76a01e81c3cdea1451c3d25fe76c154c77a5965230f4597569e2c5a2f4d569a3060a5a5d65a16ea8272d2388bcdf90921d0020509bb0b64b2030c785775450ea841cd7746a497f33ad729db0b495cad6691e5f06610d697c748e8d88d54c7ff17c633afc5fb7f6d498d9fd9aa5c7f46db244eade5cab91d178dfddfc43b99be87f583a3fa63f8e9e3d3e601f166f42c5d5e4f1fec6ebb094c18af7f176f73c4c047d36066c74d1126dc834b68008317ca5606e9f869060244675ea8e73a28df54a7eab58cb5c2e677137c92bad3f014df4616152d17c9c15057cf89b6d8da51dd26debbfb6c814f9da9aaa2abaca07931074b1e3f3b069e22d517624c9e14f8c2ea36d3ed3c3adb1439f5b4501298ada44ff89f6da50e46b7e9420dce8496e2a825b5d2a21325674ca0b3514ebb954e04addaf897646e6f5081055b46df323b207a17a757b9e0af3f6e52af86f197f27ebddbd7811864242424242424242424242424242424242424242424242424242424242424242
hmac[1] = 0xc2effbc713e2ca2e0a8bc193e92fc63d503875c8

rhokey[0] = 0xce496ec94def95aadd4bec15cdb41a740c9f2b62347c4917325fcc6fb0453986
gammakey[0] = 0xc5b96917bc536aff7c2d6584bd60cf3b99151ccac18f173133f1fd0bdcae08b5
mukey[0] = 0xb57061dc6d0a2b9f261ac410c8b26d64ac5506cbba30267a649c28c179400eba
routing_info[0] (unencrypted) = 0x14db4138d56a2ecfb10881a9be394d9f321985b2c2effbc713e2ca2e0a8bc193e92fc63d503875c8305be68dc0d0424035547c17654e87d9496e181326712eebd9c8f0f9b248c33ab9c0c66044663a7528e46d6675206755af6d409672f60d76855d16b935e341786f74ddfea1c0d38bc6437fbdcb8f4569b37af3bfc074725fdb6e830635798b9ac39c7fc1a1af72b1b0b546b7156940602a990161b85b012a930c26514c2ebcc12f291cba3ab57cc54a63f73eb5d9d6c72e818a97fc66b47dabe8777755b46991d3a583cc2bd22084f50a9ee429cab70c78023df846a9f2ca81bd7b9868856a0fcbefa6851775906836cf9af8c94b588339fe516c02c1f60975d77d1f6f33f9e06fffda84e82785c78dba5669ff389b13c7182ad32db117d8680c7a11aefc861830d1d3c14cd7e614a1207fe6592692e5b1f6175436a8dbe9afcb6202e4dbdbbcab7b6fe207e455ce4f12f69a22768399779206c7131088c304ea04238974595da78aaa9df210b21d8d48c557c85fe3dedb49ed8d1c01f0c8c02684524abb095bb80036e2994534991d5eee30333f051c6943ac0e6674fd42a5d7bcdc3110c8803603f35cdbd5083212f4af2a6b8058e03bce9274118b2ee75dac83c18ffe57571de73e25dea352b64936370454386437b81da0a5fe7e49b618c230d27c6bbffd430b140955ed95984dab0d2c77b45fa692058d950072dfc2d3961c93776bb06e8e07a088667b6ce7a6cec0b414a774116b89c74ff106838016c691dde0542bfe09d8723703eb4af35a4a3452ebca621ff53e070f68a63e236f011b5a21e4d65fb20c963a6747a2318ad887fc359125c7cce5521644293120a0edddb97c83708ceb0220a29e9c806711227a4450f97ec0c4b604b99ad73fa74361899202dfee18585132c1d33211a5acc9d260a6406fd89ecb4472fe68313eafca0abdc45f6dadc473a3c357478abcb9b6e0abd6a492d64b97594a51246fc0e15ed4956dd2b83d994f739e711b8d8a936d06d5dfc03d8817895da80016b594a5d0cf538ac7aec3cc29351f0879f7e6b50abd3e813a6f4f6563005e113d24d2e87f711499e8bc861ea9d56b4dbcb99387c3f1b85047211fa01dcfe4f3aff19d
routing_info[0] (encrypted) = 0xf12a026817cd410d83bd65c4fc27db8a75033c527e678028eb2b95f58d04baa9986e83030fb5577e0543f62394cca6d995cf368aface565d15e778db79b7ff43a21abbd556d1e1b33753959a62e6bcb5220cda916d603c2702554c4dc17a8896af5d54c7815efcd093a0f6bad14a4d7622df88ee7cd1fe512882beb43b81f7cf3e7e633262538a7eca5f76f8434bd2215c7dda800d49ef34caf74bb4f1064f72e28fa39de96ff993cf51e26512faa0e98fa387f517c3bc4a65f6d8ca27af1d81025a85edf9e3ea7f580854c5d3ce537b955ff216c7a88dfc0bb795bfdf053300c70a1f6f23126c83b3c96a806e0cda3c3bb5cf1c57e77e25aafd117f2c559c914797cdd27440d7d033ef987178e337a899b597a34cd6f471ce40ca44b234fa0730603b1d4ad215bce719d02b98882268551912ce1f14a3a8c968649b09fb9acf69f48046e2464536d734f705e2d4a996c176786ec437b5d0f62731b251c56f67ae4169167fab24673af60d88d3252bf38f8c1ebd85986bbe25f7f0a4399d947d5b15b7ad9050b3a4f67b0720e372a56fa2da6468ec436ca7425bfedccb4186dbbc28663941a2b5473ff853dbfce8327ffb1209940d5b3c9f8d6643d11238da66e35715b5d5410b93bb5c9ed25e7695c3d2a8073e7e5373dcbdab46c50aba3d238573b333b68bdf1c209933e75e27960fc78880e8429a88c24878c2abd541a0afd0e0c364517e0e8064a94ff1cde8885b19d60d30304c5f7bbc7afa64befbdd2095b47730fdcc6aacd6cf927b6c981efad29de9c575c8663b545dc57e7dbc1b7a09bf6584d5c5b1e748c0300903d09b8b33adf548b0f4a9198c7b0f5c4b4c0e3af9fcc9af4860a23aec993996e36aefff3157259147f0536ea64d23329178f3dd95e37e0019e5ab4654325b59544bf3caa891617b59978b3d21785d36166721358a99c90bd2b8364c475b7f8058219269e561303dfd1d84042543e85d954bcd5eeb4ff897aeb2988ed3d905b3c73377be03ef8817d8595f2596e7afa6a0aa121b176738fd578be920b9cf778bd92808e5bd3d8d0decd00bdc2560a22921f138af042f38c923693494237844c13c85b4d0235c462af39d519d4fbb0309805fff51
hop_payloads[0] (unencrypted) = 0x41414141414141414141414141414141414141417c5b6d02dba0b36a1bfb803e9d53f664efe8e46e0408463ca0a267185bca823fdf8f84826abca3b645f0344d62fc1f4c37f8398d1d9857e7cead76a01e81c3cdea1451c3d25fe76c154c77a5965230f4597569e2c5a2f4d569a3060a5a5d65a16ea8272d2388bcdf90921d0020509bb0b64b2030c785775450ea841cd7746a497f33ad729db0b495cad6691e5f06610d697c748e8d88d54c7ff17c633afc5fb7f6d498d9fd9aa5c7f46db244eade5cab91d178dfddfc43b99be87f583a3fa63f8e9e3d3e601f166f42c5d5e4f1fec6ebb094c18af7f176f73c4c047d36066c74d1126dc834b68008317ca5606e9f869060244675ea8e73a28df54a7eab58cb5c2e677137c92bad3f014df4616152d17c9c15057cf89b6d8da51dd26debbfb6c814f9da9aaa2abaca07931074b1e3f3b069e22d517624c9e14f8c2ea36d3ed3c3adb1439f5b4501298ada44ff89f6da50e46b7e9420dce8496e2a825b5d2a21325674ca0b3514ebb954e04addaf897646e6f5081055b46df323b207a1
hop_payloads[0] (encrypted) = 0xa51d2a1675eb1be407e116535f455d966fc5a33d05d1b7b7aa4cee07f1bfff801a9bd08a9c6e730771a4bf6a646c2f9e2a90bda866a6fecb3e79981f0048309aac743972adda805075163ed26a5af81bc8fe32606fc23d362dd240c5b601b78cfb31fc350de0cacc356fd62dbf6d6fcdaed073647490573c6eca5432b566cde10369f984b036310991b8965d71c85a667ee5b1d2d043aa4e4d239fda39474626a7840708cb9b7a5311d6f187f8f485ec91e5768007db224e38ff189dd809b1604cf067fa3fd54fee9c9176396cef8664557e2550f89858071da37a96c17c2a5c1e73feeab9b09d32ba7efbc6b18f9b1c4d85abb2dfb4648e0e6b12a3dd9fe96e6e5317ffe32c7b4b3796e8599b7a4caf4ad1b980350b8e7c8544871d7702f3e8c0a265bd658389fde9850570877856e66e29e16bdd9f2a6f6106e454e531d8b7062d3086b8c61f88677bfdb5e0b8bb6654e206e2123edb48d2b18c4316ab393ae41e570e144af52a7e5d3515260b387750e205596828940376ae31e55476b7fa3d5d4abf2ab586ece8acf42c4b2ca0c4
hmac_data[0] = 0xf12a026817cd410d83bd65c4fc27db8a75033c527e678028eb2b95f58d04baa9986e83030fb5577e0543f62394cca6d995cf368aface565d15e778db79b7ff43a21abbd556d1e1b33753959a62e6bcb5220cda916d603c2702554c4dc17a8896af5d54c7815efcd093a0f6bad14a4d7622df88ee7cd1fe512882beb43b81f7cf3e7e633262538a7eca5f76f8434bd2215c7dda800d49ef34caf74bb4f1064f72e28fa39de96ff993cf51e26512faa0e98fa387f517c3bc4a65f6d8ca27af1d81025a85edf9e3ea7f580854c5d3ce537b955ff216c7a88dfc0bb795bfdf053300c70a1f6f23126c83b3c96a806e0cda3c3bb5cf1c57e77e25aafd117f2c559c914797cdd27440d7d033ef987178e337a899b597a34cd6f471ce40ca44b234fa0730603b1d4ad215bce719d02b98882268551912ce1f14a3a8c968649b09fb9acf69f48046e2464536d734f705e2d4a996c176786ec437b5d0f62731b251c56f67ae4169167fab24673af60d88d3252bf38f8c1ebd85986bbe25f7f0a4399d947d5b15b7ad9050b3a4f67b0720e372a56fa2da6468ec436ca7425bfedccb4186dbbc28663941a2b5473ff853dbfce8327ffb1209940d5b3c9f8d6643d11238da66e35715b5d5410b93bb5c9ed25e7695c3d2a8073e7e5373dcbdab46c50aba3d238573b333b68bdf1c209933e75e27960fc78880e8429a88c24878c2abd541a0afd0e0c364517e0e8064a94ff1cde8885b19d60d30304c5f7bbc7afa64befbdd2095b47730fdcc6aacd6cf927b6c981efad29de9c575c8663b545dc57e7dbc1b7a09bf6584d5c5b1e748c0300903d09b8b33adf548b0f4a9198c7b0f5c4b4c0e3af9fcc9af4860a23aec993996e36aefff3157259147f0536ea64d23329178f3dd95e37e0019e5ab4654325b59544bf3caa891617b59978b3d21785d36166721358a99c90bd2b8364c475b7f8058219269e561303dfd1d84042543e85d954bcd5eeb4ff897aeb2988ed3d905b3c73377be03ef8817d8595f2596e7afa6a0aa121b176738fd578be920b9cf778bd92808e5bd3d8d0decd00bdc2560a22921f138af042f38c923693494237844c13c85b4d0235c462af39d519d4fbb0309805fff51a51d2a1675eb1be407e116535f455d966fc5a33d05d1b7b7aa4cee07f1bfff801a9bd08a9c6e730771a4bf6a646c2f9e2a90bda866a6fecb3e79981f0048309aac743972adda805075163ed26a5af81bc8fe32606fc23d362dd240c5b601b78cfb31fc350de0cacc356fd62dbf6d6fcdaed073647490573c6eca5432b566cde10369f984b036310991b8965d71c85a667ee5b1d2d043aa4e4d239fda39474626a7840708cb9b7a5311d6f187f8f485ec91e5768007db224e38ff189dd809b1604cf067fa3fd54fee9c9176396cef8664557e2550f89858071da37a96c17c2a5c1e73feeab9b09d32ba7efbc6b18f9b1c4d85abb2dfb4648e0e6b12a3dd9fe96e6e5317ffe32c7b4b3796e8599b7a4caf4ad1b980350b8e7c8544871d7702f3e8c0a265bd658389fde9850570877856e66e29e16bdd9f2a6f6106e454e531d8b7062d3086b8c61f88677bfdb5e0b8bb6654e206e2123edb48d2b18c4316ab393ae41e570e144af52a7e5d3515260b387750e205596828940376ae31e55476b7fa3d5d4abf2ab586ece8acf42c4b2ca0c44242424242424242424242424242424242424242424242424242424242424242
hmac[0] = 0x5fcf66568cad9ad9d61c8b05ffeb2ef00bf32dbf

Final Packet

onionpacket = 0x0102eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f2836866195fcf66568cad9ad9d61c8b05ffeb2ef00bf32dbff12a026817cd410d83bd65c4fc27db8a75033c527e678028eb2b95f58d04baa9986e83030fb5577e0543f62394cca6d995cf368aface565d15e778db79b7ff43a21abbd556d1e1b33753959a62e6bcb5220cda916d603c2702554c4dc17a8896af5d54c7815efcd093a0f6bad14a4d7622df88ee7cd1fe512882beb43b81f7cf3e7e633262538a7eca5f76f8434bd2215c7dda800d49ef34caf74bb4f1064f72e28fa39de96ff993cf51e26512faa0e98fa387f517c3bc4a65f6d8ca27af1d81025a85edf9e3ea7f580854c5d3ce537b955ff216c7a88dfc0bb795bfdf053300c70a1f6f23126c83b3c96a806e0cda3c3bb5cf1c57e77e25aafd117f2c559c914797cdd27440d7d033ef987178e337a899b597a34cd6f471ce40ca44b234fa0730603b1d4ad215bce719d02b98882268551912ce1f14a3a8c968649b09fb9acf69f48046e2464536d734f705e2d4a996c176786ec437b5d0f62731b251c56f67ae4169167fab24673af60d88d3252bf38f8c1ebd85986bbe25f7f0a4399d947d5b15b7ad9050b3a4f67b0720e372a56fa2da6468ec436ca7425bfedccb4186dbbc28663941a2b5473ff853dbfce8327ffb1209940d5b3c9f8d6643d11238da66e35715b5d5410b93bb5c9ed25e7695c3d2a8073e7e5373dcbdab46c50aba3d238573b333b68bdf1c209933e75e27960fc78880e8429a88c24878c2abd541a0afd0e0c364517e0e8064a94ff1cde8885b19d60d30304c5f7bbc7afa64befbdd2095b47730fdcc6aacd6cf927b6c981efad29de9c575c8663b545dc57e7dbc1b7a09bf6584d5c5b1e748c0300903d09b8b33adf548b0f4a9198c7b0f5c4b4c0e3af9fcc9af4860a23aec993996e36aefff3157259147f0536ea64d23329178f3dd95e37e0019e5ab4654325b59544bf3caa891617b59978b3d21785d36166721358a99c90bd2b8364c475b7f8058219269e561303dfd1d84042543e85d954bcd5eeb4ff897aeb2988ed3d905b3c73377be03ef8817d8595f2596e7afa6a0aa121b176738fd578be920b9cf778bd92808e5bd3d8d0decd00bdc2560a22921f138af042f38c923693494237844c13c85b4d0235c462af39d519d4fbb0309805fff51a51d2a1675eb1be407e116535f455d966fc5a33d05d1b7b7aa4cee07f1bfff801a9bd08a9c6e730771a4bf6a646c2f9e2a90bda866a6fecb3e79981f0048309aac743972adda805075163ed26a5af81bc8fe32606fc23d362dd240c5b601b78cfb31fc350de0cacc356fd62dbf6d6fcdaed073647490573c6eca5432b566cde10369f984b036310991b8965d71c85a667ee5b1d2d043aa4e4d239fda39474626a7840708cb9b7a5311d6f187f8f485ec91e5768007db224e38ff189dd809b1604cf067fa3fd54fee9c9176396cef8664557e2550f89858071da37a96c17c2a5c1e73feeab9b09d32ba7efbc6b18f9b1c4d85abb2dfb4648e0e6b12a3dd9fe96e6e5317ffe32c7b4b3796e8599b7a4caf4ad1b980350b8e7c8544871d7702f3e8c0a265bd658389fde9850570877856e66e29e16bdd9f2a6f6106e454e531d8b7062d3086b8c61f88677bfdb5e0b8bb6654e206e2123edb48d2b18c4316ab393ae41e570e144af52a7e5d3515260b387750e205596828940376ae31e55476b7fa3d5d4abf2ab586ece8acf42c4b2ca0c4

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.