2016-11-15 02:23:20 +01:00
# BOLT #4: Onion Routing Protocol
2016-11-14 20:42:56 +01:00
## 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 ](http://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf )
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
2016-12-07 10:04:57 +01:00
There are a number of conventions we will adhere to throughout the document:
2016-11-14 20:42:56 +01:00
- 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` ](https://en.bitcoin.it/wiki/Script#Crypto ) for
details.
2016-12-11 11:44:07 +01:00
- HMAC: the integrity verification of the packet is based on Keyed-Hash Message Authentication Code as defined by the [FIPS 198 Standard ](http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf )/[RFC 2104](https://tools.ietf.org/html/rfc2104), using `SHA256` as hashing algorithm.
2016-11-14 20:42:56 +01:00
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` ](http://www.secg.org/sec2-v2.pdf ), is used.
- Pseudo-Random Stream: [`ChaCha20` ](https://tools.ietf.org/html/rfc7539 ) 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
2016-12-07 10:04:57 +01:00
A number of encryption and verification keys are derived from the shared secret:
2016-11-14 20:42:56 +01:00
2016-12-08 07:54:35 +01:00
- _rho_: used as key when generating the pseudo-random byte stream
2016-11-14 20:42:56 +01:00
used to obfuscate the routing information.
2016-12-08 07:54:35 +01:00
- _gamma_: used as key when generating the pseudo-random byte stream used to obfuscate the per-hop payloads.
2016-11-14 20:42:56 +01:00
- _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
2016-12-08 07:54:35 +01:00
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`).
2016-11-14 20:42:56 +01:00
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.
2016-12-07 10:04:57 +01:00
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.
2016-11-14 20:42:56 +01:00
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
2016-12-07 10:04:57 +01:00
below. In addition, every _(address, HMAC)_ -pair is incrementally
2016-11-14 20:42:56 +01:00
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.
2016-12-20 01:24:42 +01:00
### 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:
```
+----------------+--------------------------+-------------------------------+--------------------------------------------+
2017-01-06 00:26:11 +01:00
| realm (1 byte) | amt_to_forward (8 bytes) | outgoing_cltv_value (2 bytes) | unused_with_v0_version_on_header (9 bytes) |
2016-12-20 01:24:42 +01:00
+----------------+--------------------------+-------------------------------+--------------------------------------------+
```
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 ](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#htlc-fees ).
2017-01-06 00:26:11 +01:00
* `outgoing_cltv_value` - The CLTV value that the _outgoing_ HTLC carrying
2016-12-20 01:24:42 +01:00
the packet should have.
2017-01-06 00:26:11 +01:00
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.
2016-12-20 01:24:42 +01:00
If the values don't correspond, then the HTLC should be failed+rejected as
2017-01-06 00:26:11 +01:00
this indicates the incoming node has tampered with the intended HTLC
values, or the origin has an obsolete `cltv-expiry-delta` value.
2016-12-20 01:24:42 +01:00
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.
2016-11-14 20:42:56 +01:00
## 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.
2016-12-08 07:54:35 +01:00
The _rho_ -key is used to generate 800 bytes of pseudo-random byte stream and applied with `XOR` to the routing info field.
2016-11-14 20:42:56 +01:00
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.
2016-12-08 07:54:35 +01:00
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.
2016-11-14 20:42:56 +01:00
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:
```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
2016-12-07 10:04:57 +01:00
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.
2016-11-14 20:42:56 +01:00
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.
2016-12-08 07:54:35 +01:00
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.
2016-11-14 20:42:56 +01:00
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.
2016-12-08 07:54:35 +01:00
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.
2016-11-14 20:42:56 +01:00
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.
2016-12-12 01:11:45 +01:00
The DER compressed representation of the multiplication result is serialized and hashed using `SHA256` .
2016-11-14 20:42:56 +01:00
The resulting hash is returned as the shared secret.
2016-12-12 01:11:45 +01:00
Notice that this is the ECDH variant implemented in `libsecp256k1` .
2016-11-14 20:42:56 +01:00
## Filler Generation
2016-12-07 10:04:57 +01:00
Upon receiving a packet, each node extracts the information destined for that node from the route info and the per-hop payload.
2016-11-14 20:42:56 +01:00
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.
2016-12-07 10:04:57 +01:00
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` .
2016-12-08 07:54:35 +01:00
It then generates the pseudo-random byte stream of matching length and applies it with `XOR` to the field.
2016-11-14 20:42:56 +01:00
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:
```Go
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))
2016-12-08 07:54:35 +01:00
// Generate pseudo-random byte stream
2016-11-14 20:42:56 +01:00
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.
2017-01-06 00:24:11 +01:00
## Returning Errors
2016-11-14 20:42:56 +01:00
2017-01-06 00:24:11 +01:00
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.
2016-11-14 20:42:56 +01:00
2017-01-06 00:24:11 +01:00
Intermediate hops store the shared secret from the forward path and reuse it to obfuscate the error packet on each hop.
2016-11-14 20:42:56 +01:00
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:
2017-01-06 00:26:44 +01:00
1. data:
* [20:hmac]
2017-01-06 02:32:28 +01:00
* [2:failure-len]
* [failure-len:failuremsg]
2017-01-06 00:26:44 +01:00
* [2:pad-len]
* [pad-len:pad]
2017-01-06 02:32:28 +01:00
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.
2017-01-06 00:26:44 +01:00
2017-01-06 02:32:28 +01:00
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.
2016-11-14 20:42:56 +01:00
The node then generates a new key, using the key type `ammag` .
2017-01-06 00:26:44 +01:00
This key is then used to generate a pseudo-random stream, which is then applied to the packet using `XOR` .
2016-11-14 20:42:56 +01:00
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.
2016-11-22 20:52:59 +01:00
2017-01-06 02:32:28 +01:00
### Failure Messages
2017-01-06 00:26:44 +01:00
2017-01-06 02:32:28 +01:00
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
2017-01-06 00:26:44 +01:00
these codes when creating an error message, and MUST include the
2017-01-06 02:32:28 +01:00
appropriate data.
2017-01-06 00:26:44 +01:00
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:
2017-01-06 02:32:28 +01:00
* 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
2017-01-06 00:26:44 +01:00
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 the`update_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 the amount
expected, the final node SHOULD fail the HTLC:
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
2017-01-06 02:32:28 +01:00
A node MUST ignore any extra bytes in `failuremsg` .
2017-01-06 00:26:44 +01:00
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_update` s.
* 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.
2017-01-10 15:33:34 +01:00
## 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
2017-01-13 18:11:48 +01:00
hop_shared_secret[0] = 0x53eb63ea8a3fec3b3cd433b85cd62a4b145e1dda09391b348c4e1cd36a03ea66
hop_blinding_factor[0] = 0x2ec2e5da605776054187180343287683aa6a51b4b1c04d6dd49c45d8cffb3c36
2017-01-10 15:33:34 +01:00
hop_ephemeral_pubkey[0] = 0x02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619
2017-01-13 18:11:48 +01:00
hop_shared_secret[1] = 0xa6519e98832a0b179f62123b3567c106db99ee37bef036e783263602f3488fae
hop_blinding_factor[1] = 0xbf66c28bc22e598cfd574a1931a2bafbca09163df2261e6d0056b2610dab938f
hop_ephemeral_pubkey[1] = 0x028f9438bfbf7feac2e108d677e3a82da596be706cc1cf342b75c7b7e22bf4e6e2
2017-01-10 15:33:34 +01:00
2017-01-13 18:11:48 +01:00
hop_shared_secret[2] = 0x3a6b412548762f0dbccce5c7ae7bb8147d1caf9b5471c34120b30bc9c04891cc
hop_blinding_factor[2] = 0xa1f2dadd184eb1627049673f18c6325814384facdee5bfd935d9cb031a1698a5
hop_ephemeral_pubkey[2] = 0x03bfd8225241ea71cd0843db7709f4c222f62ff2d4516fd38b39914ab6b83e0da0
2017-01-10 15:33:34 +01:00
2017-01-13 18:11:48 +01:00
hop_shared_secret[3] = 0x21e13c2d7cfe7e18836df50872466117a295783ab8aab0e7ecc8c725503ad02d
hop_blinding_factor[3] = 0x7cfe0b699f35525029ae0fa437c69d0f20f7ed4e3916133f9cacbb13c82ff262
hop_ephemeral_pubkey[3] = 0x031dde6926381289671300239ea8e57ffaf9bebd05b9a5b95beaf07af05cd43595
2017-01-10 15:33:34 +01:00
2017-01-13 18:11:48 +01:00
hop_shared_secret[4] = 0xb5756b9b542727dbafc6765a49488b023a725d631af688fc031217e90770c328
hop_blinding_factor[4] = 0xc96e00dddaf57e7edcd4fb5954be5b65b09f17cb6d20651b4e90315be5779205
hop_ephemeral_pubkey[4] = 0x03a214ebd875aab6ddfd77f22c5e7311d7f77f17a169e599f157bbcdae8bf071f4
2017-01-10 15:33:34 +01:00
#### Per-Packet Information
2017-01-13 18:11:48 +01:00
filler = 0x80b23adf2c3947dab3b92bb1c5f70fa32f866cc09aff45c5bc4da1ed291660791aa9a1c5d28fbf8f4ecb4bf7c0a9454c82923e24c7fd0d192ea8e2ead1f17388341f313915949b602d5de1f5cb94b77d42c7dfe84edc13cf9acf541e8243989d967e7d568f26f9209bb52d9f90bfa902f3ec6e3ae9d6215c432206cd3132b69257408002aa020f2fbae32a2d5abee0a3c9fd56329b033939cd6366fbb339aa14
hop_filler = 0x2e86897a3ae52daba4a5940cfc305ae15e9a0f8a8ac1033a15d8a14819acab6503c9df44cdaaf30629283e3458844a44a5c4bfdebdcb15fd3edb8e286124d7b47fa7a56bcc5655d2ad9809f108f238e5
2017-01-10 15:33:34 +01:00
#### Wrapping the Onion
2017-01-13 18:11:48 +01:00
rhokey[4] = 0x034e18b8cc718e8af6339106e706c52d8df89e2b1f7e9142d996acf88df8799b
gammakey[4] = 0x8b30d62d76ba081e833c88946d220e4471f9c3c943485e4ff5165eff71f0f7e6
mukey[4] = 0x8e45e5c61c2b24cb6382444db6698727afb063adecd72aada233d4bf273d975a
2017-01-10 15:33:34 +01:00
routing_info[4] (unencrypted) = 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2017-01-13 18:11:48 +01:00
routing_info[4] (encrypted) = 0xf6adec5a586e005ccd8282b782ffe8efb6f3f0e2cee0283a71aa4d873686d7efeac03dcb113fd91113df4bb5d5e8c13cde4bd12eced21d367381fdc31efe09695d6ecc095083c1571d10ed076ee914745479dfedcab84efd3889e6375f544562ea4a6522035738a9ba1a9ab4204339569d3d0c217324f1d5f3a107e930ade50b913777d1140096e2b26ce47486b66a6740f026ae91429115e17270c5a542b4c82ce438725060248726956e7639da64a55cec00b61719383271e0ab97dafe44ad194e7338ea841bf25a505d0041eb53dc0d0e6c3f7986f6647ede9327467212a3ca5724ece8503bfaba3800372d747abe2c174cbc2da01dd967fc0bae56d2bc7184e1d5d823661b8ff06eb466d483d6fa69a4f8b592ebc3006b7c047055b12407925ea74c2bb09ca21f4bc9d39dc4a7237ef6facbb15f5ba56d8e2ab94ad24267bf85cea55b0605cd6260b4b0f17994a03e39bebfcad0834849b188e83bf5c954dc112d33b0fada26f25d76d53ec9b95ed344059a279719d5edc953a4de2b1cc4f47d5da090c3b0f4c7eef14830f9a2230bffb722f11fd2ea82c43d58261e5a868361262abbd81b9f1e6145562ed6765aac732e7d91bfff7716509d72314d46904bcc8053cfd1e3cd7824b4b6499bf8c77762275fa4f651d163a8701f02a5ca67bb7d37787a66d269d4079aa92a489493020b11d87791a3e3ef66780bd0007c8fa2782bac7a839b57e8ace7618a75fe03604097960d2236616d579207fb943c85bef4f804e7f13d7d78ff3aab0f7f440a3005a363f32c31567b8d64669a7ae0299b06b80e4d224d2d70b80077ff966cfb8c11cf763954f398c592ca619acc2e0e86dad54b9cfa47bc10520f3c9ba2e0d2e27e0ba8ef8ece3e71c8a1ff75fe0c8369a3555e42db30565b2e12a8e862d0f873bd781ebf8255372e540bf6fbf4c1dae200823144f8da8df82ccd41b1b678eb91a289b88c6ee5aff71d98b64e8b17e2027fcb6826c418dbdb51f06bec866d69d9554931412808bd90021be2e0dad1d1ececfdd41fcdf6f67b88ef09eb9edcc4c226e07bdfe86b8e50e3bf68b19c0c9e0bf9aaaaddb15bc05a5666733789fa6efde866a49d0329185d852dc84a7e16c4
2017-01-10 15:33:34 +01:00
hop_payloads[4] (unencrypted) = 0x41414141414141414141414141414141414141410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2017-01-13 18:11:48 +01:00
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
2017-01-10 15:33:34 +01:00
#### Final Packet
2017-01-13 18:11:48 +01:00
onionpacket = 0x0102eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f2836866195fcf66568cad9ad9d61c8b05ffeb2ef00bf32dbff12a026817cd410d83bd65c4fc27db8a75033c527e678028eb2b95f58d04baa9986e83030fb5577e0543f62394cca6d995cf368aface565d15e778db79b7ff43a21abbd556d1e1b33753959a62e6bcb5220cda916d603c2702554c4dc17a8896af5d54c7815efcd093a0f6bad14a4d7622df88ee7cd1fe512882beb43b81f7cf3e7e633262538a7eca5f76f8434bd2215c7dda800d49ef34caf74bb4f1064f72e28fa39de96ff993cf51e26512faa0e98fa387f517c3bc4a65f6d8ca27af1d81025a85edf9e3ea7f580854c5d3ce537b955ff216c7a88dfc0bb795bfdf053300c70a1f6f23126c83b3c96a806e0cda3c3bb5cf1c57e77e25aafd117f2c559c914797cdd27440d7d033ef987178e337a899b597a34cd6f471ce40ca44b234fa0730603b1d4ad215bce719d02b98882268551912ce1f14a3a8c968649b09fb9acf69f48046e2464536d734f705e2d4a996c176786ec437b5d0f62731b251c56f67ae4169167fab24673af60d88d3252bf38f8c1ebd85986bbe25f7f0a4399d947d5b15b7ad9050b3a4f67b0720e372a56fa2da6468ec436ca7425bfedccb4186dbbc28663941a2b5473ff853dbfce8327ffb1209940d5b3c9f8d6643d11238da66e35715b5d5410b93bb5c9ed25e7695c3d2a8073e7e5373dcbdab46c50aba3d238573b333b68bdf1c209933e75e27960fc78880e8429a88c24878c2abd541a0afd0e0c364517e0e8064a94ff1cde8885b19d60d30304c5f7bbc7afa64befbdd2095b47730fdcc6aacd6cf927b6c981efad29de9c575c8663b545dc57e7dbc1b7a09bf6584d5c5b1e748c0300903d09b8b33adf548b0f4a9198c7b0f5c4b4c0e3af9fcc9af4860a23aec993996e36aefff3157259147f0536ea64d23329178f3dd95e37e0019e5ab4654325b59544bf3caa891617b59978b3d21785d36166721358a99c90bd2b8364c475b7f8058219269e561303dfd1d84042543e85d954bcd5eeb4ff897aeb2988ed3d905b3c73377be03ef8817d8595f2596e7afa6a0aa121b176738fd578be920b9cf778bd92808e5bd3d8d0decd00bdc2560a22921f138af042f38c923693494237844c13c85b4d0235c462af39d519d4fbb0309805fff51a51d2a1675eb1be407e116535f455d966fc5a33d05d1b7b7aa4cee07f1bfff801a9bd08a9c6e730771a4bf6a646c2f9e2a90bda866a6fecb3e79981f0048309aac743972adda805075163ed26a5af81bc8fe32606fc23d362dd240c5b601b78cfb31fc350de0cacc356fd62dbf6d6fcdaed073647490573c6eca5432b566cde10369f984b036310991b8965d71c85a667ee5b1d2d043aa4e4d239fda39474626a7840708cb9b7a5311d6f187f8f485ec91e5768007db224e38ff189dd809b1604cf067fa3fd54fee9c9176396cef8664557e2550f89858071da37a96c17c2a5c1e73feeab9b09d32ba7efbc6b18f9b1c4d85abb2dfb4648e0e6b12a3dd9fe96e6e5317ffe32c7b4b3796e8599b7a4caf4ad1b980350b8e7c8544871d7702f3e8c0a265bd658389fde9850570877856e66e29e16bdd9f2a6f6106e454e531d8b7062d3086b8c61f88677bfdb5e0b8bb6654e206e2123edb48d2b18c4316ab393ae41e570e144af52a7e5d3515260b387750e205596828940376ae31e55476b7fa3d5d4abf2ab586ece8acf42c4b2ca0c4
2017-01-10 15:33:34 +01:00
2016-11-22 20:52:59 +01:00
< br >
This work is licensed under a [Creative Commons Attribution 4.0 International License ](http://creativecommons.org/licenses/by/4.0/ ).
