├── .aspell.en.pws
├── .copy-edit-stylesheet-checklist.md
├── .gitattributes
├── .travis.yml
├── 00-introduction.md
├── 01-messaging.md
├── 02-peer-protocol.md
├── 03-transactions.md
├── 04-onion-routing.md
├── 05-onchain.md
├── 07-routing-gossip.md
├── 08-transport.md
├── 09-features.md
├── 10-dns-bootstrap.md
├── 11-payment-encoding.md
├── 12-offer-encoding.md
├── CONTRIBUTING.md
├── CoC.md
├── README.md
├── bolt04
├── blinded-onion-message-onion-test.json
├── blinded-payment-onion-test.json
├── onion-error-test.json
├── onion-test.json
└── route-blinding-test.json
├── bolt07
└── extended-queries.json
├── bolt12
├── format-string-test.json
├── offers-test.json
└── signature-test.json
├── proposals
└── route-blinding.md
└── tools
├── bolt3-bitcoind-test.sh
├── extract-formats.py
└── spellcheck.sh
/.aspell.en.pws:
--------------------------------------------------------------------------------
1 | personal_ws-1.1 en 264
2 | bitfields
3 | checksums
4 | timestamps
5 | tlv
6 | tlvs
7 | subtype
8 | TLV
9 | py
10 | vsprintf
11 | glibc
12 | JSON
13 | Freenode
14 | nacks
15 | secp
16 | sig
17 | unguessable
18 | libsecp
19 | TCP
20 | DER
21 | micropayments
22 | nhops
23 | retransmitted
24 | dev
25 | tradeoff
26 | kiloweight
27 | mixHeader
28 | uint
29 | hopsData
30 | bitfield
31 | B'th
32 | decrypting
33 | rhokey
34 | rhoKey
35 | buf
36 | millisatoshis
37 | yToX
38 | funder's
39 | IRATEMONK
40 | wpkh
41 | nextHmac
42 | basepoint
43 | streamKey
44 | localpubkey
45 | paymentPath
46 | SPV
47 | HopData
48 | CSV
49 | xFFFFFFFFFF
50 | plaintext
51 | EQUALVERIFY
52 | AEAD
53 | secretkey
54 | TripleDH
55 | addr
56 | CHECKMULTISIG
57 | decryptWithAD
58 | routable
59 | epk
60 | scriptpubkey
61 | mukey
62 | muKey
63 | sharedSecretSize
64 | DUP
65 | sharedSecrets
66 | xFFFFFFFFFFFF
67 | cryptographic
68 | generateSharedSecret
69 | instantiations
70 | deterministically
71 | deduplication
72 | FIPS
73 | responder
74 | UTF
75 | blockchain
76 | Blockstream
77 | nSequence
78 | decrypt
79 | flen
80 | incrementing
81 | feerate
82 | affine
83 | CHECKSEQUENCEVERIFY
84 | nonces
85 | iff
86 | serializeCompressed
87 | prepended
88 | roasbeef
89 | multisig
90 | nodepk
91 | remotesig
92 | hopBlindingFactors
93 | ECDH
94 | addrlen
95 | assocData
96 | ActOne
97 | ammag
98 | computeBlindingFactor
99 | wsh
100 | multiScalarMult
101 | onionpacket
102 | OnionPacket
103 | ikm
104 | fillerSize
105 | txinput
106 | init
107 | reconnection
108 | milli
109 | revocationsig
110 | NOTIF
111 | generateHeaderPadding
112 | IPv
113 | ipv
114 | satoshi
115 | delayedsig
116 | hopDataSize
117 | I'th
118 | segwit
119 | RBF
120 | accepter
121 | accepter's
122 | subtype
123 | redeemScript
124 | scriptSig
125 | utxo
126 | scriptPubKey
127 | scriptPubKeys
128 | scriptlen
129 | sats
130 | htlc
131 | htlcs
132 | ChaCha
133 | len
134 | ciphertext
135 | endian
136 | C'mon
137 | NewOnionPacket
138 | keypair
139 | preimage
140 | MiTM
141 | mempool
142 | cltv
143 | localfeatures
144 | iteratively
145 | PrivateKey
146 | br
147 | millisatoshi
148 | trustless
149 | ee
150 | eg
151 | hopSize
152 | retransmit
153 | retransmittal
154 | deobfuscating
155 | onchain
156 | BADONION
157 | rightShift
158 | protocolName
159 | hopEphemeralPubKeys
160 | txid
161 | Fn
162 | PublicKey
163 | encryptWithAD
164 | liveness
165 | ie
166 | shakin
167 | txin
168 | globalfeatures
169 | calcMac
170 | privkey
171 | overpayment
172 | hopSharedSecrets
173 | TimeLocked
174 | timelocked
175 | lc
176 | btcec
177 | localsig
178 | responder's
179 | ripemd
180 | md
181 | ENDIF
182 | blockchains
183 | cleartext
184 | streamBytes
185 | WISTFULTOLL
186 | locktime
187 | xFFF
188 | localprivkey
189 | deserialized
190 | pubkey
191 | PubKey
192 | ok
193 | Retransmissions
194 | numHops
195 | failuremsg
196 | fundee
197 | byteslen
198 | shortid
199 | se
200 | rk
201 | micropayment
202 | rn
203 | testbit
204 | unparsable
205 | sk
206 | RoutingInfo
207 | funder
208 | Counterintuitively
209 | decrypts
210 | sn
211 | generateFiller
212 | unrevoked
213 | ss
214 | that'd
215 | ack
216 | deobfuscated
217 | gflen
218 | satoshis
219 | instantiation
220 | HeaderMAC
221 | blindGroupElement
222 | tx
223 | pubkeys
224 | CHECKLOCKTIMEVERIFY
225 | CLTV
226 | CLTVs
227 | generateCipherStream
228 | XK
229 | lflen
230 | deobfuscates
231 | generateKey
232 | alice
233 | revocationprivkey
234 | PKH
235 | remotepubkey
236 | HKDF
237 | ooo
238 | repo
239 | num
240 | numStreamBytes
241 | txout
242 | HTLCs
243 | HTLC's
244 | retransmission
245 | decrypted
246 | sessionKey
247 | sessionkey
248 | routingInfoSize
249 | hostname
250 | rgb
251 | ciphertexts
252 | wscript
253 | CHECKSIG
254 | pre
255 | numMaxHops
256 | HMACs
257 | hmac
258 | BIP
259 | hmacSize
260 | ratelimit
261 | talkin
262 | revocationpubkey
263 | msat
264 | func
265 | unencrypted
266 | coinbase
267 | priv
268 | sha
269 | TODO
270 | ChaChaPoly
271 | delayedpubkey
272 | Diffie
273 | IETF
274 | xFFFFFFFFFFF
275 | FIXME
276 | EphemeralKey
277 | bitcoin
278 | Bitcoin
279 | smartphone
280 | other's
281 | remote's
282 | multi
283 | bitcoin's
284 | IP
285 | aa
286 | df
287 | versa
288 | timestamp
289 | metadata
290 | Bitcoin's
291 | Versioning
292 | checksum
293 | expiries
294 | bech
295 | Bech
296 | nano
297 | pico
298 | mainnet
299 | testnet
300 | icecream
301 | extractable
302 | de
303 | anonymize
304 | Punycode
305 | rck
306 | sck
307 | zeroconf
308 | swiss
309 | lollypop
310 | UTC
311 | inline
312 | fundee's
313 | BOLTs
314 | DNS
315 | subdomain
316 | subdomains
317 | wildcard
318 | tuple
319 | tuples
320 | resolvers
321 | hostnames
322 | prepending
323 | A
324 | AAAA
325 | SRV
326 | TTL
327 | URI
328 | cli
329 | paymentkey
330 | htlcpubkey
331 | remotehtlcsig
332 | localhtlcsig
333 | basepoints
334 | Bitcoins
335 | bitcoins
336 | deobfuscate
337 | offerer
338 | offerer's
339 | incentivize
340 | redemptions
341 | vbytes
342 | BTC
343 | USD
344 | XSS
345 | SQL
346 | DOM
347 | Javascript
348 | javascript
349 | Implementers
350 | sanitization
351 | ek
352 | reblind
353 | ephemeralKey
354 | ephemeralPrivKey
355 | ephemeralPubKey
356 | ecdhResult
357 | scalarMult
358 | blindingFactor
359 | Mul
360 | unlinkable
361 | regtest
362 | ratelimiting
363 | zlib
364 | ZLIB
365 | APIs
366 | duplicative
367 | CRC
368 | DoS
369 | ECDSA
370 | TLV
371 | tlv
372 | namespace
373 | verifier
374 | verifiers
375 | EOF
376 | monotonicity
377 | optimizations
378 | structs
379 | CompactSize
380 | encodings
381 | remotekey
382 | bigsize
383 | BigSize
384 | namespaces
385 | tlvs
386 | fips
387 | rfc
388 | multipath
389 | mpp
390 | tlvs
391 | snprintf
392 | GitHub
393 | IRC
394 | bitmasks
395 | CSPRNG
396 | lexicographically
397 | MINIMALIF
398 | SIGHASH
399 | sighash
400 | ANYONECANPAY
401 | cpfp
402 | utxo
403 | txes
404 | csv
405 | CHECKSIGVERIFY
406 | IFDUP
407 | sats
408 | anysegwit
409 | quiesce
410 | quiescing
411 | SomeThing
412 | onionmsg
413 | unrequested
414 | Merkle
415 | whitespace
416 | TLVs
417 | LnLeaf
418 | LnNonce
419 | LnBranch
420 | payinfo
421 | griefing
422 | unspendable
423 | pkh
424 | kB
425 | unblind
426 | unblinded
427 | workflow
428 | PUSHDATA
429 | prev
430 | vout
431 | rbf
432 | standardness
433 | perkw
434 | prevtx
435 | ints
436 | replaceability
437 | disincentivize
438 | UTXOs
439 |
--------------------------------------------------------------------------------
/.copy-edit-stylesheet-checklist.md:
--------------------------------------------------------------------------------
1 | # Basic checklist/stylesheet used for copy editing BOLTs
2 |
3 | Contributions should comply with this checklist/stylesheet to maintain correct, clear, consistent, and concise BOLTS.
4 |
5 | - spelling
6 | - run `tools/spellcheck.sh --check [0-9][0-9]-*.md`
7 | - update `.aspell.en.pws` with any missing words
8 | - typos
9 | - sentence structure
10 | - sentence fragments
11 | - run-on sentences
12 | - dangling, misplaced modifiers
13 | - consistent paragraph tense (e.g. past, present, future)
14 | - passive voice (e.g. avoid 'we')
15 | - use 'local/remote' terminology rather than 'us/them' or 'we/they'
16 | - exception: `Introduction` section
17 | - capitalization
18 | - table of contents
19 | - headers
20 | - capitalize list items containing complete sentences
21 | - commonly forgotten: 'Lightning', 'ID'
22 | - distinguish between network and currency unit
23 | - e.g. "The Bitcoin network transfers bitcoins."
24 | - punctuation
25 | - correct comma, colon, semi-colon, em-dash placement
26 | - for conjoined items, use comma before conjunction
27 | - e.g. 'this, that, and the other'
28 | - appropriate use of parenthesis
29 | - only use periods after list items if they contain complete sentences
30 | - exceptions: `Requirements` lists
31 | - abbreviations
32 | - e.g., i.e., etc., a.k.a.
33 | - formatting
34 | - single spaces between sentences
35 | - consistent use of _emphasis_, **strong**, `code`, CAPS, 'quotes'
36 | - single line separators between paragraphs and page elements
37 | - ensure correct header weights
38 | - numbers and calculations
39 | - spell out small (<10) amounts
40 | - type digits and enumerations
41 | - e.g. 'two 2-byte blocks set to 0s', 'one 4-byte block set to 1s', 'the other one is equal to 1'
42 | - exceptions, e.g. 'non-zero', '1 byte in length'
43 | - data measurements
44 | - type digits for quantities of information, use hyphen when unit is an adjective
45 | - e.g. 'a 32-bit block is 32 bits in length'
46 | - for typed calculations
47 | - space both sides of operators (except '^' and negative numbers)
48 | - e.g. 5 - 3^2 * 4 = -31
49 | - for calculation descriptions
50 | - write out operators
51 | - e.g. 1 less than 3 equals 2
52 | - list structure
53 | - 2 spaces before item
54 | - indent 2 spaces
55 | - `Requirements` sections
56 | - colon after conditions
57 | - comma before sub-items
58 | - period at branch ends
59 | - example:
60 | ```
61 | A sending node:
62 | - MAY do this.
63 | - if this, AND this:
64 | - SHOULD do this.
65 | - otherwise:
66 | - MUST do this,
67 | - but MUST NOT...in this case.
68 | ```
69 | - links
70 | - broken links
71 | - link text
72 | - correct anchors/urls
73 | - references
74 | - format e.g. [1](#reference-1)
75 | - tags
76 | - consistent usage, e.g. [TODO:], [FIXME:]
77 |
--------------------------------------------------------------------------------
/.gitattributes:
--------------------------------------------------------------------------------
1 | *.md linguist-detectable
2 |
--------------------------------------------------------------------------------
/.travis.yml:
--------------------------------------------------------------------------------
1 | language: python
2 | addons:
3 | apt:
4 | packages:
5 | - aspell-en
6 |
7 | python:
8 | - "3.4"
9 | - "3.5"
10 | - "3.6"
11 | script:
12 | - (set -e; for i in 0?-*.md; do echo "Extracting $i"; python3 tools/extract-formats.py $i; done)
13 | - tools/spellcheck.sh --check *.md
14 |
--------------------------------------------------------------------------------
/00-introduction.md:
--------------------------------------------------------------------------------
1 | # BOLT #0: Introduction and Index
2 |
3 | Welcome, friend! These Basis of Lightning Technology (BOLT) documents
4 | describe a layer-2 protocol for off-chain bitcoin transfer by mutual
5 | cooperation, relying on on-chain transactions for enforcement if
6 | necessary.
7 |
8 | Some requirements are subtle; we have tried to highlight motivations
9 | and reasoning behind the results you see here. I'm sure we've fallen
10 | short; if you find any part confusing or wrong, please contact us and
11 | help us improve.
12 |
13 | This is version 0.
14 |
15 | 1. [BOLT #1](01-messaging.md): Base Protocol
16 | 2. [BOLT #2](02-peer-protocol.md): Peer Protocol for Channel Management
17 | 3. [BOLT #3](03-transactions.md): Bitcoin Transaction and Script Formats
18 | 4. [BOLT #4](04-onion-routing.md): Onion Routing Protocol
19 | 5. [BOLT #5](05-onchain.md): Recommendations for On-chain Transaction Handling
20 | 7. [BOLT #7](07-routing-gossip.md): P2P Node and Channel Discovery
21 | 8. [BOLT #8](08-transport.md): Encrypted and Authenticated Transport
22 | 9. [BOLT #9](09-features.md): Assigned Feature Flags
23 | 10. [BOLT #10](10-dns-bootstrap.md): DNS Bootstrap and Assisted Node Location
24 | 11. [BOLT #11](11-payment-encoding.md): Invoice Protocol for Lightning Payments
25 | 12. [BOLT #12](12-offer-encoding.md): Negotiation Protocol for Lightning Payments
26 |
27 | ## The Spark: A Short Introduction to Lightning
28 |
29 | Lightning is a protocol for making fast payments with Bitcoin using a
30 | network of channels.
31 |
32 | ### Channels
33 |
34 | Lightning works by establishing *channels*: two participants create a
35 | Lightning payment channel that contains some amount of bitcoin (e.g.,
36 | 0.1 bitcoin) that they've locked up on the Bitcoin network. It is
37 | spendable only with both their signatures.
38 |
39 | Initially they each hold a bitcoin transaction that sends all the
40 | bitcoin (e.g. 0.1 bitcoin) back to one party. They can later sign a new bitcoin
41 | transaction that splits these funds differently, e.g. 0.09 bitcoin to one
42 | party, 0.01 bitcoin to the other, and invalidate the previous bitcoin
43 | transaction so it won't be spent.
44 |
45 | See [BOLT #2: Channel Establishment](02-peer-protocol.md#channel-establishment) for more on
46 | channel establishment and [BOLT #3: Funding Transaction Output](03-transactions.md#funding-transaction-output) for the format of the bitcoin transaction that creates the channel. See [BOLT #5: Recommendations for On-chain Transaction Handling](05-onchain.md) for the requirements when participants disagree or fail, and the cross-signed bitcoin transaction must be spent.
47 |
48 | ### Conditional Payments
49 |
50 | A Lightning channel only allows payment between two participants, but channels can be connected together to form a network that allows payments between all members of the network. This requires the technology of a conditional payment, which can be added to a channel,
51 | e.g. "you get 0.01 bitcoin if you reveal the secret within 6 hours".
52 | Once the recipient presents the secret, that bitcoin transaction is
53 | replaced with one lacking the conditional payment and adding the funds
54 | to that recipient's output.
55 |
56 | See [BOLT #2: Adding an HTLC](02-peer-protocol.md#adding-an-htlc-update_add_htlc) for the commands a participant uses to add a conditional payment, and [BOLT #3: Commitment Transaction](03-transactions.md#commitment-transaction) for the
57 | complete format of the bitcoin transaction.
58 |
59 | ### Forwarding
60 |
61 | Such a conditional payment can be safely forwarded to another
62 | participant with a lower time limit, e.g. "you get 0.01 bitcoin if you reveal the secret
63 | within 5 hours". This allows channels to be chained into a network
64 | without trusting the intermediaries.
65 |
66 | See [BOLT #2: Forwarding HTLCs](02-peer-protocol.md#forwarding-htlcs) for details on forwarding payments, [BOLT #4: Packet Structure](04-onion-routing.md#packet-structure) for how payment instructions are transported.
67 |
68 | ### Network Topology
69 |
70 | To make a payment, a participant needs to know what channels it can
71 | send through. Participants tell each other about channel and node
72 | creation, and updates.
73 |
74 | See [BOLT #7: P2P Node and Channel Discovery](07-routing-gossip.md)
75 | for details on the communication protocol, and [BOLT #10: DNS
76 | Bootstrap and Assisted Node Location](10-dns-bootstrap.md) for initial
77 | network bootstrap.
78 |
79 | ### Payment Invoicing
80 |
81 | A participant receives invoices that tell them what payments to make.
82 |
83 | See [BOLT #11: Invoice Protocol for Lightning Payments](11-payment-encoding.md) for the protocol describing the destination and purpose of a payment such that the payer can later prove successful payment.
84 |
85 |
86 | ## Glossary and Terminology Guide
87 |
88 | * #### *Announcement*:
89 | * A gossip message sent between *[peers](#peers)* intended to aid the discovery of a *[channel](#channel)* or a *[node](#node)*.
90 |
91 | * #### `chain_hash`:
92 | * The uniquely identifying hash of the target blockchain (usually the genesis hash).
93 | This allows *[nodes](#node)* to create and reference *channels* on
94 | several blockchains. Nodes are to ignore any messages that reference a
95 | `chain_hash` that are unknown to them. Unlike `bitcoin-cli`, the hash is
96 | not reversed but is used directly.
97 |
98 | For the main chain Bitcoin blockchain, the `chain_hash` value MUST be
99 | (encoded in hex):
100 | `6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000`.
101 |
102 | * #### *Channel*:
103 | * A fast, off-chain method of mutual exchange between two *[peers](#peers)*.
104 | To transact funds, peers exchange signatures to create an updated *[commitment transaction](#commitment-transaction)*.
105 | * _See closure methods: [mutual close](#mutual-close), [revoked transaction close](#revoked-transaction-close), [unilateral close](#unilateral-close)_
106 | * _See related: [route](#route)_
107 |
108 | * #### *Closing transaction*:
109 | * A transaction generated as part of a *[mutual close](#mutual-close)*. A closing transaction is similar to a _commitment transaction_, but with no pending payments.
110 | * _See related: [commitment transaction](#commitment-transaction), [funding transaction](#funding-transaction), [penalty transaction](#penalty-transaction)_
111 |
112 | * #### *Commitment number*:
113 | * A 48-bit incrementing counter for each *[commitment transaction](#commitment-transaction)*; counters
114 | are independent for each *peer* in the *channel* and start at 0.
115 | * _See container: [commitment transaction](#commitment-transaction)_
116 | * _See related: [closing transaction](#closing-transaction), [funding transaction](#funding-transaction), [penalty transaction](#penalty-transaction)_
117 |
118 | * #### *Commitment revocation private key*:
119 | * Every *[commitment transaction](#commitment-transaction)* has a unique commitment revocation private-key
120 | value that allows the other *peer* to spend all outputs
121 | immediately: revealing this key is how old commitment
122 | transactions are revoked. To support revocation, each output of the
123 | commitment transaction refers to the commitment revocation public key.
124 | * _See container: [commitment transaction](#commitment-transaction)_
125 | * _See originator: [per-commitment secret](#per-commitment-secret)_
126 |
127 | * #### *Commitment transaction*:
128 | * A transaction that spends the *[funding transaction](#funding-transaction)*.
129 | Each *peer* holds the other peer's signature for this transaction, so that each
130 | always has a commitment transaction that it can spend. After a new
131 | commitment transaction is negotiated, the old one is *revoked*.
132 | * _See parts: [commitment number](#commitment-number), [commitment revocation private key](#commitment-revocation-private-key), [HTLC](#HTLC-Hashed-Time-Locked-Contract), [per-commitment secret](#per-commitment-secret), [outpoint](#outpoint)_
133 | * _See related: [closing transaction](#closing-transaction), [funding transaction](#funding-transaction), [penalty transaction](#penalty-transaction)_
134 | * _See types: [revoked commitment transaction](#revoked-commitment-transaction)_
135 |
136 | * #### *Fail the channel*:
137 | * This is a forced close of the channel. Very early on (before
138 | opening), this may not require any action but forgetting the
139 | existence of the channel. Usually it requires signing and
140 | broadcasting the latest commitment transaction, although during
141 | mutual close it can also be performed by signing and broadcasting a
142 | mutual close transaction. See [BOLT #5](05-onchain.md#failing-a-channel).
143 |
144 | * #### *Close the connection*:
145 | * This means closing communication with the peer (such as closing
146 | the TCP socket). It does not imply closing any channels with the
147 | peer, but does cause the discarding of uncommitted state for
148 | connections with channels: see [BOLT #2](02-peer-protocol.md#message-retransmission).
149 |
150 | * #### *Final node*:
151 | * The final recipient of a packet that is routing a payment from an *[origin node](#origin-node)* through some number of *[hops](#hop)*. It is also the final *[receiving peer](#receiving-peer)* in a chain.
152 | * _See category: [node](#node)_
153 | * _See related: [origin node](#origin-node), [processing node](#processing-node)_
154 |
155 | * #### *Funding transaction*:
156 | * An irreversible on-chain transaction that pays to both *[peers](#peers)* on a *[channel](#channel)*.
157 | It can only be spent by mutual consent.
158 | * _See related: [closing transaction](#closing-transaction), [commitment transaction](#commitment-transaction), [penalty transaction](#penalty-transaction)_
159 |
160 | * #### *Hop*:
161 | * A *[node](#node)*. Generally, an intermediate node lying between an *[origin node](#origin-node)* and a *[final node](#final-node)*.
162 | * _See category: [node](#node)_
163 |
164 | * #### *HTLC*: Hashed Time Locked Contract.
165 | * A conditional payment between two *[peers](#peers)*: the recipient can spend
166 | the payment by presenting its signature and a *payment preimage*,
167 | otherwise the payer can cancel the contract by spending it after
168 | a given time. These are implemented as outputs from the
169 | *[commitment transaction](#commitment-transaction)*.
170 | * _See container: [commitment transaction](#commitment-transaction)_
171 | * _See parts: [Payment hash](#Payment-hash), [Payment preimage](#Payment-preimage)_
172 |
173 | * #### *Invoice*: A request for funds on the Lightning Network, possibly
174 | including payment type, payment amount, expiry, and other
175 | information. This is how payments are made on the Lightning
176 | Network, rather than using Bitcoin-style addresses.
177 |
178 | * #### *It's ok to be odd*:
179 | * A rule applied to some numeric fields that indicates either optional or
180 | compulsory support for features. Even numbers indicate that both endpoints
181 | MUST support the feature in question, while odd numbers indicate
182 | that the feature MAY be disregarded by the other endpoint.
183 |
184 | * #### *MSAT*:
185 | * A millisatoshi, often used as a field name.
186 |
187 | * #### *Mutual close*:
188 | * A cooperative close of a *[channel](#channel)*, accomplished by broadcasting an unconditional
189 | spend of the *[funding transaction](#funding-transaction)* with an output to each *peer*
190 | (unless one output is too small, and thus is not included).
191 | * _See related: [revoked transaction close](#revoked-transaction-close), [unilateral close](#unilateral-close)_
192 |
193 | * #### *Node*:
194 | * A computer or other device that is part of the Lightning network.
195 | * _See related: [peers](#peers)_
196 | * _See types: [final node](#final-node), [hop](#hop), [origin node](#origin-node), [processing node](#processing-node), [receiving node](#receiving-node), [sending node](#sending-node)_
197 |
198 | * #### *Origin node*:
199 | * The *[node](#node)* that originates a packet that will route a payment through some number of [hops](#hop) to a *[final node](#final-node)*. It is also the first [sending peer](#sending-peer) in a chain.
200 | * _See category: [node](#node)_
201 | * _See related: [final node](#final-node), [processing node](#processing-node)_
202 |
203 | * #### *Outpoint*:
204 | * A transaction hash and output index that uniquely identify an unspent transaction output. Needed to compose a new transaction, as an input.
205 | * _See related: [funding transaction](#funding-transaction), [commitment transaction](#commitment-transaction)_
206 |
207 | * #### *Payment hash*:
208 | * The *[HTLC](#HTLC-Hashed-Time-Locked-Contract)* contains the payment hash, which is the hash of the
209 | *[payment preimage](#Payment-preimage)*.
210 | * _See container: [HTLC](#HTLC-Hashed-Time-Locked-Contract)_
211 | * _See originator: [Payment preimage](#Payment-preimage)_
212 |
213 | * #### *Payment preimage*:
214 | * Proof that payment has been received, held by
215 | the final recipient, who is the only person who knows this
216 | secret. The final recipient releases the preimage in order to
217 | release funds. The payment preimage is hashed as the *[payment hash](#Payment-hash)*
218 | in the *[HTLC](#HTLC-Hashed-Time-Locked-Contract)*.
219 | * _See container: [HTLC](#HTLC-Hashed-Time-Locked-Contract)_
220 | * _See derivation: [payment hash](#Payment-hash)_
221 |
222 | * #### *Peers*:
223 | * Two *[nodes](#node)* that are in communication with each other.
224 | * Two peers may gossip with each other prior to setting up a channel.
225 | * Two peers may establish a *[channel](#channel)* through which they transact.
226 | * _See related: [node](#node)_
227 |
228 | * #### *Penalty transaction*:
229 | * A transaction that spends all outputs of a *[revoked commitment
230 | transaction](#revoked-commitment-transaction)*, using the *commitment revocation private key*. A *[peer](#peers)* uses this
231 | if the other peer tries to "cheat" by broadcasting a *[revoked commitment
232 | transaction](#revoked-commitment-transaction)*.
233 | * _See related: [closing transaction](#closing-transaction), [commitment transaction](#commitment-transaction), [funding transaction](#funding-transaction)_
234 |
235 | * #### *Per-commitment secret*:
236 | * Every *[commitment transaction](#commitment-transaction)* derives its keys from a per-commitment secret,
237 | which is generated such that the series of per-commitment secrets
238 | for all previous commitments can be stored compactly.
239 | * _See container: [commitment transaction](#commitment-transaction)_
240 | * _See derivation: [commitment revocation private key](#commitment-revocation-private-key)_
241 |
242 | * #### *Processing node*:
243 | * A *[node](#node)* that is processing a packet that originated with an *[origin node](#origin-node)* and that is being sent toward a *[final node](#final-node)* in order to route a payment. It acts as a *[receiving peer](#receiving-peer)* to receive the message, then a [sending peer](#sending-peer) to send on the packet.
244 | * _See category: [node](#node)_
245 | * _See related: [final node](#final-node), [origin node](#origin-node)_
246 |
247 | * #### *Receiving node*:
248 | * A *[node](#node)* that is receiving a message.
249 | * _See category: [node](#node)_
250 | * _See related: [sending node](#sending-node)_
251 |
252 | * #### *Receiving peer*:
253 | * A *[node](#node)* that is receiving a message from a directly connected *peer*.
254 | * _See category: [peer](#Peers)_
255 | * _See related: [sending peer](#sending-peer)_
256 |
257 | * #### *Revoked commitment transaction*:
258 | * An old *[commitment transaction](#commitment-transaction)* that has been revoked because a new commitment transaction has been negotiated.
259 | * _See category: [commitment transaction](#commitment-transaction)_
260 |
261 | * #### *Revoked transaction close*:
262 | * An invalid close of a *[channel](#channel)*, accomplished by broadcasting a *revoked
263 | commitment transaction*. Since the other *peer* knows the
264 | *commitment revocation secret key*, it can create a *[penalty transaction](#penalty-transaction)*.
265 | * _See related: [mutual close](#mutual-close), [unilateral close](#unilateral-close)_
266 |
267 | * #### *Route*:
268 | * A path across the Lightning Network that enables a payment
269 | from an *origin node* to a *[final node](#final-node)* across one or more
270 | *[hops](#hop)*.
271 | * _See related: [channel](#channel)_
272 |
273 | * #### *Sending node*:
274 | * A *[node](#node)* that is sending a message.
275 | * _See category: [node](#node)_
276 | * _See related: [receiving node](#receiving-node)_
277 |
278 | * #### *Sending peer*:
279 | * A *[node](#node)* that is sending a message to a directly connected *peer*.
280 | * _See category: [peer](#Peers)_
281 | * _See related: [receiving peer](#receiving-peer)_.
282 |
283 | * #### *Unilateral close*:
284 | * An uncooperative close of a *[channel](#channel)*, accomplished by broadcasting a
285 | *[commitment transaction](#commitment-transaction)*. This transaction is larger (i.e. less
286 | efficient) than a *[closing transaction](#closing-transaction)*, and the *[peer](#peers)* whose
287 | commitment is broadcast cannot access its own outputs for some
288 | previously-negotiated duration.
289 | * _See related: [mutual close](#mutual-close), [revoked transaction close](#revoked-transaction-close)_
290 |
291 | ## Theme Song
292 |
293 | Why this network could be democratic...
294 | Numismatic...
295 | Cryptographic!
296 | Why it could be released Lightning!
297 | (Release Lightning!)
298 |
299 |
300 | We'll have some timelocked contracts with hashed pubkeys, oh yeah.
301 | (Keep talking, whoa keep talkin')
302 | We'll segregate the witness for trustless starts, oh yeah.
303 | (I'll get the money, I've got to get the money)
304 | With dynamic onion routes, they'll be shakin' in their boots;
305 | You know that's just the truth, we'll be scaling through the roof.
306 | Release Lightning!
307 | (Go, go, go, go; go, go, go, go, go, go)
308 |
309 |
310 | [Chorus:]
311 | Oh released Lightning, it's better than a debit card..
312 | (Release Lightning, go release Lightning!)
313 | With released Lightning, micropayments just ain't hard...
314 | (Release Lightning, go release Lightning!)
315 | Then kaboom: we'll hit the moon -- release Lightning!
316 | (Go, go, go, go; go, go, go, go, go, go)
317 |
318 |
319 | We'll have QR codes, and smartphone apps, oh yeah.
320 | (Ooo ooo ooo ooo ooo ooo ooo)
321 | P2P messaging, and passive incomes, oh yeah.
322 | (Ooo ooo ooo ooo ooo ooo ooo)
323 | Outsourced closure watch, gives me feelings in my crotch.
324 | You'll know it's not a brag when the repo gets a tag:
325 | Released Lightning.
326 |
327 |
328 | [Chorus]
329 | [Instrumental, ~1m10s]
330 | [Chorus]
331 | (Lightning! Lightning! Lightning! Lightning!
332 | Lightning! Lightning! Lightning! Lightning!)
333 |
334 |
335 | C'mon guys, let's get to work!
336 |
337 |
338 | -- Anthony Towns
339 |
340 | ## Authors
341 |
342 | [ FIXME: Insert Author List ]
343 |
344 | 
345 |
346 | This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
347 |
--------------------------------------------------------------------------------
/09-features.md:
--------------------------------------------------------------------------------
1 | # BOLT #9: Assigned Feature Flags
2 |
3 | This document tracks the assignment of `features` flags in the `init`
4 | message ([BOLT #1](01-messaging.md)), as well as `features` fields in
5 | the `channel_announcement` and `node_announcement` messages ([BOLT
6 | #7](07-routing-gossip.md)). The flags are tracked separately, since
7 | new flags will likely be added over time.
8 |
9 | Some features were introduced and became so widespread they are `ASSUMED` to be present by all nodes, and can be safely ignored (and the semantics are only defined in prior revisions of this spec).
10 |
11 | Flags are numbered from the least-significant bit, at bit 0 (i.e. 0x1,
12 | an _even_ bit). They are generally assigned in pairs so that features
13 | can be introduced as optional (_odd_ bits) and later upgraded to be compulsory
14 | (_even_ bits), which will be refused by outdated nodes:
15 | see [BOLT #1: The `init` Message](01-messaging.md#the-init-message).
16 |
17 | Some features don't make sense on a per-channels or per-node basis, so
18 | each feature defines how it is presented in those contexts. Some
19 | features may be required for opening a channel, but not a requirement
20 | for use of the channel, so the presentation of those features depends
21 | on the feature itself.
22 |
23 | The Context column decodes as follows:
24 |
25 | * `I`: presented in the `init` message.
26 | * `N`: presented in the `node_announcement` messages
27 | * `C`: presented in the `channel_announcement` message.
28 | * `C-`: presented in the `channel_announcement` message, but always odd (optional).
29 | * `C+`: presented in the `channel_announcement` message, but always even (required).
30 | * `9`: presented in [BOLT 11](11-payment-encoding.md) invoices.
31 | * `B`: presented in the `allowed_features` field of a blinded path.
32 |
33 | | Bits | Name | Description | Context | Dependencies | Link |
34 | |-------|-----------------------------------|-----------------------------------------------------------|----------|-----------------------------|-----------------------------------------------------------------------|
35 | | 0/1 | `option_data_loss_protect` | ASSUMED | | | |
36 | | 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | | [BOLT #2][bolt02-open] |
37 | | 6/7 | `gossip_queries` | Peer has useful gossip to share | | | |
38 | | 8/9 | `var_onion_optin` | ASSUMED | | | |
39 | | 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | | [BOLT #7][bolt07-query] |
40 | | 12/13 | `option_static_remotekey` | ASSUMED | | | |
41 | | 14/15 | `payment_secret` | ASSUMED | IN9 | | [Routing Onion Specification][bolt04] |
42 | | 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] |
43 | | 18/19 | `option_support_large_channel` | Can create large channels | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
44 | | 22/23 | `option_anchors` | Anchor commitment type with zero fee HTLC transactions | IN | | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] |
45 | | 24/25 | `option_route_blinding` | Node supports blinded paths | IN9 | | [BOLT #4][bolt04-route-blinding] |
46 | | 26/27 | `option_shutdown_anysegwit` | Future segwit versions allowed in `shutdown` | IN | | [BOLT #2][bolt02-shutdown] |
47 | | 28/29 | `option_dual_fund` | Use v2 of channel open, enables dual funding | IN | | [BOLT #2](02-peer-protocol.md) |
48 | | 34/35 | `option_quiesce` | Support for `stfu` message | IN | | [BOLT #2][bolt02-quiescence] |
49 | | 38/39 | `option_onion_messages` | Can forward onion messages | IN | | [BOLT #7](04-onion-routing.md#onion-messages) |
50 | | 42/43 | `option_provide_storage` | Can store other nodes' encrypted backup data | IN | | [BOLT #1](01-messaging.md#peer-storage) |
51 | | 44/45 | `option_channel_type` | Node supports the `channel_type` field in open/accept | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
52 | | 46/47 | `option_scid_alias` | Supply channel aliases for routing | IN | | [BOLT #2][bolt02-channel-ready] |
53 | | 48/49 | `option_payment_metadata` | Payment metadata in tlv record | 9 | | [BOLT #11](11-payment-encoding.md#tagged-fields) |
54 | | 50/51 | `option_zeroconf` | Understands zeroconf channel types | IN | `option_scid_alias` | [BOLT #2][bolt02-channel-ready] |
55 | | 60/61 | `option_simple_close` | Simplified closing negotiation | IN | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close] |
56 |
57 | ## Requirements
58 |
59 | The origin node:
60 | * If it supports a feature above, SHOULD set the corresponding odd
61 | bit in all feature fields indicated by the Context column unless
62 | indicated that it must set the even feature bit instead.
63 | * If it requires a feature above, MUST set the corresponding even
64 | feature bit in all feature fields indicated by the Context column,
65 | unless indicated that it must set the odd feature bit instead.
66 | * MUST NOT set feature bits it does not support.
67 | * MUST NOT set feature bits in fields not specified by the table above.
68 | * MUST NOT set both the optional and mandatory bits.
69 | * MUST set all transitive feature dependencies.
70 | * MUST support:
71 | * `var_onion_optin`
72 |
73 | The receiving node:
74 | * if both the optional and the mandatory feature bits in a pair are set,
75 | the feature should be treated as mandatory.
76 |
77 | The requirements for receiving specific bits are defined in the linked sections in the table above.
78 | The requirements for feature bits that are not defined
79 | above can be found in [BOLT #1: The `init` Message](01-messaging.md#the-init-message).
80 |
81 | ## Rationale
82 |
83 | Note that for feature flags which are available in both the `node_announcement`
84 | and [BOLT 11](11-payment-encoding.md) invoice contexts, the features as set in
85 | the [BOLT 11](11-payment-encoding.md) invoice should override those set in the
86 | `node_announcement`. This keeps things consistent with the unknown features
87 | behavior as specified in [BOLT 7](07-routing-gossip.md#the-node_announcement-message).
88 |
89 | The origin must set all transitive feature dependencies in order to create a
90 | well-formed feature vector. By validating all known dependencies up front, this
91 | simplifies logic gated on a single feature bit; the feature's dependencies are
92 | known to be set, and do not need to be validated at every feature gate.
93 |
94 | 
95 |
96 | This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
97 |
98 | [bolt02-retransmit]: 02-peer-protocol.md#message-retransmission
99 | [bolt02-open]: 02-peer-protocol.md#the-open_channel-message
100 | [bolt02-simple-close]: 02-peer-protocol.md#closing-negotiation-closing_complete-and-closing_sig
101 | [bolt03-htlc-tx]: 03-transactions.md#htlc-timeout-and-htlc-success-transactions
102 | [bolt02-shutdown]: 02-peer-protocol.md#closing-initiation-shutdown
103 | [bolt02-quiescence]: 02-peer-protocol.md#channel-quiescence
104 | [bolt02-channel-ready]: 02-peer-protocol.md#the-channel_ready-message
105 | [bolt04]: 04-onion-routing.md
106 | [bolt07-sync]: 07-routing-gossip.md#initial-sync
107 | [bolt07-query]: 07-routing-gossip.md#query-messages
108 | [bolt04-mpp]: 04-onion-routing.md#basic-multi-part-payments
109 | [bolt04-route-blinding]: 04-onion-routing.md#route-blinding
110 | [ml-sighash-single-harmful]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html
111 |
--------------------------------------------------------------------------------
/10-dns-bootstrap.md:
--------------------------------------------------------------------------------
1 | # BOLT #10: DNS Bootstrap and Assisted Node Location
2 |
3 | ## Overview
4 |
5 | This specification describes a node discovery mechanism based on the Domain Name System (DNS).
6 | Its purpose is twofold:
7 |
8 | - Bootstrap: providing the initial node discovery for nodes that have no known contacts in the network
9 | - Assisted Node Location: supporting nodes in discovery of the current network address of previously known peers
10 |
11 | A domain name server implementing this specification is referred to as a
12 | _DNS Seed_ and answers incoming DNS queries of type `A`, `AAAA`, or `SRV`, as
13 | specified in RFCs 1035[1](#ref-1), 3596[2](#ref-2), and
14 | 2782[3](#ref-3), respectively.
15 | The DNS server is authoritative for a subdomain, referred to as a
16 | _seed root domain_, and clients may query it for subdomains.
17 |
18 | The subdomains consist of a number of dot-separated _conditions_ that further narrow the desired results.
19 |
20 | ## Table of Contents
21 |
22 | * [DNS Seed Queries](#dns-seed-queries)
23 | * [Query Semantics](#query-semantics)
24 | * [Reply Construction](#reply-construction)
25 | * [Policies](#policies)
26 | * [Examples](#examples)
27 | * [References](#references)
28 | * [Authors](#authors)
29 |
30 | ## DNS Seed Queries
31 |
32 | A client MAY issue queries using the `A`, `AAAA`, or `SRV` query types,
33 | specifying conditions for the desired results the seed should return.
34 |
35 | Queries distinguish between _wildcard_ queries and _node_ queries, depending on
36 | whether the `l`-key is set or not.
37 |
38 | ### Query Semantics
39 |
40 | The conditions are key-value pairs: the key is a single-letter, while the
41 | remainder of the key-value pair is the value.
42 | The following key-value pairs MUST be supported by a DNS seed:
43 |
44 | - `r`: realm byte
45 | - used to specify what realm the returned nodes must support
46 | - default value: 0 (Bitcoin)
47 | - `a`: address types
48 | - a bitfield that uses the types from [BOLT #7](07-routing-gossip.md) as bit
49 | index
50 | - used to specify what address types should be returned for `SRV` queries
51 | - MAY only be used for `SRV` queries
52 | - default value: 6 (i.e. `2 || 4`, since bit 1 and bit 2 are set for IPv4 and
53 | IPv6, respectively)
54 | - `l`: `node_id`
55 | - a bech32-encoded `node_id` of a specific node
56 | - used to ask for a single node instead of a random selection
57 | - default value: null
58 | - `n`: number of desired reply records
59 | - default value: 25
60 |
61 | Conditions are passed in the DNS seed query as individual, dot-separated subdomain components.
62 |
63 | For example, a query for `r0.a2.n10.lseed.bitcoinstats.com` would imply: return
64 | 10 (`n10`) IPv4 (`a2`) records for nodes supporting Bitcoin (`r0`).
65 |
66 | ### Requirements
67 |
68 | The DNS seed:
69 | - MUST evaluate the conditions from the _seed root domain_ by
70 | 'going up-the-tree', i.e. evaluating right-to-left in a fully qualified domain
71 | name.
72 | - E.g. to evaluate the above case: first evaluate `n10`, then `a2`, and finally `r0`.
73 | - if a condition (key) is specified more than once:
74 | - MUST discard any earlier value for that condition AND use the new value
75 | instead.
76 | - E.g. for `n5.r0.a2.n10.lseed.bitcoinstats.com`, the result is:
77 | ~~`n10`~~, `a2`, `r0`, `n5`.
78 | - SHOULD return results that match all conditions.
79 | - if it does NOT implement filtering by a given condition:
80 | - MAY ignore the condition altogether (i.e. the seed filtering is best effort only).
81 | - for `A` and `AAAA` queries:
82 | - MUST return only nodes listening on the default port 9735, as defined in
83 | [BOLT #1](01-messaging.md).
84 | - for `SRV` queries:
85 | - MAY return nodes that are listening on non-default ports, since `SRV`
86 | records return a _(hostname,port)_-tuple.
87 | - upon receiving a _wildcard_ query:
88 | - MUST select a random subset of up to `n` IPv4 or IPv6 addresses of nodes
89 | that are listening for incoming connections.
90 | - upon receiving a _node_ query:
91 | - MUST select the record matching the `node_id`, if any, AND return all
92 | addresses associated with that node.
93 |
94 | Querying clients:
95 | - MUST NOT rely on any given condition being met by the results.
96 |
97 | ### Reply Construction
98 |
99 | The results are serialized in a reply with a query type matching the client's
100 | query type. For example, `A`, `AAAA`, and `SRV` queries respectively result in
101 | `A`, `AAAA`, and `SRV` replies. Additionally, replies may be augmented with
102 | additional records (e.g. to add `A` or `AAAA` records matching the returned
103 | `SRV` records).
104 |
105 | For `A` and `AAAA` queries, the reply contains the domain name and the IP
106 | address of the results.
107 |
108 | The domain name MUST match the domain in the query, in order not to be filtered
109 | by intermediate resolvers.
110 |
111 | For `SRV` queries, the reply consists of (_virtual hostnames_, port)-tuples.
112 | A virtual hostname is a subdomain of the seed root domain that uniquely
113 | identifies a node in the network.
114 | It is constructed by prepending the `node_id` condition to the seed root domain.
115 |
116 | The DNS seed:
117 | - MAY additionally return the corresponding `A` and `AAAA` records that
118 | indicate the IP address for the `SRV` entries in the additional section of the
119 | reply.
120 | - MAY omit these additional records upon detecting a repeated query.
121 | - Reason: due to the large size of the resulting reply, the reply may be
122 | dropped by intermediate resolvers.
123 | - if no entries match all the conditions:
124 | - MUST return an empty reply.
125 |
126 | ## Policies
127 |
128 | The DNS seed:
129 | - MUST NOT return replies with a TTL less than 60 seconds.
130 | - MAY filter nodes from its local views for various reasons, including faulty
131 | nodes, flaky nodes, or spam prevention.
132 | - MUST reply to random queries (i.e. queries to the seed root domain and to
133 | the `_nodes._tcp.` alias for `SRV` queries) with _random and unbiased_
134 | samples from the set of all known good nodes, in accordance with the Bitcoin DNS Seed policy[4](#ref-4).
135 |
136 | ## Examples
137 |
138 | Querying for `AAAA` records:
139 |
140 | $ dig lseed.bitcoinstats.com AAAA
141 | lseed.bitcoinstats.com. 60 IN AAAA 2a02:aa16:1105:4a80:1234:1234:37c1:9c9
142 |
143 | Querying for `SRV` records:
144 |
145 | $ dig lseed.bitcoinstats.com SRV
146 | lseed.bitcoinstats.com. 59 IN SRV 10 10 6331 ln1qwktpe6jxltmpphyl578eax6fcjc2m807qalr76a5gfmx7k9qqfjwy4mctz.lseed.bitcoinstats.com.
147 | lseed.bitcoinstats.com. 59 IN SRV 10 10 9735 ln1qv2w3tledmzczw227nnkqrrltvmydl8gu4w4d70g9td7avke6nmz2tdefqp.lseed.bitcoinstats.com.
148 | lseed.bitcoinstats.com. 59 IN SRV 10 10 9735 ln1qtynyymv99pqf0r9cuexvvqtxrlgejuecf8myfsa96vcpflgll5cqmr2xsu.lseed.bitcoinstats.com.
149 | lseed.bitcoinstats.com. 59 IN SRV 10 10 4280 ln1qdfvlysfpyh96apy3w3qdwlu8jjkdhnuxa689ka540tnde6gnx86cf7ga2d.lseed.bitcoinstats.com.
150 | lseed.bitcoinstats.com. 59 IN SRV 10 10 4281 ln1qwf789tlcpe4n34649xrqllxt97whsvfk5pm07ggqms3vrjwdj3cu6332zs.lseed.bitcoinstats.com.
151 |
152 | Querying for the `A` for the first virtual hostname from the previous example:
153 |
154 | $ dig ln1qwktpe6jxltmpphyl578eax6fcjc2m807qalr76a5gfmx7k9qqfjwy4mctz.lseed.bitcoinstats.com A
155 | ln1qwktpe6jxltmpphyl578eax6fcjc2m807qalr76a5gfmx7k9qqfjwy4mctz.lseed.bitcoinstats.com. 60 IN A 139.59.143.87
156 |
157 | Querying for only IPv4 nodes (`a2`) via seed filtering:
158 |
159 | $dig a2.lseed.bitcoinstats.com SRV
160 | a2.lseed.bitcoinstats.com. 59 IN SRV 10 10 9735 ln1q2jy22cg2nckgxttjf8txmamwe9rtw325v4m04ug2dm9sxlrh9cagrrpy86.lseed.bitcoinstats.com.
161 | a2.lseed.bitcoinstats.com. 59 IN SRV 10 10 9735 ln1qfrkq32xayuq63anmc2zp5vtd2jxafhdzzudmuws0hvxshtgd2zd7jsqv7f.lseed.bitcoinstats.com.
162 |
163 | Querying for only IPv6 nodes (`a4`) supporting Bitcoin (`r0`) via seed filtering:
164 |
165 | $dig r0.a4.lseed.bitcoinstats.com SRV
166 | r0.a4.lseed.bitcoinstats.com. 59 IN SRV 10 10 9735 ln1qwx3prnvmxuwsnaqhzwsrrpwy4pjf5m8fv4m8kcjkdvyrzymlcmj5dakwrx.lseed.bitcoinstats.com.
167 | r0.a4.lseed.bitcoinstats.com. 59 IN SRV 10 10 9735 ln1qwr7x7q2gvj7kwzzr7urqq9x7mq0lf9xn6svs8dn7q8gu5q4e852znqj3j7.lseed.bitcoinstats.com.
168 |
169 | ## References
170 | - [RFC 1035 - Domain Names](https://www.ietf.org/rfc/rfc1035.txt)
171 | - [RFC 3596 - DNS Extensions to Support IP Version 6](https://tools.ietf.org/html/rfc3596)
172 | - [RFC 2782 - A DNS RR for specifying the location of services (DNS SRV)](https://www.ietf.org/rfc/rfc2782.txt)
173 | - [Expectations for DNS Seed operators](https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md)
174 |
175 | ## Authors
176 |
177 | [ FIXME: Insert Author List ]
178 |
179 | 
180 |
181 | This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
182 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | # How to Modify the Specification
2 |
3 | Welcome! This document is a meta-discussion of how the specifications
4 | should be safely altered when you want to include some amazing new
5 | functionality.
6 |
7 | Please remember that we're all trying to Make Things Better. Respect,
8 | consideration, kindness and humor have made this process
9 | [fun](00-introduction.md#theme-song) and rewarding and we'd like to keep it
10 | that way. We're nice!
11 |
12 | ## Extension Design
13 |
14 | There are several extension mechanisms in the spec; you should seek to use
15 | them, or introduce new ones if necessary.
16 |
17 | ### Adding New Inter-Peer Messages
18 |
19 | Unknown odd inter-peer messages are ignored, aka "it's OK to be odd!"
20 | which makes more sense as you get to know me.
21 |
22 | If your message is an enhancement, and you don't need to know if the other
23 | side supports it, you should give it an odd number. If it would be broken
24 | if the other side doesn't support it (ie. Should Never Happen) give it an
25 | even number. Mistakes happen, and future versions of the software may well
26 | not be tested against ancient versions.
27 |
28 | If you want to experiment with new [message types](01-messaging.md#lightning-message-format) internally, I recommend
29 | using 32768 and above (use even, so it will break if these accidentally
30 | escape into the wild).
31 |
32 | ### Adding New Feature Bits
33 |
34 | [Feature bits](01-messaging.md#the-init-message) are how you know a message is legal to send (see above), and
35 | also they can be used to find appropriate peers.
36 |
37 | Feature bits are always assigned in pairs, even if it doesn't make sense
38 | for them to ever be compulsory. The feature bit is self-assigned in the
39 | title of the PR, to make it easier for others to self-assign. Until the PR
40 | is merged into the spec, experimental implementations should use the proposed
41 | feature bit +100; they can accept both feature bits once it is merged (if
42 | the protocol does not change!).
43 |
44 | Almost every spec change should have a feature bit associated; in the past
45 | we have grouped feature bits, then we couldn't disable a single feature
46 | when implementations turned out to be broken.
47 |
48 | Usually feature bits are odd when first deployed, then some become even
49 | when deployment is almost universal. This often allows legacy code to be
50 | removed, since you'll never talk to peers who can't deal with the feature.
51 |
52 | If you want to experiment with new feature bits internally, I recommend
53 | using 100 and above.
54 |
55 | ### Extending Inter-Peer Messages
56 |
57 | The spec says that additional data in messages is ignored, which is another
58 | way we can extend in future. For BOLT 1.0, optional fields were appended,
59 | and their presence flagged by feature bits.
60 |
61 | The modern way to do this is to add a TLV to the end of a message. This
62 | contains optional fields: again, even means you will only send it if a
63 | feature bit indicates support, odd means it's OK to send to old peers
64 | (often making implementation easier, since peers can send them
65 | unconditionally).
66 |
67 | ## Writing The Spec
68 |
69 | The specification is supposed to be readable in text form, readable once
70 | converted to HTML, and digestible by [tools/extract-formats.py]. In
71 | particular, fields should use the correct type and have as much of their
72 | structure as possible described explicitly (avoid 100*byte fields).
73 |
74 | If necessary, you can modify that tool if you need strange formatting
75 | changes.
76 |
77 | The output of this tool is used to generate code for several
78 | implementations, and it's also recommended that implementations quote the
79 | spec liberally and have automated testing that the quotes are correct, as
80 | [c-lightning
81 | does](https://github.com/ElementsProject/lightning/blob/master/tools/check-bolt.c).
82 |
83 | If your New Thing replaces the existing one, be sure to move the existing
84 | one to a Legacy subsection: new readers will want to go straight to the
85 | modern version. Don't emulate the classic Linux snprintf 1.27 man page:
86 |
87 | RETURN VALUE
88 | If the output was truncated, the return value is -1, otherwise it is the
89 | number of characters stored, not including the terminating null. (Thus
90 | until glibc 2.0.6. Since glibc 2.1 these functions return the number
91 | of characters (excluding the trailing null) which would have been writ‐
92 | ten to the final string if enough space had been available.)
93 |
94 | Imagine the bitterness of someone who only reads the first sentence
95 | assuming they have the answer they're looking for! Someone who still
96 | remembers it with bitterness 20 years on and digs it out of prehistory
97 | to use it as an example of how not to write. Yep, that'd be sad.
98 |
99 | There's a [detailed style guide](.copy-edit-stylesheet-checklist.md) if you
100 | want to know how to format things, and we run a spellchecker in our [CI
101 | system](.travis.yml) as well so you may need to add lines to
102 | [.aspell.en.pws].
103 |
104 | ### Writing The Requirements
105 |
106 | Some requirements are obvious, some are subtle. They're designed to walk
107 | an implementer through the code they have to write, so write them as YOU
108 | develop YOUR implementation. Stick with `MUST`/`SHOULD`/`MAY` and `NOT`:
109 | see [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)
110 |
111 | Requirements are grouped into writer and reader, just as implementations
112 | are. Make sure you define exactly what a writer must do, and exactly what
113 | a reader must do if the writer doesn't do that! A developer should
114 | never have to intuit reader requirements from writer ones.
115 |
116 | Note that the data doesn't have requirements: don't say `foo MUST be 0`,
117 | say `The writer MUST set foo to 0` and `The reader MUST fail the connection
118 | if foo is not 0`.
119 |
120 | Avoid the term `MUST check`: use `MUST fail the connection if` or `MUST
121 | fail the channel if` or `MUST send an error message if`.
122 |
123 | There's a subtle art here for future extensions: you might say `a writer
124 | MUST set foo to 0` and not mention it in the reader requirements, but it's
125 | better to say `a reader MUST ignore foo`. A future version of the spec
126 | might define when a writer sets `foo` to `1` and we know that old readers
127 | will ignore it.
128 |
129 | `MAY` is a hint as to what something is for: an implementation may do
130 | anything not written in the spec anyway. `MUST` is when not doing
131 | something will break the protocol or security.
132 |
133 | Requirements can be vague (eg. "in a timely manner"), but only as a last
134 | resort admission of defeat. If you don't know, what hope has the poor
135 | implementer?
136 |
137 | ### Creating Test Vectors
138 |
139 | For new low-level protocol constructions, test vectors are necessary.
140 | These have traditionally been lines within the spec itself, but the modern
141 | trend is to use JSON and separate files. The intent is that they be
142 | machine-readable by implementations.
143 |
144 | For new inter-peer messages, a test framework is in development to simulate
145 | entire conversations.
146 |
147 | ## Specification Modification Process
148 |
149 | There is a [mailing
150 | list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev)
151 | for larger feature discussion, a [GitHub
152 | repository](https://github.com/lightningnetwork/lightning-rfc) for
153 | explicit issues and pull requests, and a bi-weekly IRC meeting on
154 | #lightning-dev on Freenode, currently held at 5:30am Tuesday,
155 | Adelaide/Australia timezone (eg. Tuesday 23rd July 2019 05:30 == Mon, 22
156 | Jul 2019 20:00 UTC).
157 |
158 | Spelling, typo and formatting changes are accepted once two contributors
159 | ack and there are no nacks. All other changes get approved and minuted at
160 | the IRC meeting. Protocol changes require two independent implementations
161 | which successfully inter-operate; be patient as spec changes are hard to
162 | fix later, so agreement can take some time.
163 |
164 | In addition, there are occasional face-to-face invitation-only Summits
165 | where broad direction is established. These are amazing, and you should
166 | definitely join us sometime.
167 |
168 | We look forward to you joining us!
169 | Your Friendly Lightning Developers.
170 |
--------------------------------------------------------------------------------
/CoC.md:
--------------------------------------------------------------------------------
1 | # Code of Conduct
2 |
3 | The lightning spec community is open to pretty much anyone. To ensure that project forums are open and friendly, we count on maintainers and project representatives to behave in a way that is not disruptive to any one participant's well-being.
4 |
5 | Therefore, we came up with some easy to follow guidelines.
6 | * Be friendly. Interact in a way that fosters openness, inclusivity, and collaboration.
7 | * Be respectful. We may disagree, but disagreement is no excuse for rude behavior or personal attacks.
8 | * Be considerate. Provide and accept constructive criticism.
9 |
10 | Private or public harassment of any kind will not be tolerated. Since harassment can take many forms, here's a non-exhaustive list of what we consider unacceptable behavior:
11 | * Offensive language directed at individuals or groups of people
12 | * Bullying (verbal, physical, social, or cyber)
13 | * Interfering with someone's ability to contribute, like with excessive nitpicking
14 | * Continued one-on-one communication after a party has requested it cease
15 | * Stalking online or offline
16 | * Doxing or unauthorized publication of private information or communication
17 | * Unwelcomed sexual attention
18 | * Inappropriate visual displays such as sexually-oriented or offensive photography, cartoons, drawings, or gestures
19 | * Retaliation for reporting or threatening to report harassment
20 |
21 | Additionally, spam and other content which disrupts or prevents contributors from working is not acceptable.
22 |
23 | ## The Code of Conduct Team
24 |
25 | A small team of contributors has volunteered to enforce this Code of Conduct. If you feel like a community member has engaged in inappropriate behavior, please don't hesitate to contact one of the following contributors via email:
26 | * Vincenzo Palazzo - vincenzopalazzo on member.fsf.org
27 | * Rusty Russell - rusty on rustcorp.com.au
28 |
29 | ## The Code of Conduct Team’s Responsibilities
30 |
31 | Team members are tasked with acknowledging reports within 24 hours. They will review each incident and determine, to the best of their ability:
32 | * Does the event constitute a Code of Conduct violation?
33 | * Is the behavior on our list of inappropriate behavior? Is it borderline inappropriate?
34 | * Did the event occur in a space within our Code of Conduct's scope?
35 | * If the incident occurred outside community forums and the individual is seen as a project representative or identifies as a contributor, the incident may be in scope.
36 | * Additionally, an incident may be in scope if a community member's ability to contribute to the lightning spec is impacted.
37 | * Did this incident occur in a private conversation or in a public space?
38 | * Is the situation isolated or ongoing?
39 | * How is the reported person's behavior negatively impacting others?
40 | * Does the incident impact the ability of individuals to freely contribute to the lightning spec?
41 | * Does this incident include sexual harassment?
42 | * Does this pose a safety risk or severely negatively impact someone's mental health?
43 | * Is there a risk of this behavior being repeated?
44 | * Does the reported person understand why their behavior was inappropriate?
45 |
46 | If a report is insufficiently detailed or involves multiple parties, the Code of Conduct Team may seek additional information from witnesses or the accused. Neither party should contact the other to discuss the incident. Likewise, the team will do its best not to disclose who reported a given incident, either to the accused or generally, though we recognize that circumstantial disclosures to the accused might be unavoidable.
47 |
48 | The Code of Conduct Team aims to resolve all reports within one week. If a resolution is not possible within that time frame, the team will respond to the reporter(s) with an adjusted one.
49 |
50 | ## Possible responses to an incident include:
51 |
52 | ### Taking no further action:
53 | If the Code of Conduct Team determines that no action is needed, they will inform the reporter.
54 |
55 | ### Simple warning:
56 | This applies to disruptive behavior, but not insulting behavior. The Code of Conduct Team will contact the individual(s) and request that they stop.
57 |
58 | ### Final warning:
59 | If an incident or series of incidents creates sustained toxicity within the lightning spec community, the Code of Conduct Team will sternly warn the reported party and raise the possibility of further disciplinary action. In addition, they may request that the reported party:
60 | * Not use specific language
61 | * Not participate in specific types of discussions
62 | * Not send private messages to a community member
63 | * Not review a particular person's PRs on GitHub (but still allow them to privately share review comments with a maintainer)
64 | * Not lead sub-projects like code review sessions
65 | * Take a step away for a short period to cool off
66 | * Lose maintainer/merge access
67 |
68 | ### 2-3 months imposed break:
69 | If the Code of Conduct Team’s warning goes unheeded, the individual(s) may be asked to avoid participating with the lightning spec community on its preferred platforms for several months. After time has passed, the individual(s) will have the option of meeting with the team to discuss returning to the community.
70 |
71 | ### Extended or permanent ban:
72 | If a temporary break does not remedy a serious offense, the offender may be removed or banned from the Github repository. The Code of Conduct Team may also choose to un-ban a user for a first offense, depending on its severity and pending that the user has offered the offended party a genuine apology.
73 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Lightning Network In-Progress Specifications
2 |
3 | The specifications are currently a work-in-progress and currently being
4 | drafted.
5 |
6 | Pull requests and comments welcome, seeking input from community stakeholders.
7 |
8 | Discussion available on [delving bitcoin](https://delvingbitcoin.org/tag/lightning).
9 |
10 | Previous discussions used the `lightning-dev` mailing list: an archive can be found [here](https://www.mail-archive.com/lightning-dev@lists.linuxfoundation.org/).
11 |
12 | ### [Start here for Table of Contents](00-introduction.md)
13 |
14 | 
15 |
16 | This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
17 |
--------------------------------------------------------------------------------
/bolt04/blinded-onion-message-onion-test.json:
--------------------------------------------------------------------------------
1 | {
2 | "comment": "Test vector creating an onionmessage, including joining an existing one",
3 | "generate": {
4 | "comment": "This sections contains test data for Dave's blinded path Bob->Dave; sender has to prepend a hop to Alice to reach Bob",
5 | "session_key": "0303030303030303030303030303030303030303030303030303030303030303",
6 | "hops": [
7 | {
8 | "alias": "Alice",
9 | "comment": "Alice->Bob: note next_path_key_override to match that give by Dave for Bob",
10 | "path_key_secret": "6363636363636363636363636363636363636363636363636363636363636363",
11 | "tlvs": {
12 | "next_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c",
13 | "next_path_key_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
14 | "path_key_override_secret": "0101010101010101010101010101010101010101010101010101010101010101"
15 | },
16 | "encrypted_data_tlv": "04210324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c0821031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
17 | "ss": "c04d2a4c518241cb49f2800eea92554cb543f268b4c73f85693541e86d649205",
18 | "HMAC256('blinded_node_id', ss)": "bc5388417c8db33af18ab7ba43f6a5641861f7b0ecb380e501a739af446a7bf4",
19 | "blinded_node_id": "02d1c3d73f8cac67e7c5b6ec517282d5ba0a52b06a29ec92ff01e12decf76003c1",
20 | "E": "031195a8046dcbb8e17034bca630065e7a0982e4e36f6f7e5a8d4554e4846fcd99",
21 | "H(E || ss)": "83377bd6096f82df3a46afec20d68f3f506168f2007f6e86c2dc267417de9e34",
22 | "next_e": "bf3e8999518c0bb6e876abb0ae01d44b9ba211720048099a2ba5a83afd730cad01",
23 | "rho": "6926df9d4522b26ad4330a51e3481208e4816edd9ae4feaf311ea0342eb90c44",
24 | "encrypted_recipient_data": "49531cf38d3280b7f4af6d6461a2b32e3df50acfd35176fc61422a1096eed4dfc3806f29bf74320f712a61c766e7f7caac0c42f86040125fbaeec0c7613202b206dbdd31fda56394367b66a711bfd7d5bedbe20bed1b"
25 | },
26 | {
27 | "alias": "Bob",
28 | "comment": "Bob->Carol",
29 | "path_key_secret": "0101010101010101010101010101010101010101010101010101010101010101",
30 | "tlvs": {
31 | "next_node_id": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007",
32 | "unknown_tag_561": "123456"
33 | },
34 | "encrypted_data_tlv": "0421027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007fd023103123456",
35 | "ss": "196f1f3e0be9d65f88463c1ab63e07f41b4e7c0368c28c3e6aa290cc0d22eaed",
36 | "HMAC256('blinded_node_id', ss)": "c331d35827bdd509a02f1e64d48c7f0d7b2603355abbb1a3733c86e50135608e",
37 | "blinded_node_id": "03f1465ca5cf3ec83f16f9343d02e6c24b76993a93e1dea2398f3147a9be893d7a",
38 | "E": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
39 | "H(E || ss)": "1889a6cf337d9b34f80bb23a91a2ca194e80d7614f0728bdbda153da85e46b69",
40 | "next_e": "f7ab6dca6152f7b6b0c9d7c82d716af063d72d8eef8816dfc51a8ae828fa7dce01",
41 | "rho": "db991242ce366ab44272f38383476669b713513818397a00d4808d41ea979827",
42 | "encrypted_recipient_data": "adf6771d3983b7f543d1b3d7a12b440b2bd3e1b3b8d6ec1023f6dec4f0e7548a6f57f6dbe9573b0a0f24f7c5773a7dd7a7bdb6bd0ee686d759f5"
43 | },
44 | {
45 | "alias": "Carol",
46 | "comment": "Carol->Dave",
47 | "path_key_secret": "f7ab6dca6152f7b6b0c9d7c82d716af063d72d8eef8816dfc51a8ae828fa7dce",
48 | "tlvs": {
49 | "padding": "0000000000",
50 | "next_node_id": "032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991"
51 | },
52 | "encrypted_data_tlv": "010500000000000421032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991",
53 | "ss": "c7b33d74a723e26331a91c15ae5bc77db28a18b801b6bc5cd5bba98418303a9d",
54 | "HMAC256('blinded_node_id', ss)": "a684c7495444a8cc2a6dfdecdf0819f3cdf4e86b81cc14e39825a40872ecefff",
55 | "blinded_node_id": "035dbc0493aa4e7eea369d6a06e8013fd03e66a5eea91c455ed65950c4942b624b",
56 | "E": "02b684babfd400c8dd48b367e9754b8021a3594a34dc94d7101776c7f6a86d0582",
57 | "H(E || ss)": "2d80c5619a5a68d22dd3d784cab584c2718874922735d36cb36a179c10a796ca",
58 | "next_e": "5de52bb427cc148bf23e509fdc18012004202517e80abcfde21612ae408e6cea01",
59 | "rho": "739851e89b61cab34ee9ba7d5f3c342e4adc8b91a72991664026f68a685f0bdc",
60 | "encrypted_recipient_data": "d8903df7a79ac799a0b59f4ba22f6a599fa32e7ff1a8325fc22b88d278ce3e4840af02adfb82d6145a189ba50c2219c9e4351e634d198e0849ac"
61 | },
62 | {
63 | "alias": "Dave",
64 | "comment": "Dave is final node, hence path_id",
65 | "path_key_secret": "5de52bb427cc148bf23e509fdc18012004202517e80abcfde21612ae408e6cea",
66 | "tlvs": {
67 | "padding": "",
68 | "path_id": "deadbeefbadc0ffeedeadbeefbadc0ffeedeadbeefbadc0ffeedeadbeefbadc0",
69 | "unknown_tag_65535": "06c1"
70 | },
71 | "encrypted_data_tlv": "01000620deadbeefbadc0ffeedeadbeefbadc0ffeedeadbeefbadc0ffeedeadbeefbadc0fdffff0206c1",
72 | "ss": "024955ed0d4ebbfab13498f5d7aacd00bf096c8d9ed0473cdfc96d90053c86b7",
73 | "HMAC256('blinded_node_id', ss)": "3f5612df60f050ac571aeaaf76655e138529bea6d23293ebe15659f2588cd039",
74 | "blinded_node_id": "0237bf019fa0fbecde8b4a1c7b197c9c1c76f9a23d67dd55bb5e42e1f50bb771a6",
75 | "E": "025aaca62db7ce6b46386206ef9930daa32e979a35cb185a41cb951aa7d254b03c",
76 | "H(E || ss)": "db5719e79919d706eab17eebaad64bd691e56476a42f0e26ae60caa9082f56fa",
77 | "next_e": "ae31d2fbbf2f59038542c13287b9b624ea1a212c82be87c137c3d92aa30a185d01",
78 | "rho": "c47cde57edc790df7b9b6bf921aff5e5eee43f738ab8fa9103ef675495f3f50e",
79 | "encrypted_recipient_data": "bdc03f088764c6224c8f939e321bf096f363b2092db381fc8787f891c8e6dc9284991b98d2a63d9f91fe563065366dd406cd8e112cdaaa80d0e6"
80 | }
81 | ]
82 | },
83 | "route": {
84 | "comment": "The resulting blinded route Alice to Dave.",
85 | "first_node_id": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619",
86 | "first_path_key": "031195a8046dcbb8e17034bca630065e7a0982e4e36f6f7e5a8d4554e4846fcd99",
87 | "hops": [
88 | {
89 | "blinded_node_id": "02d1c3d73f8cac67e7c5b6ec517282d5ba0a52b06a29ec92ff01e12decf76003c1",
90 | "encrypted_recipient_data": "49531cf38d3280b7f4af6d6461a2b32e3df50acfd35176fc61422a1096eed4dfc3806f29bf74320f712a61c766e7f7caac0c42f86040125fbaeec0c7613202b206dbdd31fda56394367b66a711bfd7d5bedbe20bed1b"
91 | },
92 | {
93 | "blinded_node_id": "03f1465ca5cf3ec83f16f9343d02e6c24b76993a93e1dea2398f3147a9be893d7a",
94 | "encrypted_recipient_data": "adf6771d3983b7f543d1b3d7a12b440b2bd3e1b3b8d6ec1023f6dec4f0e7548a6f57f6dbe9573b0a0f24f7c5773a7dd7a7bdb6bd0ee686d759f5"
95 | },
96 | {
97 | "blinded_node_id": "035dbc0493aa4e7eea369d6a06e8013fd03e66a5eea91c455ed65950c4942b624b",
98 | "encrypted_recipient_data": "d8903df7a79ac799a0b59f4ba22f6a599fa32e7ff1a8325fc22b88d278ce3e4840af02adfb82d6145a189ba50c2219c9e4351e634d198e0849ac"
99 | },
100 | {
101 | "blinded_node_id": "0237bf019fa0fbecde8b4a1c7b197c9c1c76f9a23d67dd55bb5e42e1f50bb771a6",
102 | "encrypted_recipient_data": "bdc03f088764c6224c8f939e321bf096f363b2092db381fc8787f891c8e6dc9284991b98d2a63d9f91fe563065366dd406cd8e112cdaaa80d0e6"
103 | }
104 | ]
105 | },
106 | "onionmessage": {
107 | "comment": "An onion message which sends a 'hello' to Dave",
108 | "unknown_tag_1": "68656c6c6f",
109 | "onion_message_packet": "0002531fe6068134503d2723133227c867ac8fa6c83c537e9a44c3c5bdbdcb1fe33793b828776d70aabbd8cef1a5b52d5a397ae1a20f20435ff6057cd8be339d5aee226660ef73b64afa45dbf2e6e8e26eb96a259b2db5aeecda1ce2e768bbc35d389d7f320ca3d2bd14e2689bef2f5ac0307eaaabc1924eb972c1563d4646ae131accd39da766257ed35ea36e4222527d1db4fa7b2000aab9eafcceed45e28b5560312d4e2299bd8d1e7fe27d10925966c28d497aec400b4630485e82efbabc00550996bdad5d6a9a8c75952f126d14ad2cff91e16198691a7ef2937de83209285f1fb90944b4e46bca7c856a9ce3da10cdf2a7d00dc2bf4f114bc4d3ed67b91cbde558ce9af86dc81fbdc37f8e301b29e23c1466659c62bdbf8cff5d4c20f0fb0851ec72f5e9385dd40fdd2e3ed67ca4517117825665e50a3e26f73c66998daf18e418e8aef9ce2d20da33c3629db2933640e03e7b44c2edf49e9b482db7b475cfd4c617ae1d46d5c24d697846f9f08561eac2b065f9b382501f6eabf07343ed6c602f61eab99cdb52adf63fd44a8db2d3016387ea708fc1c08591e19b4d9984ebe31edbd684c2ea86526dd8c7732b1d8d9117511dc1b643976d356258fce8313b1cb92682f41ab72dedd766f06de375f9edacbcd0ca8c99b865ea2b7952318ea1fd20775a28028b5cf59dece5de14f615b8df254eee63493a5111ea987224bea006d8f1b60d565eef06ac0da194dba2a6d02e79b2f2f34e9ca6e1984a507319d86e9d4fcaeea41b4b9144e0b1826304d4cc1da61cfc5f8b9850697df8adc5e9d6f3acb3219b02764b4909f2b2b22e799fd66c383414a84a7d791b899d4aa663770009eb122f90282c8cb9cda16aba6897edcf9b32951d0080c0f52be3ca011fbec3fb16423deb47744645c3b05fdbd932edf54ba6efd26e65340a8e9b1d1216582e1b30d64524f8ca2d6c5ba63a38f7120a3ed71bed8960bcac2feee2dd41c90be48e3c11ec518eb3d872779e4765a6cc28c6b0fa71ab57ced73ae963cc630edae4258cba2bf25821a6ae049fec2fca28b5dd1bb004d92924b65701b06dcf37f0ccd147a13a03f9bc0f98b7d78fe9058089756931e2cd0e0ed92ec6759d07b248069526c67e9e6ce095118fd3501ba0f858ef030b76c6f6beb11a09317b5ad25343f4b31aef02bc555951bc7791c2c289ecf94d5544dcd6ad3021ed8e8e3db34b2a73e1eedb57b578b068a5401836d6e382110b73690a94328c404af25e85a8d6b808893d1b71af6a31fadd8a8cc6e31ecc0d9ff7e6b91fd03c274a5c1f1ccd25b61150220a3fddb04c91012f5f7a83a5c90deb2470089d6e38cd5914b9c946eca6e9d31bbf8667d36cf87effc3f3ff283c21dd4137bd569fe7cf758feac94053e4baf7338bb592c8b7c291667fadf4a9bf9a2a154a18f612cbc7f851b3f8f2070e0a9d180622ee4f8e81b0ab250d504cef24116a3ff188cc829fcd8610b56343569e8dc997629410d1967ca9dd1d27eec5e01e4375aad16c46faba268524b154850d0d6fe3a76af2c6aa3e97647c51036049ac565370028d6a439a2672b6face56e1b171496c0722cfa22d9da631be359661617c5d5a2d286c5e19db9452c1e21a0107b6400debda2decb0c838f342dd017cdb2dccdf1fe97e3df3f881856b546997a3fed9e279c720145101567dd56be21688fed66bf9759e432a9aa89cbbd225d13cdea4ca05f7a45cfb6a682a3d5b1e18f7e6cf934fae5098108bae9058d05c3387a01d8d02a656d2bfff67e9f46b2d8a6aac28129e52efddf6e552214c3f8a45bc7a912cca9a7fec1d7d06412c6972cb9e3dc518983f56530b8bffe7f92c4b6eb47d4aef59fb513c4653a42de61bc17ad7728e7fc7590ff05a9e991de03f023d0aaf8688ed6170def5091c66576a424ac1cb"
110 | },
111 | "decrypt": {
112 | "comment": "This section contains the internal values generated by intermediate nodes when decrypting the onion.",
113 | "hops": [
114 | {
115 | "alias": "Alice",
116 | "privkey": "4141414141414141414141414141414141414141414141414141414141414141",
117 | "onion_message": "0201031195a8046dcbb8e17034bca630065e7a0982e4e36f6f7e5a8d4554e4846fcd9905560002531fe6068134503d2723133227c867ac8fa6c83c537e9a44c3c5bdbdcb1fe33793b828776d70aabbd8cef1a5b52d5a397ae1a20f20435ff6057cd8be339d5aee226660ef73b64afa45dbf2e6e8e26eb96a259b2db5aeecda1ce2e768bbc35d389d7f320ca3d2bd14e2689bef2f5ac0307eaaabc1924eb972c1563d4646ae131accd39da766257ed35ea36e4222527d1db4fa7b2000aab9eafcceed45e28b5560312d4e2299bd8d1e7fe27d10925966c28d497aec400b4630485e82efbabc00550996bdad5d6a9a8c75952f126d14ad2cff91e16198691a7ef2937de83209285f1fb90944b4e46bca7c856a9ce3da10cdf2a7d00dc2bf4f114bc4d3ed67b91cbde558ce9af86dc81fbdc37f8e301b29e23c1466659c62bdbf8cff5d4c20f0fb0851ec72f5e9385dd40fdd2e3ed67ca4517117825665e50a3e26f73c66998daf18e418e8aef9ce2d20da33c3629db2933640e03e7b44c2edf49e9b482db7b475cfd4c617ae1d46d5c24d697846f9f08561eac2b065f9b382501f6eabf07343ed6c602f61eab99cdb52adf63fd44a8db2d3016387ea708fc1c08591e19b4d9984ebe31edbd684c2ea86526dd8c7732b1d8d9117511dc1b643976d356258fce8313b1cb92682f41ab72dedd766f06de375f9edacbcd0ca8c99b865ea2b7952318ea1fd20775a28028b5cf59dece5de14f615b8df254eee63493a5111ea987224bea006d8f1b60d565eef06ac0da194dba2a6d02e79b2f2f34e9ca6e1984a507319d86e9d4fcaeea41b4b9144e0b1826304d4cc1da61cfc5f8b9850697df8adc5e9d6f3acb3219b02764b4909f2b2b22e799fd66c383414a84a7d791b899d4aa663770009eb122f90282c8cb9cda16aba6897edcf9b32951d0080c0f52be3ca011fbec3fb16423deb47744645c3b05fdbd932edf54ba6efd26e65340a8e9b1d1216582e1b30d64524f8ca2d6c5ba63a38f7120a3ed71bed8960bcac2feee2dd41c90be48e3c11ec518eb3d872779e4765a6cc28c6b0fa71ab57ced73ae963cc630edae4258cba2bf25821a6ae049fec2fca28b5dd1bb004d92924b65701b06dcf37f0ccd147a13a03f9bc0f98b7d78fe9058089756931e2cd0e0ed92ec6759d07b248069526c67e9e6ce095118fd3501ba0f858ef030b76c6f6beb11a09317b5ad25343f4b31aef02bc555951bc7791c2c289ecf94d5544dcd6ad3021ed8e8e3db34b2a73e1eedb57b578b068a5401836d6e382110b73690a94328c404af25e85a8d6b808893d1b71af6a31fadd8a8cc6e31ecc0d9ff7e6b91fd03c274a5c1f1ccd25b61150220a3fddb04c91012f5f7a83a5c90deb2470089d6e38cd5914b9c946eca6e9d31bbf8667d36cf87effc3f3ff283c21dd4137bd569fe7cf758feac94053e4baf7338bb592c8b7c291667fadf4a9bf9a2a154a18f612cbc7f851b3f8f2070e0a9d180622ee4f8e81b0ab250d504cef24116a3ff188cc829fcd8610b56343569e8dc997629410d1967ca9dd1d27eec5e01e4375aad16c46faba268524b154850d0d6fe3a76af2c6aa3e97647c51036049ac565370028d6a439a2672b6face56e1b171496c0722cfa22d9da631be359661617c5d5a2d286c5e19db9452c1e21a0107b6400debda2decb0c838f342dd017cdb2dccdf1fe97e3df3f881856b546997a3fed9e279c720145101567dd56be21688fed66bf9759e432a9aa89cbbd225d13cdea4ca05f7a45cfb6a682a3d5b1e18f7e6cf934fae5098108bae9058d05c3387a01d8d02a656d2bfff67e9f46b2d8a6aac28129e52efddf6e552214c3f8a45bc7a912cca9a7fec1d7d06412c6972cb9e3dc518983f56530b8bffe7f92c4b6eb47d4aef59fb513c4653a42de61bc17ad7728e7fc7590ff05a9e991de03f023d0aaf8688ed6170def5091c66576a424ac1cb",
118 | "next_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c"
119 | },
120 | {
121 | "alias": "Bob",
122 | "privkey": "4242424242424242424242424242424242424242424242424242424242424242",
123 | "onion_message": "0201031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f05560002536d53f93796cad550b6c68662dca41f7e8c221c31022c64dd1a627b2df3982b25eac261e88369cfc66e1e3b6d9829cb3dcd707046e68a7796065202a7904811bf2608c5611cf74c9eb5371c7eb1a4428bb39a041493e2a568ddb0b2482a6cc6711bc6116cef144ebf988073cb18d9dd4ce2d3aa9de91a7dc6d7c6f11a852024626e66b41ba1158055505dff9cb15aa51099f315564d9ee3ed6349665dc3e209eedf9b5805ee4f69d315df44c80e63d0e2efbdab60ec96f44a3447c6a6ddb1efb6aa4e072bde1dab974081646bfddf3b02daa2b83847d74dd336465e76e9b8fecc2b0414045eeedfc39939088a76820177dd1103c99939e659beb07197bab9f714b30ba8dc83738e9a6553a57888aaeda156c68933a2f4ff35e3f81135076b944ed9856acbfee9c61299a5d1763eadd14bf5eaf71304c8e165e590d7ecbcd25f1650bf5b6c2ad1823b2dc9145e168974ecf6a2273c94decff76d94bc6708007a17f22262d63033c184d0166c14f41b225a956271947aae6ce65890ed8f0d09c6ffe05ec02ee8b9de69d7077a0c5adeb813aabcc1ba8975b73ab06ddea5f4db3c23a1de831602de2b83f990d4133871a1a81e53f86393e6a7c3a7b73f0c099fa72afe26c3027bb9412338a19303bd6e6591c04fb4cde9b832b5f41ae199301ea8c303b5cef3aca599454273565de40e1148156d1f97c1aa9e58459ab318304075e034f5b7899c12587b86776a18a1da96b7bcdc22864fccc4c41538ebce92a6f054d53bf46770273a70e75fe0155cd6d2f2e937465b0825ce3123b8c206fac4c30478fa0f08a97ade7216dce11626401374993213636e93545a31f500562130f2feb04089661ad8c34d5a4cbd2e4e426f37cb094c786198a220a2646ecadc38c04c29ee67b19d662c209a7b30bfecc7fe8bf7d274de0605ee5df4db490f6d32234f6af639d3fce38a2801bcf8d51e9c090a6c6932355a83848129a378095b34e71cb8f51152dc035a4fe8e802fec8de221a02ba5afd6765ce570bef912f87357936ea0b90cb2990f56035e89539ec66e8dbd6ed50835158614096990e019c3eba3d7dd6a77147641c6145e8b17552cd5cf7cd163dd40b9eaeba8c78e03a2cd8c0b7997d6f56d35f38983a202b4eb8a54e14945c4de1a6dde46167e11708b7a5ff5cb9c0f7fc12fae49a012aa90bb1995c038130b749c48e6f1ffb732e92086def42af10fbc460d94abeb7b2fa744a5e9a491d62a08452be8cf2fdef573deedc1fe97098bce889f98200b26f9bb99da9aceddda6d793d8e0e44a2601ef4590cfbb5c3d0197aac691e3d31c20fd8e38764962ca34dabeb85df28feabaf6255d4d0df3d814455186a84423182caa87f9673df770432ad8fdfe78d4888632d460d36d2719e8fa8e4b4ca10d817c5d6bc44a8b2affab8c2ba53b8bf4994d63286c2fad6be04c28661162fa1a67065ecda8ba8c13aee4a8039f4f0110e0c0da2366f178d8903e19136dad6df9d8693ce71f3a270f9941de2a93d9b67bc516207ac1687bf6e00b29723c42c7d9c90df9d5e599dbeb7b73add0a6a2b7aba82f98ac93cb6e60494040445229f983a81c34f7f686d166dfc98ec23a6318d4a02a311ac28d655ea4e0f9c3014984f31e621ef003e98c373561d9040893feece2e0fa6cd2dd565e6fbb2773a2407cb2c3273c306cf71f427f2e551c4092e067cf9869f31ac7c6c80dd52d4f85be57a891a41e34be0d564e39b4af6f46b85339254a58b205fb7e10e7d0470ee73622493f28c08962118c23a1198467e72c4ae1cd482144b419247a5895975ea90d135e2a46ef7e5794a1551a447ff0a0d299b66a7f565cd86531f5e7af5408d85d877ce95b1df12b88b7d5954903a5296325ba478ba1e1a9d1f30a2d5052b2e2889bbd64f72c72bc71d8817288a2",
124 | "next_node_id": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007"
125 | },
126 | {
127 | "alias": "Carol",
128 | "privkey": "4343434343434343434343434343434343434343434343434343434343434343",
129 | "onion_message": "020102b684babfd400c8dd48b367e9754b8021a3594a34dc94d7101776c7f6a86d0582055600029a77e8523162efa1f4208f4f2050cd5c386ddb6ce6d36235ea569d217ec52209fb85fdf7dbc4786c373eebdba0ddc184cfbe6da624f610e93f62c70f2c56be1090b926359969f040f932c03f53974db5656233bd60af375517d4323002937d784c2c88a564bcefe5c33d3fc21c26d94dfacab85e2e19685fd2ff4c543650958524439b6da68779459aee5ffc9dc543339acec73ff43be4c44ddcbe1c11d50e2411a67056ba9db7939d780f5a86123fdd3abd6f075f7a1d78ab7daf3a82798b7ec1e9f1345bc0d1e935098497067e2ae5a51ece396fcb3bb30871ad73aee51b2418b39f00c8e8e22be4a24f4b624e09cb0414dd46239de31c7be035f71e8da4f5a94d15b44061f46414d3f355069b5c5b874ba56704eb126148a22ec873407fe118972127e63ff80e682e410f297f23841777cec0517e933eaf49d7e34bd203266b42081b3a5193b51ccd34b41342bc67cf73523b741f5c012ba2572e9dda15fbe131a6ac2ff24dc2a7622d58b9f3553092cfae7fae3c8864d95f97aa49ec8edeff5d9f5782471160ee412d82ff6767030fc63eec6a93219a108cd41433834b26676a39846a944998796c79cd1cc460531b8ded659cedfd8aecefd91944f00476f1496daafb4ea6af3feacac1390ea510709783c2aa81a29de27f8959f6284f4684102b17815667cbb0645396ac7d542b878d90c42a1f7f00c4c4eedb2a22a219f38afadb4f1f562b6e000a94e75cc38f535b43a3c0384ccef127fde254a9033a317701c710b2b881065723486e3f4d3eea5e12f374a41565fe43fa137c1a252c2153dde055bb343344c65ad0529010ece29bbd405effbebfe3ba21382b94a60ac1a5ffa03f521792a67b30773cb42e862a8a02a8bbd41b842e115969c87d1ff1f8c7b5726b9f20772dd57fe6e4ea41f959a2a673ffad8e2f2a472c4c8564f3a5a47568dd75294b1c7180c500f7392a7da231b1fe9e525ea2d7251afe9ca52a17fe54a116cb57baca4f55b9b6de915924d644cba9dade4ccc01939d7935749c008bafc6d3ad01cd72341ce5ddf7a5d7d21cf0465ab7a3233433aef21f9acf2bfcdc5a8cc003adc4d82ac9d72b36eb74e05c9aa6ccf439ac92e6b84a3191f0764dd2a2e0b4cc3baa08782b232ad6ecd3ca6029bc08cc094aef3aebddcaddc30070cb6023a689641de86cfc6341c8817215a4650f844cd2ca60f2f10c6e44cfc5f23912684d4457bf4f599879d30b79bf12ef1ab8d34dddc15672b82e56169d4c770f0a2a7a960b1e8790773f5ff7fce92219808f16d061cc85e053971213676d28fb48925e9232b66533dbd938458eb2cc8358159df7a2a2e4cf87500ede2afb8ce963a845b98978edf26a6948d4932a6b95d022004556d25515fe158092ce9a913b4b4a493281393ca731e8d8e5a3449b9d888fc4e73ffcbb9c6d6d66e88e03cf6e81a0496ede6e4e4172b08c000601993af38f80c7f68c9d5fff9e0e215cff088285bf039ca731744efcb7825a272ca724517736b4890f47e306b200aa2543c363e2c9090bcf3cf56b5b86868a62471c7123a41740392fc1d5ab28da18dca66618e9af7b42b62b23aba907779e73ca03ec60e6ab9e0484b9cae6578e0fddb6386cb3468506bf6420298bf4a690947ab582255551d82487f271101c72e19e54872ab47eae144db66bc2f8194a666a5daec08d12822cb83a61946234f2dfdbd6ca7d8763e6818adee7b401fcdb1ac42f9df1ac5cc5ac131f2869013c8d6cd29d4c4e3d05bccd34ca83366d616296acf854fa05149bfd763a25b9938e96826a037fdcb85545439c76df6beed3bdbd01458f9cf984997cc4f0a7ac3cc3f5e1eeb59c09cadcf5a537f16e444149c8f17d4bdaef16c9fbabc5ef06eb0f0bf3a07a1beddfeacdaf1df5582d6dbd6bb808d6ab31bc22e5d7",
130 | "next_node_id": "032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991"
131 | },
132 | {
133 | "alias": "Dave",
134 | "privkey": "4444444444444444444444444444444444444444444444444444444444444444",
135 | "onion_message": "0201025aaca62db7ce6b46386206ef9930daa32e979a35cb185a41cb951aa7d254b03c055600025550b2910294fa73bda99b9de9c851be9cbb481e23194a1743033630efba546b86e7d838d0f6e9cc0ed088dbf6889f0dceca3bfc745bd77d013a31311fa932a8bf1d28387d9ff521eabc651dee8f861fed609a68551145a451f017ec44978addeee97a423c08445531da488fd1ddc998e9cdbfcea59517b53fbf1833f0bbe6188dba6ca773a247220ec934010daca9cc185e1ceb136803469baac799e27a0d82abe53dc48a06a55d1f643885cc7894677dd20a4e4152577d1ba74b870b9279f065f9b340cedb3ca13b7df218e853e10ccd1b59c42a2acf93f489e170ee4373d30ab158b60fc20d3ba73a1f8c750951d69fb5b9321b968ddc8114936412346aff802df65516e1c09c51ef19849ff36c0199fd88c8bec301a30fef0c7cb497901c038611303f64e4174b5daf42832aa5586b84d2c9b95f382f4269a5d1bd4be898618dc78dfd451170f72ca16decac5b03e60702112e439cadd104fb3bbb3d5023c9b80823fdcd0a212a7e1aaa6eeb027adc7f8b3723031d135a09a979a4802788bb7861c6cc85501fb91137768b70aeab309b27b885686604ffc387004ac4f8c44b101c39bc0597ef7fd957f53fc5051f534b10eb3852100962b5e58254e5558689913c26ad6072ea41f5c5db10077cfc91101d4ae393be274c74297da5cc381cd88d54753aaa7df74b2f9da8d88a72bc9218fcd1f19e4ff4aace182312b9509c5175b6988f044c5756d232af02a451a02ca752f3c52747773acff6fd07d2032e6ce562a2c42105d106eba02d0b1904182cdc8c74875b082d4989d3a7e9f0e73de7c75d357f4af976c28c0b206c5e8123fc2391d078592d0d5ff686fd245c0a2de2e535b7cca99c0a37d432a8657393a9e3ca53eec1692159046ba52cb9bc97107349d8673f74cbc97e231f1108005c8d03e24ca813cea2294b39a7a493bcc062708f1f6cf0074e387e7d50e0666ce784ef4d31cb860f6cad767438d9ea5156ff0ae86e029e0247bf94df75ee0cda4f2006061455cb2eaff513d558863ae334cef7a3d45f55e7cc13153c6719e9901c1d4db6c03f643b69ea4860690305651794284d9e61eb848ccdf5a77794d376f0af62e46d4835acce6fd9eef5df73ebb8ea3bb48629766967f446e744ecc57ff3642c4aa1ccee9a2f72d5caa75fa05787d08b79408fce792485fdecdc25df34820fb061275d70b84ece540b0fc47b2453612be34f2b78133a64e812598fbe225fd85415f8ffe5340ce955b5fd9d67dd88c1c531dde298ed25f96df271558c812c26fa386966c76f03a6ebccbca49ac955916929bd42e134f982dde03f924c464be5fd1ba44f8dc4c3cbc8162755fd1d8f7dc044b15b1a796c53df7d8769bb167b2045b49cc71e08908796c92c16a235717cabc4bb9f60f8f66ff4fff1f9836388a99583acebdff4a7fb20f48eedcd1f4bdcc06ec8b48e35307df51d9bc81d38a94992dd135b30079e1f592da6e98dff496cb1a7776460a26b06395b176f585636ebdf7eab692b227a31d6979f5a6141292698e91346b6c806b90c7c6971e481559cae92ee8f4136f2226861f5c39ddd29bbdb118a35dece03f49a96804caea79a3dacfbf09d65f2611b5622de51d98e18151acb3bb84c09caaa0cc80edfa743a4679f37d6167618ce99e73362fa6f213409931762618a61f1738c071bba5afc1db24fe94afb70c40d731908ab9a505f76f57a7d40e708fd3df0efc5b7cbb2a7b75cd23449e09684a2f0e2bfa0d6176c35f96fe94d92fc9fa4103972781f81cb6e8df7dbeb0fc529c600d768bed3f08828b773d284f69e9a203459d88c12d6df7a75be2455fec128f07a497a2b2bf626cc6272d0419ca663e9dc66b8224227eb796f0246dcae9c5b0b6cfdbbd40c3245a610481c92047c968c9fc92c04b89cc41a0c15355a8f",
136 | "tlvs": {
137 | "unknown_tag_1": "68656c6c6f",
138 | "encrypted_recipient_data": "bdc03f088764c6224c8f939e321bf096f363b2092db381fc8787f891c8e6dc9284991b98d2a63d9f91fe563065366dd406cd8e112cdaaa80d0e6"
139 | }
140 | }
141 | ]
142 | }
143 | }
144 |
--------------------------------------------------------------------------------
/bolt04/blinded-payment-onion-test.json:
--------------------------------------------------------------------------------
1 | {
2 | "comment": "test vector for a payment onion sent to a partially blinded route",
3 | "generate": {
4 | "comment": "This section contains test data for creating a payment onion that sends to the provided blinded route.",
5 | "session_key": "0303030303030303030303030303030303030303030303030303030303030303",
6 | "associated_data": "4242424242424242424242424242424242424242424242424242424242424242",
7 | "final_amount_msat": 100000,
8 | "final_cltv": 749000,
9 | "blinded_payinfo": {
10 | "comment": "total costs for using the blinded path",
11 | "fee_base_msat": 10100,
12 | "fee_proportional_millionths": 251,
13 | "cltv_expiry_delta": 150
14 | },
15 | "blinded_route": {
16 | "comment": "This section contains a blinded route that the sender will use for his payment, usually obtained from a Bolt 12 invoice.",
17 | "first_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c",
18 | "first_path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766",
19 | "hops": [
20 | {
21 | "alias": "Bob",
22 | "blinded_node_id": "03da173ad2aee2f701f17e59fbd16cb708906d69838a5f088e8123fb36e89a2c25",
23 | "encrypted_data": "cd7b00ff9c09ed28102b210ac73aa12d63e90852cebc496c49f57c499a2888b49f2e72b19446f7e60a818aa2938d8c625415b992b8928a7321edb8f7cea40de362bed082ad51acc6156dca5532fb68"
24 | },
25 | {
26 | "alias": "Carol",
27 | "blinded_node_id": "02e466727716f044290abf91a14a6d90e87487da160c2a3cbd0d465d7a78eb83a7",
28 | "encrypted_data": "cc0f16524fd7f8bb0f4e8d40ad71709ef140174c76faa574cac401bb8992fef76c4d004aa485dd599ed1cf2715f570f656a5aaecaf1ee8dc9d0fa1d424759be1932a8f29fac08bc2d2a1ed7159f28b"
29 | },
30 | {
31 | "alias": "Dave",
32 | "blinded_node_id": "036861b366f284f0a11738ffbf7eda46241a8977592878fe3175ae1d1e4754eccf",
33 | "encrypted_data": "0fa1a72cff3b64a3d6e1e4903cf8c8b0a17144aeb249dcb86561adee1f679ee8db3e561d9e49895fd4bcebf6f58d6f61a6d41a9bf5aa4b0453437856632e8255c351873143ddf2bb2b0832b091e1b4"
34 | },
35 | {
36 | "alias": "Eve",
37 | "blinded_node_id": "021982a48086cb8984427d3727fe35a03d396b234f0701f5249daa12e8105c8dae",
38 | "encrypted_data": "da1c7e5f7881219884beae6ae68971de73bab4c3055d9865b1afb60722a63c688768042ade22f2c22f5724767d171fd221d3e579e43b354cc72e3ef146ada91a892d95fc48662f5b158add0af457da"
39 | }
40 | ]
41 | },
42 | "full_route": {
43 | "comment": "The sender adds one normal hop through Alice, who doesn't support blinded payments (and doesn't charge a fee). The sender provides the initial blinding point in Bob's onion payload, and encrypted_data for each node in the blinded route.",
44 | "hops": [
45 | {
46 | "alias": "Alice",
47 | "pubkey": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619",
48 | "payload": "14020301ae2d04030b6e5e0608000000000000000a",
49 | "tlvs": {
50 | "outgoing_channel_id": "0x0x10",
51 | "amt_to_forward": 110125,
52 | "outgoing_cltv_value": 749150
53 | }
54 | },
55 | {
56 | "alias": "Bob",
57 | "pubkey": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c",
58 | "payload": "740a4fcd7b00ff9c09ed28102b210ac73aa12d63e90852cebc496c49f57c499a2888b49f2e72b19446f7e60a818aa2938d8c625415b992b8928a7321edb8f7cea40de362bed082ad51acc6156dca5532fb680c21024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766",
59 | "tlvs": {
60 | "current_path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766",
61 | "encrypted_recipient_data": {
62 | "padding": "0000000000000000000000000000000000000000000000000000000000000000",
63 | "short_channel_id": "0x0x1",
64 | "payment_relay": {
65 | "cltv_expiry_delta": 50,
66 | "fee_proportional_millionths": 0,
67 | "fee_base_msat": 10000
68 | },
69 | "payment_constraints": {
70 | "max_cltv_expiry": 750150,
71 | "htlc_minimum_msat": 50
72 | },
73 | "allowed_features": {
74 | "features": []
75 | }
76 | }
77 | }
78 | },
79 | {
80 | "alias": "Carol",
81 | "pubkey": "02e466727716f044290abf91a14a6d90e87487da160c2a3cbd0d465d7a78eb83a7",
82 | "payload": "510a4fcc0f16524fd7f8bb0f4e8d40ad71709ef140174c76faa574cac401bb8992fef76c4d004aa485dd599ed1cf2715f570f656a5aaecaf1ee8dc9d0fa1d424759be1932a8f29fac08bc2d2a1ed7159f28b",
83 | "tlvs": {
84 | "encrypted_recipient_data": {
85 | "short_channel_id": "0x0x2",
86 | "next_path_key_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
87 | "payment_relay": {
88 | "cltv_expiry_delta": 75,
89 | "fee_proportional_millionths": 150,
90 | "fee_base_msat": 100
91 | },
92 | "payment_constraints": {
93 | "max_cltv_expiry": 750100,
94 | "htlc_minimum_msat": 50
95 | },
96 | "allowed_features": {
97 | "features": []
98 | }
99 | }
100 | }
101 | },
102 | {
103 | "alias": "Dave",
104 | "pubkey": "036861b366f284f0a11738ffbf7eda46241a8977592878fe3175ae1d1e4754eccf",
105 | "payload": "510a4f0fa1a72cff3b64a3d6e1e4903cf8c8b0a17144aeb249dcb86561adee1f679ee8db3e561d9e49895fd4bcebf6f58d6f61a6d41a9bf5aa4b0453437856632e8255c351873143ddf2bb2b0832b091e1b4",
106 | "tlvs": {
107 | "encrypted_recipient_data": {
108 | "padding": "00000000000000000000000000000000000000000000000000000000000000000000",
109 | "short_channel_id": "0x0x3",
110 | "payment_relay": {
111 | "cltv_expiry_delta": 25,
112 | "fee_proportional_millionths": 100
113 | },
114 | "payment_constraints": {
115 | "max_cltv_expiry": 750025,
116 | "htlc_minimum_msat": 50
117 | },
118 | "allowed_features": {
119 | "features": []
120 | }
121 | }
122 | }
123 | },
124 | {
125 | "alias": "Eve",
126 | "pubkey": "021982a48086cb8984427d3727fe35a03d396b234f0701f5249daa12e8105c8dae",
127 | "payload": "6002030186a004030b6dc80a4fda1c7e5f7881219884beae6ae68971de73bab4c3055d9865b1afb60722a63c688768042ade22f2c22f5724767d171fd221d3e579e43b354cc72e3ef146ada91a892d95fc48662f5b158add0af457da12030249f0",
128 | "tlvs": {
129 | "amt_to_forward": 100000,
130 | "total_amount_msat": 150000,
131 | "outgoing_cltv_value": 749000,
132 | "encrypted_recipient_data": {
133 | "padding": "00000000000000000000000000000000000000000000000000000000",
134 | "path_id": "c9cf92f45ade68345bc20ae672e2012f4af487ed4415",
135 | "payment_constraints": {
136 | "max_cltv_expiry": 750000,
137 | "htlc_minimum_msat": 50
138 | },
139 | "allowed_features": {
140 | "features": []
141 | }
142 | }
143 | }
144 | }
145 | ]
146 | },
147 | "onion": "0002531fe6068134503d2723133227c867ac8fa6c83c537e9a44c3c5bdbdcb1fe337dadf610256c6ab518495dce9cdedf9391e21a71dada75be905267ba82f326c0513dda706908cfee834996700f881b2aed106585d61a2690de4ebe5d56ad2013b520af2a3c49316bc590ee83e8c31b1eb11ff766dad27ca993326b1ed582fb451a2ad87fbf6601134c6341c4a2deb6850e25a355be68dbb6923dc89444fdd74a0f700433b667bda345926099f5547b07e97ad903e8a01566a78ae177366239e793dac719de805565b6d0a1d290e273f705cfc56873f8b5e28225f7ded7a1d4ceffae63f91e477be8c917c786435976102a924ba4ba3de6150c829ce01c25428f2f5d05ef023be7d590ecdf6603730db3948f80ca1ed3d85227e64ef77200b9b557f427b6e1073cfa0e63e4485441768b98ab11ba8104a6cee1d7af7bb5ee9c05cf9cf4718901e92e09dfe5cb3af336a953072391c1e91fc2f4b92e124b38e0c6d17ef6ba7bbe93f02046975bb01b7f766fcfc5a755af11a90cc7eb3505986b56e07a7855534d03b79f0dfbfe645b0d6d4185c038771fd25b800aa26b2ed2e30b1e713659468618a2fea04fcd0473284598f76b11b0d159d343bc9711d3bea8d561547bcc8fff12317c0e7b1ee75bcb8082d762b6417f99d0f71ff7c060f6b564ad6827edaffa72eefcc4ce633a8da8d41c19d8f6aebd8878869eb518ccc16dccae6a94c690957598ce0295c1c46af5d7a2f0955b5400526bfd1430f554562614b5d00feff3946427be520dee629b76b6a9c2b1da6701c8ca628a69d6d40e20dd69d6e879d7a052d9c16f544b49738c7ff3cdd0613e9ed00ead7707702d1a6a0b88de1927a50c36beb78f4ff81e3dd97b706307596eebb363d418a891e1cb4589ce86ce81cdc0e1473d7a7dd5f6bb6e147c1f7c46fa879b4512c25704da6cdbb3c123a72e3585dc07b3e5cbe7fecf3a08426eee8c70ddc46ebf98b0bcb14a08c469cb5cfb6702acc0befd17640fa60244eca491280a95fbbc5833d26e4be70fcf798b55e06eb9fcb156942dcf108236f32a5a6c605687ba4f037eddbb1834dcbcd5293a0b66c621346ca5d893d239c26619b24c71f25cecc275e1ab24436ac01c80c0006fab2d95e82e3a0c3ea02d08ec5b24eb39205c49f4b549dcab7a88962336c4624716902f4e08f2b23cfd324f18405d66e9da3627ac34a6873ba2238386313af20d5a13bbd507fdc73015a17e3bd38fae1145f7f70d7cb8c5e1cdf9cf06d1246592a25d56ec2ae44cd7f75aa7f5f4a2b2ee49a41a26be4fab3f3f2ceb7b08510c5e2b7255326e4c417325b333cafe96dde1314a15dd6779a7d5a8a40622260041e936247eec8ec39ca29a1e18161db37497bdd4447a7d5ef3b8d22a2acd7f486b152bb66d3a15afc41dc9245a8d75e1d33704d4471e417ccc8d31645fdd647a2c191692675cf97664951d6ce98237d78b0962ad1433b5a3e49ddddbf57a391b14dcce00b4d7efe5cbb1e78f30d5ef53d66c381a45e275d2dcf6be559acb3c42494a9a2156eb8dcf03dd92b2ebaa697ea628fa0f75f125e4a7daa10f8dcf56ebaf7814557708c75580fad2bbb33e66ad7a4788a7aaac792aaae76138d7ff09df6a1a1920ddcf22e5e7007b15171b51ff81799355232ce39f7d5ceeaf704255d790041d6390a69f42816cba641ec81faa3d7c0fdec59dfe4ca41f31a692eaffc66b083995d86c575aea4514a3e09e8b3a1fa4d1591a2505f253ad0b6bfd9d87f063d2be414d3a427c0506a88ac5bdbef9b50d73bce876f85c196dca435e210e1d6713695b529ddda3350fb5065a6a8288abd265380917bac8ebbc7d5ced564587471dddf90c22ce6dbadea7e7a6723438d4cf6ac6dae27d033a8cadd77ab262e8defb33445ddb2056ec364c7629c33745e2338"
148 | },
149 | "decrypt": {
150 | "comment": "This section contains the internal values generated by intermediate nodes when decrypting their payload.",
151 | "hops": [
152 | {
153 | "alias": "Alice",
154 | "onion": "0002531fe6068134503d2723133227c867ac8fa6c83c537e9a44c3c5bdbdcb1fe337dadf610256c6ab518495dce9cdedf9391e21a71dada75be905267ba82f326c0513dda706908cfee834996700f881b2aed106585d61a2690de4ebe5d56ad2013b520af2a3c49316bc590ee83e8c31b1eb11ff766dad27ca993326b1ed582fb451a2ad87fbf6601134c6341c4a2deb6850e25a355be68dbb6923dc89444fdd74a0f700433b667bda345926099f5547b07e97ad903e8a01566a78ae177366239e793dac719de805565b6d0a1d290e273f705cfc56873f8b5e28225f7ded7a1d4ceffae63f91e477be8c917c786435976102a924ba4ba3de6150c829ce01c25428f2f5d05ef023be7d590ecdf6603730db3948f80ca1ed3d85227e64ef77200b9b557f427b6e1073cfa0e63e4485441768b98ab11ba8104a6cee1d7af7bb5ee9c05cf9cf4718901e92e09dfe5cb3af336a953072391c1e91fc2f4b92e124b38e0c6d17ef6ba7bbe93f02046975bb01b7f766fcfc5a755af11a90cc7eb3505986b56e07a7855534d03b79f0dfbfe645b0d6d4185c038771fd25b800aa26b2ed2e30b1e713659468618a2fea04fcd0473284598f76b11b0d159d343bc9711d3bea8d561547bcc8fff12317c0e7b1ee75bcb8082d762b6417f99d0f71ff7c060f6b564ad6827edaffa72eefcc4ce633a8da8d41c19d8f6aebd8878869eb518ccc16dccae6a94c690957598ce0295c1c46af5d7a2f0955b5400526bfd1430f554562614b5d00feff3946427be520dee629b76b6a9c2b1da6701c8ca628a69d6d40e20dd69d6e879d7a052d9c16f544b49738c7ff3cdd0613e9ed00ead7707702d1a6a0b88de1927a50c36beb78f4ff81e3dd97b706307596eebb363d418a891e1cb4589ce86ce81cdc0e1473d7a7dd5f6bb6e147c1f7c46fa879b4512c25704da6cdbb3c123a72e3585dc07b3e5cbe7fecf3a08426eee8c70ddc46ebf98b0bcb14a08c469cb5cfb6702acc0befd17640fa60244eca491280a95fbbc5833d26e4be70fcf798b55e06eb9fcb156942dcf108236f32a5a6c605687ba4f037eddbb1834dcbcd5293a0b66c621346ca5d893d239c26619b24c71f25cecc275e1ab24436ac01c80c0006fab2d95e82e3a0c3ea02d08ec5b24eb39205c49f4b549dcab7a88962336c4624716902f4e08f2b23cfd324f18405d66e9da3627ac34a6873ba2238386313af20d5a13bbd507fdc73015a17e3bd38fae1145f7f70d7cb8c5e1cdf9cf06d1246592a25d56ec2ae44cd7f75aa7f5f4a2b2ee49a41a26be4fab3f3f2ceb7b08510c5e2b7255326e4c417325b333cafe96dde1314a15dd6779a7d5a8a40622260041e936247eec8ec39ca29a1e18161db37497bdd4447a7d5ef3b8d22a2acd7f486b152bb66d3a15afc41dc9245a8d75e1d33704d4471e417ccc8d31645fdd647a2c191692675cf97664951d6ce98237d78b0962ad1433b5a3e49ddddbf57a391b14dcce00b4d7efe5cbb1e78f30d5ef53d66c381a45e275d2dcf6be559acb3c42494a9a2156eb8dcf03dd92b2ebaa697ea628fa0f75f125e4a7daa10f8dcf56ebaf7814557708c75580fad2bbb33e66ad7a4788a7aaac792aaae76138d7ff09df6a1a1920ddcf22e5e7007b15171b51ff81799355232ce39f7d5ceeaf704255d790041d6390a69f42816cba641ec81faa3d7c0fdec59dfe4ca41f31a692eaffc66b083995d86c575aea4514a3e09e8b3a1fa4d1591a2505f253ad0b6bfd9d87f063d2be414d3a427c0506a88ac5bdbef9b50d73bce876f85c196dca435e210e1d6713695b529ddda3350fb5065a6a8288abd265380917bac8ebbc7d5ced564587471dddf90c22ce6dbadea7e7a6723438d4cf6ac6dae27d033a8cadd77ab262e8defb33445ddb2056ec364c7629c33745e2338",
155 | "node_privkey": "4141414141414141414141414141414141414141414141414141414141414141"
156 | },
157 | {
158 | "alias": "Bob",
159 | "onion": "000280caa47c2a0ea677f6a77529e46caa04212153a8d5f829bee1e7339b17e2e2a9a3461d10472364a4ff12344beb6df96fb0c38ec47d1e956ddff5a665190fcca5ed02c3a3903fd8bbd4a4b95b197867c378b67b08f0624cfe80734ba512869c0fa22099beb1f6f1ea325b07ce7449736d7ffad79178b428d8ea2d7bc6578f12dbd788ef933f3b5ba352797c41f6786c3820c96726acf8bddf2cfa5d9c617d2b0bd5ab7b93f7964c98f44cf47db8422f47d11100236a29579f1cafcd38bd979814e1d2bf6d625edf50e1e21bfaf6268e3180dd7aafd3892da281c6dd53c1c366d0fdaf670b6ad84a38d6e8a3f4a80d132d686fd3b7443bc2250023bdb9303190f74c9220481cf99da30b5ec2bdb5a49028f5014e3eaeaa48429a0c78ebd3bb7c7d582c22b7d547cd269f0c4490373a81bf92687e73dac2075b4bda189ce0be225f5f510655e37a6e724a1415bede0a076b92a882cc2a82878ba67aaedf71454eb42b7f8638df8e21d5f708006e5112e2dc0a4afbcfed9f2c7959be812853ca8e313fbc99a0f38f1ee4479c96ccb836632b0808401db159bd2637f7a664013241e4664e994a0a9a3940115a702c60381e66d291e1ade1be2802e1226e311e3201a7c9682b6bc4354caff3d439adb1dfee53ad3fb3dd5e169d64796853bb323129f41213b166a7cac00f728c3e33bd7e59aa2ac0d1341cdb1532b507a0f446e51022a882ac16405442347b70f78c9b6e122f8e70096a4fae4c0405db5b869e0b7b59b09519c4dbf4d4980483906e837da0bee93f668ffaad37d6a4764211a02f95ad2dc2d942c198796741c20a3baf8efb5a53bd9c1a0148318d60a97d0013ab63269097ea295d62c1426d064f0b31c02e74a348ee0509998e701069f5a1e0c1086aed38d2ec87da69fb57a992d88ace3b4a16b0960f5a94936e2e684a9926cf4f911969a2a5d31fed0c7616d30197848253170e51274278873b11f3f5cc1b04b14aa5812524e4d86cbf08306c2aa671288324d7a009b2be533b1d7d0ce6defeeb630b86a9655f1e6424fcb559ed67457c115fba0d0719374802ea68fab299fd3f273be86fa3d2e7456020db2f47c6ec16c21ce6ec65de495e20af1941a5dcd65d910c1cb93f22e1318c173c645c81aed681c9704a8a541ac3d6ff604f46d0260468acbfec1b771b9eb8cd49a2124468dae786571895a569aae18438eaee6343ab2634823119fa2439634645d12e3b4a748b9cc0398b8416a834eb5d9e5cf619bbfaba4894d1c574c738caf530d0862f4cc75eb52bd3921d2d9edb09940edb1e3776423b0046d870ccdcc5d61f72e0440b97a93eeef21fb246a779d339be301a5971400749d6cc9911dfbf9de8ae86fac83c860fdd0e2bfa40af37c99d50e50fd6e5ae86597a201112ed404042b55e132f243dec481a2adc1d5e4b71e1efdea806ea900b2907ce877742d5ecf700ff3640f737863d0dd7207e462ee8d0e17d52047a88ae7446f419560d23968bf64957949e36953155b0ac2511c66be2890b4036329a21e132efb635297a64431899e0c351e50c6682c9b4d79b5d122466d02cd84f206369417d9c194a9349d3c631d72eb7857a9cd542906fc02ad6cdcf9bcf25ace3d826b6623fa5164351e14d3f0de5c8445a2ba3aae26595d0e31c3e307c1d56d4274f61f056145c1b8d6880872b9b10a8bfa4a923cad2edbcf5c50eba48936ed2bcc0be60eb721a74b46704aaae5ad24e2797852195dfacbb30a777d33b63d4dc4f35cfbe5e88fd1944c55a54fd53581446ea061ad29f4671da819ad7488c5dfc700f5f7a1b2af0d6a6e9d9ffc570a6d3209614ab4dc43728f3f0cd7eb4ce36ccd98936bbcbd32627384434bd01e9c0f93b2a5173fba184685e19b9af78afe876aa4e4b4242382b293133771d95a2bd83fa9c62",
160 | "node_privkey": "4242424242424242424242424242424242424242424242424242424242424242",
161 | "next_path_key": "034e09f450a80c3d252b258aba0a61215bf60dda3b0dc78ffb0736ea1259dfd8a0"
162 | },
163 | {
164 | "alias": "Carol",
165 | "onion": "000288b48876fb0dc0d7375233ccaf2910dc0dc81ba52e5a7906f00d75e0d58dbd4bb7c2714870529410735f0951e72cbe981e2e167c0d8f3de33a36e39e78465aea2acad1e23c78b6fd342d63e37d214c912b4a0be344618f779138edc1b42a5ca3218ca2fea4be427f6cd0d387160db2bf6c2ba8e82941c8cf3626bd6bed7187f633012ef49df38f6b12963cb639e9eed1b9d269dcebcbd0b25287aa536ec85e7320b02e193122199a745ccbaaebd37f5d4b71f52f9b50feeb793eeef56924a046bc5e7003f6253e0284a8d3fe2e42c3564050f1e753cd32cc258ac0ffa6e05eecad5ba1286f78252e60dd884a65405ab673a85ba52adfa65c1086d4bb37ba2e0848adb2b04379775ad798492b14e8997f30ffa9cf5d432bdf5b246fce008fd876399beed827db58195f4f6192f6ff4ec63cb17fdcb497cb7aec26846a71dd8dca02fc3bb14dd7231a4d62a981bec54b71eb20331096dfa214a0ff4489ee96db663826ae8c850e9f06baa52a47b8eb576363f97e742aab2dc616acc6e74588e1d2ac16694febc90abaf5b1c684163c0e615a68d32633f01934adc8c6bf91fa3fd7aad033b7596d60402494e45e2c1632c40f7bfbd88a81a896a1d28ed6338c83e1eeaa467945d59998eb456c95f94bf1892e8f326ec2d5e0196b7073f106febc6ab8ca5bcc23f77ffc819bc1b5debce418ccc7d8391bbf33bceee6110beba170121bd99f54c956e64970bdab31227b03ee0ea3f01fbd9bd74015f6f82d04fab072e8f85f4370d09f41ee3e48eb959767bd989abb4eea42c4daa0437a7f747d7f9b70eb87b9f9b0b6f283b8205912601a432999b8869fd9fe5bad3572edac24da7184f9298f21ff60923db277264d29c846dd2f228f6fc53b6b60364237de64773f803f174ed10229c374f603ccc5fd3a62cb413ffe6f5630dc646bb33f231b2350537ec39e5d3f2fe1a1cb019ed0b18ad14019cad27afcca8ad70387ca110394c0432774f1aa1fa404b2e086c84a55388d3bd102501c78ef925cce89d76fa04c3f20f2d1f0ce507ac8b37b7913e3949ba12bbc5a4f6bac37c2415622d365bc8b83709a28e3d46f3850c89a3ff4d027fef6e3e4ce5c6c85f663c7eaec3c9730106fb82f53249a905533cfabee812aae51965b24b42f7ab471967bc8e73354e69141ee26a1f03684d5fb9c256a34de8257210e0390dd3962db521ae0a3bdab28300610ab2a634b699e5f092da5a061609ef6414bd805c8171f54ad6f285fb64ce0becca0b61188badcf8ef21190dad629e3fb3e89f55ebba829919540ebf5f8ae4283836d3c9133c1ca3365f6b9394916730411650686e0c2ab9c53b6cda9efdd5cfcb53ba9b6962bb6aa49d0a83a87460b60a9c7d2643ee99afe652883795f14014ec5df61b1e30c041c1fa6487f3c82f1ded5f83ffbef5017e197b7fb77be3b36e284a15e57d45bf9316dcaf97eb78ee4642b731ba05c5063bce1333fab4af6da97c80a96ee599b4df823efbedc250c0abba9783da7ddf2414b2a4774ff2880a7dc6791103e18b8631e39743cf9e87aed71700daa5dc72fdae520324741f92ea3d510ff555dea5e45f15cda87272d4559a12d4777680acb06993840e3c748da82c16cae556015fb2acd0335da11a3388575394048ab71199793ab706abc9d68add2075d79a5cc0f779845ee8b98951be61fd293d6c15b9d4653935bf17cf50bd31f8b79e60dba0e7fd6864754fd94262485a4f65e7eb3e1922f51b1a4dd2b4fd2c20d94d1213fbe90bd603dfc7e15176382e3ce0f43f980d44d23bf3c57f54a15f42c171a8f2511e28ac178c6f01396e50397a57ffb09c5e6c315bd3ae7983577c1a0386c6d5d9a2223438e321b0fedfdee58fa452d57dc11a256834bb49ac9deeec88e4bf563c7340f44a240caec941c7e50f09cf",
166 | "node_privkey": "4343434343434343434343434343434343434343434343434343434343434343",
167 | "next_path_key": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f"
168 | },
169 | {
170 | "alias": "Dave",
171 | "onion": "0003f25471c0f2ff549a7fd7859100306bb6c294c209f34c77f782897f184b967c498efc246bdb8e060a6d1cf8dd0d4d732e33311fb96c9e9f1274005fa3d08b41704a1b7224c6300a7caead7baa0a8263eba2e0de6956ee8e4a1958264f47e4cf20d194eb576f5bd249ee4fece563f80fd76dc3eaca8f956188406d83195752b5c90c4b2a5e7ac3a8d5c62b17b551aff48ef6842a7e9326832c9a4a2fd415011150a9e71beb901fd9747bac8add1c694b612730dc86b5b19a0bbbc675947a953316e3303d7b30c182f94def9206671edac9a3ec3e52d28fc28247a1c73ab751bf61c82c3950f617e758f79bd0ba294defb20466eaf1e801462046baad3aec3e5b8868a7b037f23d73a47a7e74c77107334f37388cff863e452820c61d89728fa75c84bc7cdfc06dcdd1911f5f803353926d073efd65251380e174913aae03318ea5b6f0ec83998c55ab99bef62803ea2da9f6d1ea892b90efc4f8ffb685a5201a781da2e6ac5923645638c9709ae32171a00c0cd3d8c7eedfb06b4eedc7d3e566987e2e3805a038f21d78ded5d6c7137a5e8e592f3180ee4d5f4e1289176f67fc38690d0958bc82e240b72b10577f340f1e14b8633f0b6d9729ff4618be2a972400a015a871ba33be70335f652a8d70f2bd32421d6ac2af781d667dad787d6aef4505a15d046579e46eebe757444cffca6d0610f0dd36a7ce57af969bd0c3f7006298ef406a25f689daf58f875d44d2423ebf195b503f11c37c506ea6abe50a463f7bb5e9b964604d832724de768513f6b38bf71715e1feea8a6e86797788d487146891564919da1372016ed8f08c7fcbff66a4a65a3d0fcd8e3daac6eba41f5d65ef2d8075364a9e78b3a273549f6eac4abb72e912e237990367e0d43e89945f8ac3907be5a6c662139485a50cb5ce3f0ba08586c39f6c515368ec3f91b72295f1b7a73a9df322ae9a45d363d6c616be3300083764cbdee31221f25a318f095feacb09f957c96db30fccca47a0215b576c3ed925a0bad05d6400abe318c11f36628c387a4ee38832182cd44b3cd48e5422c1f1e3b57218dfe72c611f5415127720e60f6e2400607e61841b76de1704bcbeb0daf1377ccb2253916de2b6d490bb71ba0a44fea2e94f2423d723934557d5905e01b2b80232a884e258d46dc92ea11e0818d0ece5b914f02049866e151801ab8c9aea155479b354dc91151fb9ba43277458f9760dd859faaa139e3b9ab36a1dbc36a93ef2c90598b20cb30ef3c4f23a2d6178b4d1da668fb328a25d84d30a132d9f2a6a988cbe2e5c2be01cb6db4b4725a50d6cdacf5fb083e7d650a25bec1407fbc047d26076c7596429a29606ad527e97ef0824ad6c1b05831a3e5b71c63a528918a3301cdd4061fc1fcce3da601961f2602a2b002ac8404125c2d52666263858a923e197efcda873c32d86897352e4f2264ad6a1b48acc0fe78ff55cb442cb2bb5fa2880810e1d00aa0247057fb80b7ed36cf9647af41b44ee4a63ee2d6f652526404572520a7d2d9dcde4e62df0c3be89f8471550594cdd16a51a9cacc58729c092c68506162fe65edc2314055d389f724ced189d826a546b5c4d08a43d977b3cf033de5760b71a7cc38ee5851592031aafb467a89b3b6c7ed67b15d44c48d6baedce3e95e08ec7c55038f3eba90ccb900895734f0fb7efe54961ce493369cc56416898a9bed7c2482871c15a7f1eb5ed17c33657fc31333539c2dfb59461af09e7049228113b5c9feea5a6e9959c18c51b19c90995afb9c76f2c0c820964cd7989c993a73925818a656c6a18dcd1a1e3782b2eae06dd5a41250ec2d1c203626ab9920c1673339eff04b1eb0cab85ef5909f571f9b83cdf21697c9f5cfa1c76e7bca955510e2126b3bb989a4ac21cf948f965e48bc363d2997437797b4f770e8b65",
172 | "node_privkey": "4444444444444444444444444444444444444444444444444444444444444444",
173 | "next_path_key": "03e09038ee76e50f444b19abf0a555e8697e035f62937168b80adf0931b31ce52a"
174 | },
175 | {
176 | "alias": "Eve",
177 | "onion": "0002ef43c4dfe9aee14248c445406ac7980474ce106c504d9025f57963739130adfd06eb26201baee8866af2d1b7a7ab26595349dad002af0590193aaa8f400ab394f5994ec831aeeecb64421c566e3556cbdd7e7e50deb1fc49fd5e007308ab6494415514abff978899623f9b6065ca1e243bb78170118e8b8c8b53b750b59cc1ec017d167adbb3aabab7c2d84fbf94f5d827239f4c2b9d2c3cfe68fe5641f25e386202a4b6edff2a71e700229df7230c8ca31bd5588f04799e9640c9c20a47cba713f3cc5ad3202e14bb520880f2a8409d8e7835cae21b48a651c2d47fe6af785889ab98f1416f6e4ad67a66ae681e9a8828bad3f9b6890221c4a7ec80531d6b63eb30843f613ce644795bc8bcee60e8f7b36f3fd04de762f103c52efaf36a2f3bbbaac482d6271dc4180c10bcc076c04d06ea7fd8fb6a647e0e10523b05da2d89e4139fb55c2315cd01bdcbd57587fef8442d7ff5620630fd2d2e79739d90be811bf2cba60415d6cba2cea14ba1859f3122cd905c4e12e3e2a1ab6fab54b2ec40e434626e2d3c3195c02c82a8bd64d226c2328ac72ca12197d9908eaf54333717448ce6ed73adc0ac05e2ee1d735131d87918beb8995993dc8f63fe10f2c8eba2be7ab8bb44d9f78f59ef3e4c180bd75e4eef2381450c6f0480d543997305f1d07815993b5aca8d88d474966d9abec93bb069a16aa2da75b87f94576e01d08a17d3e0e3d0370f010733a7d7affb12cdf94c259a62607fce71003535c4727305de5ff7bba3840922844b3a45f62c29715fccf440517ef121450f6962396fba9b07036d085582405dcae6ee95964b66bc7c85b8d02d90091500db3cebf6de584f86b7b55335a8c9aa26381b00747f055cc458a2cadfccf9c29702bf941447beaca6583cca09492a57d4b03b2ca00dbaf41dfd6a9b249381626a7debe475735a7e39e77a363eccf14669046f656cc09ad448da8d8b545e6a604f46dc481786d09a94c63cf23f49ba367d2929466364dbce2a8ffce3dadf8f4cef8a56e1fefa1a3304a953fe83018e57d8a95694b02d994fea2630a9a3d5f1e2f6d6142d503ec4152871f7122d7e566a03261f554639e7a759e0e73846f71d5cace37d91336fc9ca9396bf64ca2cf45fa2db779b3b5c63b04f1c0c1fb79fdfcf5a82b0202df934ae1720a7ce1e047cbec3f82737b50168c974f4623cacce87e3f5bd5232caca7956d28ffedcf11ac5998662c5f6b13c6126584ca2e894d3fcbad4d130bbe22e88a135e0020cdd43853e0b3af3800e9544854d211e873cf68ab683578d501d69ec5dc7fce42ac436d58243880c1b88227b0681c6c9dd8a8ad0793202b15ab63b787b748e258da3e68d0e649fc4ac081a71de8adbc891c113d5f722686b6ac4ed9e3cc247bc4a4643416f480627e9de20f7307f434a499f5c6951c2e8b3ff51d455bf65ceb5ee3dee47b968ac2642e13d8a68f903b73627c2e75788fecca5836371a908eea4f1ea44db2315bc185f77e478efeaaa4da2da13fe7aeaa79ed1d04876a8b2b7b333c5de8c4c9a50274c2eb7b9bd2a3630c57173174781fc9785235f830cefa1c82080eaffdef257f18eedc9ddfd25a696a11a3dc56cd836be72f5f4a2cbb6316d5d3b1ad91a7ec7d877f28d2c29a5525b0b24362699281b0e3b48f38caf1085045fe9089f9e6fb29e4b47aa4cecf68c9bf72073469bd9beeea5e88bfe554cb6a81231149ba7fe7784c154fd8b0f9179ecdf1e9fd5c2939ec1ab16df9cbe9359101ebce933d4f65d3f66f87afaecfe9c046b52f4878b6c430329df7bd879fba8864fcbd9b782bf545734699b9b5a66b466dcedc0c9368803b5b0f1232950cef398ad3e057a5db964bd3e5c8a5717b30b41601a4f11ad63afe404cb6f1e8ea5fd7a8e085b65ca5136146febf4d47928dcc9a9e0",
178 | "node_privkey": "4545454545454545454545454545454545454545454545454545454545454545",
179 | "next_path_key": "038fc6859a402b96ce4998c537c823d6ab94d1598fca02c788ba5dd79fbae83589"
180 | }
181 | ]
182 | }
183 | }
--------------------------------------------------------------------------------
/bolt04/onion-error-test.json:
--------------------------------------------------------------------------------
1 | {
2 | "comment": "A simple error returned by node hops[4], the public/private keys and shared_secrets are identical to the ones used in `onion-test-v0.json`",
3 | "generate": {
4 | "session_key": "4141414141414141414141414141414141414141414141414141414141414141",
5 | "failure_message": "2002",
6 | "hops": [
7 | {
8 | "version": 0,
9 | "pubkey": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619",
10 | "hop_shared_secret": "53eb63ea8a3fec3b3cd433b85cd62a4b145e1dda09391b348c4e1cd36a03ea66",
11 | "ammag_key": "3761ba4d3e726d8abb16cba5950ee976b84937b61b7ad09e741724d7dee12eb5"
12 | },
13 | {
14 | "version": 0,
15 | "pubkey": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c",
16 | "hop_shared_secret": "a6519e98832a0b179f62123b3567c106db99ee37bef036e783263602f3488fae",
17 | "ammag_key": "59ee5867c5c151daa31e36ee42530f429c433836286e63744f2020b980302564"
18 | },
19 | {
20 | "version": 0,
21 | "pubkey": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007",
22 | "hop_shared_secret": "3a6b412548762f0dbccce5c7ae7bb8147d1caf9b5471c34120b30bc9c04891cc",
23 | "ammag_key": "1bf08df8628d452141d56adfd1b25c1530d7921c23cecfc749ac03a9b694b0d3"
24 | },
25 | {
26 | "version": 0,
27 | "pubkey": "032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991",
28 | "hop_shared_secret": "21e13c2d7cfe7e18836df50872466117a295783ab8aab0e7ecc8c725503ad02d",
29 | "ammag_key": "cd9ac0e09064f039fa43a31dea05f5fe5f6443d40a98be4071af4a9d704be5ad"
30 | },
31 | {
32 | "version": 0,
33 | "pubkey": "02edabbd16b41c8371b92ef2f04c1185b4f03b6dcd52ba9b78d9d7c89c8f221145",
34 | "hop_shared_secret": "b5756b9b542727dbafc6765a49488b023a725d631af688fc031217e90770c328",
35 | "um_key": "4da7f2923edce6c2d85987d1d9fa6d88023e6c3a9c3d20f07d3b10b61a78d646",
36 | "ammag_key": "2f36bb8822e1f0d04c27b7d8bb7d7dd586e032a3218b8d414afbba6f169a4d68",
37 | "payload": "0002200200fe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
38 | "comment": "hops[4] is the only node that needs a mu_key since it is the only node that computes an HMAC of the original error message, the payload is omits the HMAC."
39 | }
40 | ]
41 | },
42 | "errorpacket": "9c5add3963fc7f6ed7f148623c84134b5647e1306419dbe2174e523fa9e2fbed3a06a19f899145610741c83ad40b7712aefaddec8c6baf7325d92ea4ca4d1df8bce517f7e54554608bf2bd8071a4f52a7a2f7ffbb1413edad81eeea5785aa9d990f2865dc23b4bc3c301a94eec4eabebca66be5cf638f693ec256aec514620cc28ee4a94bd9565bc4d4962b9d3641d4278fb319ed2b84de5b665f307a2db0f7fbb757366067d88c50f7e829138fde4f78d39b5b5802f1b92a8a820865af5cc79f9f30bc3f461c66af95d13e5e1f0381c184572a91dee1c849048a647a1158cf884064deddbf1b0b88dfe2f791428d0ba0f6fb2f04e14081f69165ae66d9297c118f0907705c9c4954a199bae0bb96fad763d690e7daa6cfda59ba7f2c8d11448b604d12d"
43 | }
44 |
--------------------------------------------------------------------------------
/bolt04/onion-test.json:
--------------------------------------------------------------------------------
1 | {
2 | "comment": "A testcase for a variable length hop_payload. The third payload is 275 bytes long. All the payloads already have the variable length encoded.",
3 | "generate": {
4 | "session_key": "4141414141414141414141414141414141414141414141414141414141414141",
5 | "associated_data": "4242424242424242424242424242424242424242424242424242424242424242",
6 | "hops": [
7 | {
8 | "pubkey": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619",
9 | "payload": "1202023a98040205dc06080000000000000001"
10 | },
11 | {
12 | "pubkey": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c",
13 | "payload": "52020236b00402057806080000000000000002fd02013c0102030405060708090a0b0c0d0e0f0102030405060708090a0b0c0d0e0f0102030405060708090a0b0c0d0e0f0102030405060708090a0b0c0d0e0f"
14 | },
15 | {
16 | "pubkey": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007",
17 | "payload": "12020230d4040204e206080000000000000003"
18 | },
19 | {
20 | "pubkey": "032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991",
21 | "payload": "1202022710040203e806080000000000000004"
22 | },
23 | {
24 | "pubkey": "02edabbd16b41c8371b92ef2f04c1185b4f03b6dcd52ba9b78d9d7c89c8f221145",
25 | "payload": "fd011002022710040203e8082224a33562c54507a9334e79f0dc4f17d407e6d7c61f0e2f3d0d38599502f617042710fd012de02a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a"
26 | }
27 | ]
28 | },
29 | "onion": "0002eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619f7f3416a5aa36dc7eeb3ec6d421e9615471ab870a33ac07fa5d5a51df0a8823aabe3fea3f90d387529d4f72837f9e687230371ccd8d263072206dbed0234f6505e21e282abd8c0e4f5b9ff8042800bbab065036eadd0149b37f27dde664725a49866e052e809d2b0198ab9610faa656bbf4ec516763a59f8f42c171b179166ba38958d4f51b39b3e98706e2d14a2dafd6a5df808093abfca5aeaaca16eded5db7d21fb0294dd1a163edf0fb445d5c8d7d688d6dd9c541762bf5a5123bf9939d957fe648416e88f1b0928bfa034982b22548e1a4d922690eecf546275afb233acf4323974680779f1a964cfe687456035cc0fba8a5428430b390f0057b6d1fe9a8875bfa89693eeb838ce59f09d207a503ee6f6299c92d6361bc335fcbf9b5cd44747aadce2ce6069cfdc3d671daef9f8ae590cf93d957c9e873e9a1bc62d9640dc8fc39c14902d49a1c80239b6c5b7fd91d05878cbf5ffc7db2569f47c43d6c0d27c438abff276e87364deb8858a37e5a62c446af95d8b786eaf0b5fcf78d98b41496794f8dcaac4eef34b2acfb94c7e8c32a9e9866a8fa0b6f2a06f00a1ccde569f97eec05c803ba7500acc96691d8898d73d8e6a47b8f43c3d5de74458d20eda61474c426359677001fbd75a74d7d5db6cb4feb83122f133206203e4e2d293f838bf8c8b3a29acb321315100b87e80e0edb272ee80fda944e3fb6084ed4d7f7c7d21c69d9da43d31a90b70693f9b0cc3eac74c11ab8ff655905688916cfa4ef0bd04135f2e50b7c689a21d04e8e981e74c6058188b9b1f9dfc3eec6838e9ffbcf22ce738d8a177c19318dffef090cee67e12de1a3e2a39f61247547ba5257489cbc11d7d91ed34617fcc42f7a9da2e3cf31a94a210a1018143173913c38f60e62b24bf0d7518f38b5bab3e6a1f8aeb35e31d6442c8abb5178efc892d2e787d79c6ad9e2fc271792983fa9955ac4d1d84a36c024071bc6e431b625519d556af38185601f70e29035ea6a09c8b676c9d88cf7e05e0f17098b584c4168735940263f940033a220f40be4c85344128b14beb9e75696db37014107801a59b13e89cd9d2258c169d523be6d31552c44c82ff4bb18ec9f099f3bf0e5b1bb2ba9a87d7e26f98d294927b600b5529c47e04d98956677cbcee8fa2b60f49776d8b8c367465b7c626da53700684fb6c918ead0eab8360e4f60edd25b4f43816a75ecf70f909301825b512469f8389d79402311d8aecb7b3ef8599e79485a4388d87744d899f7c47ee644361e17040a7958c8911be6f463ab6a9b2afacd688ec55ef517b38f1339efc54487232798bb25522ff4572ff68567fe830f92f7b8113efce3e98c3fffbaedce4fd8b50e41da97c0c08e423a72689cc68e68f752a5e3a9003e64e35c957ca2e1c48bb6f64b05f56b70b575ad2f278d57850a7ad568c24a4d32a3d74b29f03dc125488bc7c637da582357f40b0a52d16b3b40bb2c2315d03360bc24209e20972c200566bcf3bbe5c5b0aedd83132a8a4d5b4242ba370b6d67d9b67eb01052d132c7866b9cb502e44796d9d356e4e3cb47cc527322cd24976fe7c9257a2864151a38e568ef7a79f10d6ef27cc04ce382347a2488b1f404fdbf407fe1ca1c9d0d5649e34800e25e18951c98cae9f43555eef65fee1ea8f15828807366c3b612cd5753bf9fb8fced08855f742cddd6f765f74254f03186683d646e6f09ac2805586c7cf11998357cafc5df3f285329366f475130c928b2dceba4aa383758e7a9d20705c4bb9db619e2992f608a1ba65db254bb389468741d0502e2588aeb54390ac600c19af5c8e61383fc1bebe0029e4474051e4ef908828db9cca13277ef65db3fd47ccc2179126aaefb627719f421e20",
30 | "decode": [
31 | "4141414141414141414141414141414141414141414141414141414141414141",
32 | "4242424242424242424242424242424242424242424242424242424242424242",
33 | "4343434343434343434343434343434343434343434343434343434343434343",
34 | "4444444444444444444444444444444444444444444444444444444444444444",
35 | "4545454545454545454545454545454545454545454545454545454545454545"
36 | ]
37 | }
38 |
--------------------------------------------------------------------------------
/bolt04/route-blinding-test.json:
--------------------------------------------------------------------------------
1 | {
2 | "comment": "test vector for using blinded routes",
3 | "generate": {
4 | "comment": "This section contains test data for creating a blinded route. This route is the concatenation of two blinded routes: one from Dave to Eve and one from Bob to Carol.",
5 | "hops": [
6 | {
7 | "comment": "Bob creates a Bob -> Carol route with the following session_key and concatenates it with the Dave -> Eve route.",
8 | "session_key": "0202020202020202020202020202020202020202020202020202020202020202",
9 | "alias": "Bob",
10 | "node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c",
11 | "tlvs": {
12 | "padding": "0000000000000000000000000000000000000000000000000000",
13 | "short_channel_id": "0x0x1729",
14 | "payment_relay": {
15 | "cltv_expiry_delta": 36,
16 | "fee_proportional_millionths": 150,
17 | "fee_base_msat": 10000
18 | },
19 | "payment_constraints": {
20 | "max_cltv_expiry": 748005,
21 | "htlc_minimum_msat": 1500
22 | },
23 | "allowed_features": {
24 | "features": []
25 | },
26 | "unknown_tag_561": "123456"
27 | },
28 | "encoded_tlvs": "011a0000000000000000000000000000000000000000000000000000020800000000000006c10a0800240000009627100c06000b69e505dc0e00fd023103123456",
29 | "path_privkey": "0202020202020202020202020202020202020202020202020202020202020202",
30 | "path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766",
31 | "shared_secret": "76771bab0cc3d0de6e6f60147fd7c9c7249a5ced3d0612bdfaeec3b15452229d",
32 | "rho": "ba217b23c0978d84c4a19be8a9ff64bc1b40ed0d7ecf59521567a5b3a9a1dd48",
33 | "encrypted_data": "cd4100ff9c09ed28102b210ac73aa12d63e90852cebc496c49f57c49982088b49f2e70b99287fdee0aa58aa39913ab405813b999f66783aa2fe637b3cda91ffc0913c30324e2c6ce327e045183e4bffecb",
34 | "blinded_node_id": "03da173ad2aee2f701f17e59fbd16cb708906d69838a5f088e8123fb36e89a2c25"
35 | },
36 | {
37 | "comment": "Notice the next_path_key_override tlv in Carol's payload, indicating that Bob concatenated his route with another blinded route starting at Dave.",
38 | "alias": "Carol",
39 | "node_id": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007",
40 | "tlvs": {
41 | "short_channel_id": "0x0x1105",
42 | "next_path_key_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
43 | "payment_relay": {
44 | "cltv_expiry_delta": 48,
45 | "fee_proportional_millionths": 100,
46 | "fee_base_msat": 500
47 | },
48 | "payment_constraints": {
49 | "max_cltv_expiry": 747969,
50 | "htlc_minimum_msat": 1500
51 | },
52 | "allowed_features": {
53 | "features": []
54 | }
55 | },
56 | "encoded_tlvs": "020800000000000004510821031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f0a0800300000006401f40c06000b69c105dc0e00",
57 | "path_privkey": "0a2aa791ac81265c139237b2b84564f6000b1d4d0e68d4b9cc97c5536c9b61c1",
58 | "path_key": "034e09f450a80c3d252b258aba0a61215bf60dda3b0dc78ffb0736ea1259dfd8a0",
59 | "shared_secret": "dc91516ec6b530a3d641c01f29b36ed4dc29a74e063258278c0eeed50313d9b8",
60 | "rho": "d1e62bae1a8e169da08e6204997b60b1a7971e0f246814c648125c35660f5416",
61 | "encrypted_data": "cc0f16524fd7f8bb0b1d8d40ad71709ef140174c76faa574cac401bb8992fef76c4d004aa485dd599ed1cf2715f57ff62da5aaec5d7b10d59b04d8a9d77e472b9b3ecc2179334e411be22fa4c02b467c7e",
62 | "blinded_node_id": "02e466727716f044290abf91a14a6d90e87487da160c2a3cbd0d465d7a78eb83a7"
63 | },
64 | {
65 | "comment": "Eve creates a Dave -> Eve blinded route using the following session_key.",
66 | "session_key": "0101010101010101010101010101010101010101010101010101010101010101",
67 | "alias": "Dave",
68 | "node_id": "032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991",
69 | "tlvs": {
70 | "padding": "0000000000000000000000000000000000000000000000000000000000000000000000",
71 | "short_channel_id": "0x0x561",
72 | "payment_relay": {
73 | "cltv_expiry_delta": 144,
74 | "fee_proportional_millionths": 250
75 | },
76 | "payment_constraints": {
77 | "max_cltv_expiry": 747921,
78 | "htlc_minimum_msat": 1500
79 | },
80 | "allowed_features": {
81 | "features": []
82 | }
83 | },
84 | "encoded_tlvs": "01230000000000000000000000000000000000000000000000000000000000000000000000020800000000000002310a060090000000fa0c06000b699105dc0e00",
85 | "path_privkey": "0101010101010101010101010101010101010101010101010101010101010101",
86 | "path_key": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
87 | "shared_secret": "dc46f3d1d99a536300f17bc0512376cc24b9502c5d30144674bfaa4b923d9057",
88 | "rho": "393aa55d35c9e207a8f28180b81628a31dff558c84959cdc73130f8c321d6a06",
89 | "encrypted_data": "0fa0a72cff3b64a3d6e1e4903cf8c8b0a17144aeb249dcb86561adee1f679ee8db3e561d9c43815fd4bcebf6f58c546da0cd8a9bf5cebd0d554802f6c0255e28e4a27343f761fe518cd897463187991105",
90 | "blinded_node_id": "036861b366f284f0a11738ffbf7eda46241a8977592878fe3175ae1d1e4754eccf"
91 | },
92 | {
93 | "comment": "Eve is the final recipient, so she included a path_id in her own payload to verify that the route is used when she expects it.",
94 | "alias": "Eve",
95 | "node_id": "02edabbd16b41c8371b92ef2f04c1185b4f03b6dcd52ba9b78d9d7c89c8f221145",
96 | "tlvs": {
97 | "padding": "0000000000000000000000000000000000000000000000000000",
98 | "path_id": "deadbeef",
99 | "payment_constraints": {
100 | "max_cltv_expiry": 747777,
101 | "htlc_minimum_msat": 1500
102 | },
103 | "allowed_features": {
104 | "features": [113]
105 | },
106 | "unknown_tag_65535": "06c1"
107 | },
108 | "encoded_tlvs": "011a00000000000000000000000000000000000000000000000000000604deadbeef0c06000b690105dc0e0f020000000000000000000000000000fdffff0206c1",
109 | "path_privkey": "62e8bcd6b5f7affe29bec4f0515aab2eebd1ce848f4746a9638aa14e3024fb1b",
110 | "path_key": "03e09038ee76e50f444b19abf0a555e8697e035f62937168b80adf0931b31ce52a",
111 | "shared_secret": "352a706b194c2b6d0a04ba1f617383fb816dc5f8f9ac0b60dd19c9ae3b517289",
112 | "rho": "719d0307340b1c68b79865111f0de6e97b093a30bc603cebd1beb9eef116f2d8",
113 | "encrypted_data": "da1a7e5f7881219884beae6ae68971de73bab4c3055d9865b1afb60724a2e4d3f0489ad884f7f3f77149209f0df51efd6b276294a02e3949c7254fbc8b5cab58212d9a78983e1cf86fe218b30c4ca8f6d8",
114 | "blinded_node_id": "021982a48086cb8984427d3727fe35a03d396b234f0701f5249daa12e8105c8dae"
115 | }
116 | ]
117 | },
118 | "route": {
119 | "comment": "This section contains the resulting blinded route, which can then be used inside onion messages or payments.",
120 | "first_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c",
121 | "first_path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766",
122 | "hops": [
123 | {
124 | "blinded_node_id": "03da173ad2aee2f701f17e59fbd16cb708906d69838a5f088e8123fb36e89a2c25",
125 | "encrypted_data": "cd4100ff9c09ed28102b210ac73aa12d63e90852cebc496c49f57c49982088b49f2e70b99287fdee0aa58aa39913ab405813b999f66783aa2fe637b3cda91ffc0913c30324e2c6ce327e045183e4bffecb"
126 | },
127 | {
128 | "blinded_node_id": "02e466727716f044290abf91a14a6d90e87487da160c2a3cbd0d465d7a78eb83a7",
129 | "encrypted_data": "cc0f16524fd7f8bb0b1d8d40ad71709ef140174c76faa574cac401bb8992fef76c4d004aa485dd599ed1cf2715f57ff62da5aaec5d7b10d59b04d8a9d77e472b9b3ecc2179334e411be22fa4c02b467c7e"
130 | },
131 | {
132 | "blinded_node_id": "036861b366f284f0a11738ffbf7eda46241a8977592878fe3175ae1d1e4754eccf",
133 | "encrypted_data": "0fa0a72cff3b64a3d6e1e4903cf8c8b0a17144aeb249dcb86561adee1f679ee8db3e561d9c43815fd4bcebf6f58c546da0cd8a9bf5cebd0d554802f6c0255e28e4a27343f761fe518cd897463187991105"
134 | },
135 | {
136 | "blinded_node_id": "021982a48086cb8984427d3727fe35a03d396b234f0701f5249daa12e8105c8dae",
137 | "encrypted_data": "da1a7e5f7881219884beae6ae68971de73bab4c3055d9865b1afb60724a2e4d3f0489ad884f7f3f77149209f0df51efd6b276294a02e3949c7254fbc8b5cab58212d9a78983e1cf86fe218b30c4ca8f6d8"
138 | }
139 | ]
140 | },
141 | "unblind": {
142 | "comment": "This section contains test data for unblinding the route at each intermediate hop.",
143 | "hops": [
144 | {
145 | "alias": "Bob",
146 | "node_privkey": "4242424242424242424242424242424242424242424242424242424242424242",
147 | "path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766",
148 | "blinded_privkey": "d12fec0332c3e9d224789a17ebd93595f37d37bd8ef8bd3d2e6ce50acb9e554f",
149 | "decrypted_data": "011a0000000000000000000000000000000000000000000000000000020800000000000006c10a0800240000009627100c06000b69e505dc0e00fd023103123456",
150 | "next_path_key": "034e09f450a80c3d252b258aba0a61215bf60dda3b0dc78ffb0736ea1259dfd8a0"
151 | },
152 | {
153 | "alias": "Carol",
154 | "node_privkey": "4343434343434343434343434343434343434343434343434343434343434343",
155 | "path_key": "034e09f450a80c3d252b258aba0a61215bf60dda3b0dc78ffb0736ea1259dfd8a0",
156 | "blinded_privkey": "bfa697fbbc8bbc43ca076e6dd60d306038a32af216b9dc6fc4e59e5ae28823c1",
157 | "decrypted_data": "020800000000000004510821031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f0a0800300000006401f40c06000b69c105dc0e00",
158 | "next_path_key": "03af5ccc91851cb294e3a364ce63347709a08cdffa58c672e9a5c587ddd1bbca60",
159 | "next_path_key_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f"
160 | },
161 | {
162 | "alias": "Dave",
163 | "node_privkey": "4444444444444444444444444444444444444444444444444444444444444444",
164 | "path_key": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
165 | "blinded_privkey": "cebc115c7fce4c295dc396dea6c79115b289b8ceeceea2ed61cf31428d88fc4e",
166 | "decrypted_data": "01230000000000000000000000000000000000000000000000000000000000000000000000020800000000000002310a060090000000fa0c06000b699105dc0e00",
167 | "next_path_key": "03e09038ee76e50f444b19abf0a555e8697e035f62937168b80adf0931b31ce52a"
168 | },
169 | {
170 | "alias": "Eve",
171 | "node_privkey": "4545454545454545454545454545454545454545454545454545454545454545",
172 | "path_key": "03e09038ee76e50f444b19abf0a555e8697e035f62937168b80adf0931b31ce52a",
173 | "blinded_privkey": "ff4e07da8d92838bedd019ce532eb990ed73b574e54a67862a1df81b40c0d2af",
174 | "decrypted_data": "011a00000000000000000000000000000000000000000000000000000604deadbeef0c06000b690105dc0e0f020000000000000000000000000000fdffff0206c1",
175 | "next_path_key": "038fc6859a402b96ce4998c537c823d6ab94d1598fca02c788ba5dd79fbae83589"
176 | }
177 | ]
178 | }
179 | }
180 |
--------------------------------------------------------------------------------
/bolt07/extended-queries.json:
--------------------------------------------------------------------------------
1 | [
2 | {
3 | "hex": "01070f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206000186a0000005dc",
4 | "msg": {
5 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
6 | "firstBlockNum": 100000,
7 | "numberOfBlocks": 1500,
8 | "tlvStream": {
9 | "records": [],
10 | "unknown": []
11 | },
12 | "type": "QueryChannelRange"
13 | }
14 | },
15 | {
16 | "hex": "01070f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206000088b800000064010103",
17 | "msg": {
18 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
19 | "firstBlockNum": 35000,
20 | "numberOfBlocks": 100,
21 | "tlvStream": {
22 | "records": [
23 | "WANT_TIMESTAMPS | WANT_CHECKSUMS"
24 | ],
25 | "unknown": []
26 | },
27 | "type": "QueryChannelRange"
28 | }
29 | },
30 | {
31 | "hex": "01080f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206000b8a06000005dc01001900000000000000008e0000000000003c69000000000045a6c4",
32 | "msg": {
33 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
34 | "complete": 1,
35 | "firstBlockNum": 756230,
36 | "numberOfBlocks": 1500,
37 | "shortChannelIds": {
38 | "array": [
39 | "0x0x142",
40 | "0x0x15465",
41 | "0x69x42692"
42 | ],
43 | "encoding": "UNCOMPRESSED"
44 | },
45 | "type": "ReplyChannelRange"
46 | }
47 | },
48 | {
49 | "hex": "01080f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206000006400000006e01001601789c636000833e08659309a65878be010010a9023a",
50 | "msg": {
51 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
52 | "complete": 1,
53 | "firstBlockNum": 1600,
54 | "numberOfBlocks": 110,
55 | "shortChannelIds": {
56 | "array": [
57 | "0x0x142",
58 | "0x0x15465",
59 | "0x4x3318"
60 | ],
61 | "encoding": "COMPRESSED_ZLIB"
62 | },
63 | "type": "ReplyChannelRange"
64 | }
65 | },
66 | {
67 | "hex": "01080f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e22060001ddde000005dc01001900000000000000304300000000000778d6000000000046e1c1011900000282c1000e77c5000778ad00490ab00000b57800955bff031800000457000008ae00000d050000115c000015b300001a0a",
68 | "msg": {
69 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
70 | "checksums": {
71 | "checksums": [
72 | {
73 | "checksum1": 1111,
74 | "checksum2": 2222
75 | },
76 | {
77 | "checksum1": 3333,
78 | "checksum2": 4444
79 | },
80 | {
81 | "checksum1": 5555,
82 | "checksum2": 6666
83 | }
84 | ]
85 | },
86 | "complete": 1,
87 | "firstBlockNum": 122334,
88 | "numberOfBlocks": 1500,
89 | "shortChannelIds": {
90 | "array": [
91 | "0x0x12355",
92 | "0x7x30934",
93 | "0x70x57793"
94 | ],
95 | "encoding": "UNCOMPRESSED"
96 | },
97 | "timestamps": {
98 | "encoding": "UNCOMPRESSED",
99 | "timestamps": [
100 | {
101 | "timestamp1": 164545,
102 | "timestamp2": 948165
103 | },
104 | {
105 | "timestamp1": 489645,
106 | "timestamp2": 4786864
107 | },
108 | {
109 | "timestamp1": 46456,
110 | "timestamp2": 9788415
111 | }
112 | ]
113 | },
114 | "type": "ReplyChannelRange"
115 | }
116 | },
117 | {
118 | "hex": "01080f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e22060001ddde000005dc01001801789c63600001036730c55e710d4cbb3d3c080017c303b1012201789c63606a3ac8c0577e9481bd622d8327d7060686ad150c53a3ff0300554707db031800000457000008ae00000d050000115c000015b300001a0a",
119 | "msg": {
120 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
121 | "checksums": {
122 | "checksums": [
123 | {
124 | "checksum1": 1111,
125 | "checksum2": 2222
126 | },
127 | {
128 | "checksum1": 3333,
129 | "checksum2": 4444
130 | },
131 | {
132 | "checksum1": 5555,
133 | "checksum2": 6666
134 | }
135 | ]
136 | },
137 | "complete": 1,
138 | "firstBlockNum": 122334,
139 | "numberOfBlocks": 1500,
140 | "shortChannelIds": {
141 | "array": [
142 | "0x0x12355",
143 | "0x7x30934",
144 | "0x70x57793"
145 | ],
146 | "encoding": "COMPRESSED_ZLIB"
147 | },
148 | "timestamps": {
149 | "encoding": "COMPRESSED_ZLIB",
150 | "timestamps": [
151 | {
152 | "timestamp1": 164545,
153 | "timestamp2": 948165
154 | },
155 | {
156 | "timestamp1": 489645,
157 | "timestamp2": 4786864
158 | },
159 | {
160 | "timestamp1": 46456,
161 | "timestamp2": 9788415
162 | }
163 | ]
164 | },
165 | "type": "ReplyChannelRange"
166 | }
167 | },
168 | {
169 | "hex": "01050f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206001900000000000000008e0000000000003c69000000000045a6c4",
170 | "msg": {
171 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
172 | "shortChannelIds": {
173 | "array": [
174 | "0x0x142",
175 | "0x0x15465",
176 | "0x69x42692"
177 | ],
178 | "encoding": "UNCOMPRESSED"
179 | },
180 | "tlvStream": {
181 | "records": [],
182 | "unknown": []
183 | },
184 | "type": "QueryShortChannelIds"
185 | }
186 | },
187 | {
188 | "hex": "01050f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206001801789c63600001c12b608a69e73e30edbaec0800203b040e",
189 | "msg": {
190 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
191 | "shortChannelIds": {
192 | "array": [
193 | "0x0x4564",
194 | "0x2x47550",
195 | "0x69x42692"
196 | ],
197 | "encoding": "COMPRESSED_ZLIB"
198 | },
199 | "tlvStream": {
200 | "records": [],
201 | "unknown": []
202 | },
203 | "type": "QueryShortChannelIds"
204 | }
205 | },
206 | {
207 | "hex": "01050f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e22060019000000000000002fc80000000000003cc4000000000045a6c4010c01789c6364620100000e0008",
208 | "msg": {
209 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
210 | "shortChannelIds": {
211 | "array": [
212 | "0x0x12232",
213 | "0x0x15556",
214 | "0x69x42692"
215 | ],
216 | "encoding": "UNCOMPRESSED"
217 | },
218 | "tlvStream": {
219 | "records": [
220 | {
221 | "array": [
222 | 1,
223 | 2,
224 | 4
225 | ],
226 | "encoding": "COMPRESSED_ZLIB"
227 | }
228 | ],
229 | "unknown": []
230 | },
231 | "type": "QueryShortChannelIds"
232 | }
233 | },
234 | {
235 | "hex": "01050f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206001801789c63600001f30a30c5b0cd144cb92e3b020017c6034a010c01789c6364620100000e0008",
236 | "msg": {
237 | "chainHash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
238 | "shortChannelIds": {
239 | "array": [
240 | "0x0x14200",
241 | "0x0x46645",
242 | "0x69x42692"
243 | ],
244 | "encoding": "COMPRESSED_ZLIB"
245 | },
246 | "tlvStream": {
247 | "records": [
248 | {
249 | "array": [
250 | 1,
251 | 2,
252 | 4
253 | ],
254 | "encoding": "COMPRESSED_ZLIB"
255 | }
256 | ],
257 | "unknown": []
258 | },
259 | "type": "QueryShortChannelIds"
260 | }
261 | }
262 | ]
263 |
264 |
--------------------------------------------------------------------------------
/bolt12/format-string-test.json:
--------------------------------------------------------------------------------
1 | [
2 | {
3 | "comment": "A complete string is valid",
4 | "valid": true,
5 | "string": "lno1pqps7sjqpgtyzm3qv4uxzmtsd3jjqer9wd3hy6tsw35k7msjzfpy7nz5yqcnygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg"
6 | },
7 | {
8 | "comment": "Uppercase is valid",
9 | "valid": true,
10 | "string": "LNO1PQPS7SJQPGTYZM3QV4UXZMTSD3JJQER9WD3HY6TSW35K7MSJZFPY7NZ5YQCNYGRFDEJ82UM5WF5K2UCKYYPWA3EYT44H6TXTXQUQH7LZ5DJGE4AFGFJN7K4RGRKUAG0JSD5XVXG"
11 | },
12 | {
13 | "comment": "+ can join anywhere",
14 | "valid": true,
15 | "string": "l+no1pqps7sjqpgtyzm3qv4uxzmtsd3jjqer9wd3hy6tsw35k7msjzfpy7nz5yqcnygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg"
16 | },
17 | {
18 | "comment": "Multiple + can join",
19 | "valid": true,
20 | "string": "lno1pqps7sjqpgt+yzm3qv4uxzmtsd3jjqer9wd3hy6tsw3+5k7msjzfpy7nz5yqcn+ygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd+5xvxg"
21 | },
22 | {
23 | "comment": "+ can be followed by whitespace",
24 | "valid": true,
25 | "string": "lno1pqps7sjqpgt+ yzm3qv4uxzmtsd3jjqer9wd3hy6tsw3+ 5k7msjzfpy7nz5yqcn+\nygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd+\r\n 5xvxg"
26 | },
27 | {
28 | "comment": "+ can be followed by whitespace, UPPERCASE",
29 | "valid": true,
30 | "string": "LNO1PQPS7SJQPGT+ YZM3QV4UXZMTSD3JJQER9WD3HY6TSW3+ 5K7MSJZFPY7NZ5YQCN+\nYGRFDEJ82UM5WF5K2UCKYYPWA3EYT44H6TXTXQUQH7LZ5DJGE4AFGFJN7K4RGRKUAG0JSD+\r\n 5XVXG"
31 | },
32 | {
33 | "comment": "Mixed case is invalid",
34 | "valid": false,
35 | "string": "LnO1PqPs7sJqPgTyZm3qV4UxZmTsD3JjQeR9Wd3hY6TsW35k7mSjZfPy7nZ5YqCnYgRfDeJ82uM5Wf5k2uCkYyPwA3EyT44h6tXtXqUqH7Lz5dJgE4AfGfJn7k4rGrKuAg0jSd5xVxG"
36 | },
37 | {
38 | "comment": "+ must be surrounded by bech32 characters",
39 | "valid": false,
40 | "string": "lno1pqps7sjqpgtyzm3qv4uxzmtsd3jjqer9wd3hy6tsw35k7msjzfpy7nz5yqcnygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg+"
41 | },
42 | {
43 | "comment": "+ must be surrounded by bech32 characters",
44 | "valid": false,
45 | "string": "lno1pqps7sjqpgtyzm3qv4uxzmtsd3jjqer9wd3hy6tsw35k7msjzfpy7nz5yqcnygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg+ "
46 | },
47 | {
48 | "comment": "+ must be surrounded by bech32 characters",
49 | "valid": false,
50 | "string": "+lno1pqps7sjqpgtyzm3qv4uxzmtsd3jjqer9wd3hy6tsw35k7msjzfpy7nz5yqcnygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg"
51 | },
52 | {
53 | "comment": "+ must be surrounded by bech32 characters",
54 | "valid": false,
55 | "string": "+ lno1pqps7sjqpgtyzm3qv4uxzmtsd3jjqer9wd3hy6tsw35k7msjzfpy7nz5yqcnygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg"
56 | },
57 | {
58 | "comment": "+ must be surrounded by bech32 characters",
59 | "valid": false,
60 | "string": "ln++o1pqps7sjqpgtyzm3qv4uxzmtsd3jjqer9wd3hy6tsw35k7msjzfpy7nz5yqcnygrfdej82um5wf5k2uckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg"
61 | }
62 | ]
63 |
--------------------------------------------------------------------------------
/bolt12/offers-test.json:
--------------------------------------------------------------------------------
1 | [
2 | {
3 | "description": "Minimal bolt12 offer",
4 | "valid": true,
5 | "bolt12": "lno1zcss9mk8y3wkklfvevcrszlmu23kfrxh49px20665dqwmn4p72pksese",
6 | "fields": [
7 | {
8 | "type": 22,
9 | "length": 33,
10 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
11 | }
12 | ]
13 | },
14 | {
15 | "description": "with description (but no amount)",
16 | "valid": true,
17 | "bolt12": "lno1pgx9getnwss8vetrw3hhyuckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg",
18 | "field info": "description is 'Test vectors'",
19 | "fields": [
20 | {
21 | "type": 10,
22 | "length": 12,
23 | "hex": "5465737420766563746f7273"
24 | },
25 | {
26 | "type": 22,
27 | "length": 33,
28 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
29 | }
30 | ]
31 | },
32 | {
33 | "description": "for testnet",
34 | "valid": true,
35 | "bolt12": "lno1qgsyxjtl6luzd9t3pr62xr7eemp6awnejusgf6gw45q75vcfqqqqqqq2p32x2um5ypmx2cm5dae8x93pqthvwfzadd7jejes8q9lhc4rvjxd022zv5l44g6qah82ru5rdpnpj",
36 | "field info": "chains[0] is testnet",
37 | "fields": [
38 | {
39 | "type": 2,
40 | "length": 32,
41 | "hex": "43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000"
42 | },
43 | {
44 | "type": 10,
45 | "length": 12,
46 | "hex": "5465737420766563746f7273"
47 | },
48 | {
49 | "type": 22,
50 | "length": 33,
51 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
52 | }
53 | ]
54 | },
55 | {
56 | "description": "for bitcoin (redundant)",
57 | "valid": true,
58 | "bolt12": "lno1qgsxlc5vp2m0rvmjcxn2y34wv0m5lyc7sdj7zksgn35dvxgqqqqqqqq2p32x2um5ypmx2cm5dae8x93pqthvwfzadd7jejes8q9lhc4rvjxd022zv5l44g6qah82ru5rdpnpj",
59 | "field info": "chains[0] is bitcoin",
60 | "fields": [
61 | {
62 | "type": 2,
63 | "length": 32,
64 | "hex": "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000"
65 | },
66 | {
67 | "type": 10,
68 | "length": 12,
69 | "hex": "5465737420766563746f7273"
70 | },
71 | {
72 | "type": 22,
73 | "length": 33,
74 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
75 | }
76 | ]
77 | },
78 | {
79 | "description": "for bitcoin or liquidv1",
80 | "valid": true,
81 | "bolt12": "lno1qfqpge38tqmzyrdjj3x2qkdr5y80dlfw56ztq6yd9sme995g3gsxqqm0u2xq4dh3kdevrf4zg6hx8a60jv0gxe0ptgyfc6xkryqqqqqqqq9qc4r9wd6zqan9vd6x7unnzcss9mk8y3wkklfvevcrszlmu23kfrxh49px20665dqwmn4p72pksese",
82 | "field info": "chains[0] is liquidv1, chains[1] is bitcoin",
83 | "fields": [
84 | {
85 | "type": 2,
86 | "length": 64,
87 | "hex": "1466275836220db2944ca059a3a10ef6fd2ea684b0688d2c379296888a2060036fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000"
88 | },
89 | {
90 | "type": 10,
91 | "length": 12,
92 | "hex": "5465737420766563746f7273"
93 | },
94 | {
95 | "type": 22,
96 | "length": 33,
97 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
98 | }
99 | ]
100 | },
101 | {
102 | "description": "with metadata",
103 | "valid": true,
104 | "bolt12": "lno1qsgqqqqqqqqqqqqqqqqqqqqqqqqqqzsv23jhxapqwejkxar0wfe3vggzamrjghtt05kvkvpcp0a79gmy3nt6jsn98ad2xs8de6sl9qmgvcvs",
105 | "field info": "metadata is 16 zero bytes",
106 | "fields": [
107 | {
108 | "type": 4,
109 | "length": 16,
110 | "hex": "00000000000000000000000000000000"
111 | },
112 | {
113 | "type": 10,
114 | "length": 12,
115 | "hex": "5465737420766563746f7273"
116 | },
117 | {
118 | "type": 22,
119 | "length": 33,
120 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
121 | }
122 | ]
123 | },
124 | {
125 | "description": "with amount",
126 | "valid": true,
127 | "bolt12": "lno1pqpzwyq2p32x2um5ypmx2cm5dae8x93pqthvwfzadd7jejes8q9lhc4rvjxd022zv5l44g6qah82ru5rdpnpj",
128 | "field info": "amount is 10000msat",
129 | "fields": [
130 | {
131 | "type": 8,
132 | "length": 2,
133 | "hex": "2710"
134 | },
135 | {
136 | "type": 10,
137 | "length": 12,
138 | "hex": "5465737420766563746f7273"
139 | },
140 | {
141 | "type": 22,
142 | "length": 33,
143 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
144 | }
145 | ]
146 | },
147 | {
148 | "description": "with currency",
149 | "valid": true,
150 | "bolt12": "lno1qcp4256ypqpzwyq2p32x2um5ypmx2cm5dae8x93pqthvwfzadd7jejes8q9lhc4rvjxd022zv5l44g6qah82ru5rdpnpj",
151 | "field info": "amount is USD $100.00",
152 | "fields": [
153 | {
154 | "type": 6,
155 | "length": 3,
156 | "hex": "555344"
157 | },
158 | {
159 | "type": 8,
160 | "length": 2,
161 | "hex": "2710"
162 | },
163 | {
164 | "type": 10,
165 | "length": 12,
166 | "hex": "5465737420766563746f7273"
167 | },
168 | {
169 | "type": 22,
170 | "length": 33,
171 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
172 | }
173 | ]
174 | },
175 | {
176 | "description": "with expiry",
177 | "valid": true,
178 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucwq3ay997czcss9mk8y3wkklfvevcrszlmu23kfrxh49px20665dqwmn4p72pksese",
179 | "field info": "expiry is 2035-01-01",
180 | "fields": [
181 | {
182 | "type": 10,
183 | "length": 12,
184 | "hex": "5465737420766563746f7273"
185 | },
186 | {
187 | "type": 14,
188 | "length": 4,
189 | "hex": "7a4297d8"
190 | },
191 | {
192 | "type": 22,
193 | "length": 33,
194 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
195 | }
196 | ]
197 | },
198 | {
199 | "description": "with issuer",
200 | "valid": true,
201 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucjy358garswvaz7tmzdak8gvfj9ehhyeeqgf85c4p3xgsxjmnyw4ehgunfv4e3vggzamrjghtt05kvkvpcp0a79gmy3nt6jsn98ad2xs8de6sl9qmgvcvs",
202 | "field info": "issuer is 'https://bolt12.org BOLT12 industries'",
203 | "fields": [
204 | {
205 | "type": 10,
206 | "length": 12,
207 | "hex": "5465737420766563746f7273"
208 | },
209 | {
210 | "type": 18,
211 | "length": 36,
212 | "hex": "68747470733a2f2f626f6c7431322e6f726720424f4c54313220696e6475737472696573"
213 | },
214 | {
215 | "type": 22,
216 | "length": 33,
217 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
218 | }
219 | ]
220 | },
221 | {
222 | "description": "with quantity",
223 | "valid": true,
224 | "bolt12": "lno1pgx9getnwss8vetrw3hhyuc5qyz3vggzamrjghtt05kvkvpcp0a79gmy3nt6jsn98ad2xs8de6sl9qmgvcvs",
225 | "field info": "quantity_max is 5",
226 | "fields": [
227 | {
228 | "type": 10,
229 | "length": 12,
230 | "hex": "5465737420766563746f7273"
231 | },
232 | {
233 | "type": 20,
234 | "length": 1,
235 | "hex": "05"
236 | },
237 | {
238 | "type": 22,
239 | "length": 33,
240 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
241 | }
242 | ]
243 | },
244 | {
245 | "description": "with unlimited (or unknown) quantity",
246 | "valid": true,
247 | "bolt12": "lno1pgx9getnwss8vetrw3hhyuc5qqtzzqhwcuj966ma9n9nqwqtl032xeyv6755yeflt235pmww58egx6rxry",
248 | "field info": "quantity_max is unknown/unlimited",
249 | "fields": [
250 | {
251 | "type": 10,
252 | "length": 12,
253 | "hex": "5465737420766563746f7273"
254 | },
255 | {
256 | "type": 20,
257 | "length": 0,
258 | "hex": ""
259 | },
260 | {
261 | "type": 22,
262 | "length": 33,
263 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
264 | }
265 | ]
266 | },
267 | {
268 | "description": "with single quantity (weird but valid)",
269 | "valid": true,
270 | "bolt12": "lno1pgx9getnwss8vetrw3hhyuc5qyq3vggzamrjghtt05kvkvpcp0a79gmy3nt6jsn98ad2xs8de6sl9qmgvcvs",
271 | "field info": "quantity_max is 1",
272 | "fields": [
273 | {
274 | "type": 10,
275 | "length": 12,
276 | "hex": "5465737420766563746f7273"
277 | },
278 | {
279 | "type": 20,
280 | "length": 1,
281 | "hex": "01"
282 | },
283 | {
284 | "type": 22,
285 | "length": 33,
286 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
287 | }
288 | ]
289 | },
290 | {
291 | "description": "with feature",
292 | "valid": true,
293 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucvp5yqqqqqqqqqqqqqqqqqqqqkyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg",
294 | "field info": "feature bit 99 set",
295 | "fields": [
296 | {
297 | "type": 10,
298 | "length": 12,
299 | "hex": "5465737420766563746f7273"
300 | },
301 | {
302 | "type": 12,
303 | "length": 13,
304 | "hex": "08000000000000000000000000"
305 | },
306 | {
307 | "type": 22,
308 | "length": 33,
309 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
310 | }
311 | ]
312 | },
313 | {
314 | "description": "with blinded path via Bob (0x424242...), path_key 020202...",
315 | "valid": true,
316 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucs5ypjgef743p5fzqq9nqxh0ah7y87rzv3ud0eleps9kl2d5348hq2k8qzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgqpqqqqqqqqqqqqqqqqqqqqqqqqqqqzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqqzq3zyg3zyg3zyg3vggzamrjghtt05kvkvpcp0a79gmy3nt6jsn98ad2xs8de6sl9qmgvcvs",
317 | "field info": "path is [id=02020202..., enc=0x00*16], [id=02020202..., enc=0x11*8]",
318 | "fields": [
319 | {
320 | "type": 10,
321 | "length": 12,
322 | "hex": "5465737420766563746f7273"
323 | },
324 | {
325 | "type": 16,
326 | "length": 161,
327 | "hex": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c0202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020200100000000000000000000000000000000002020202020202020202020202020202020202020202020202020202020202020200081111111111111111"
328 | },
329 | {
330 | "type": 22,
331 | "length": 33,
332 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
333 | }
334 | ]
335 | },
336 | {
337 | "description": "same, with blinded path first_node_id using sciddir",
338 | "valid": true,
339 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucs3yqqqqqqqqqqqqp2qgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqqyqqqqqqqqqqqqqqqqqqqqqqqqqqqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqqgzyg3zyg3zyg3z93pqthvwfzadd7jejes8q9lhc4rvjxd022zv5l44g6qah82ru5rdpnpj",
340 | "field info": "short_channel_id is 0x0x42, direction is 0",
341 | "fields": [
342 | {
343 | "type": 10,
344 | "length": 12,
345 | "hex": "5465737420766563746f7273"
346 | },
347 | {
348 | "type": 16,
349 | "length": 137,
350 | "hex": "00000000000000002a0202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020200100000000000000000000000000000000002020202020202020202020202020202020202020202020202020202020202020200081111111111111111"
351 | },
352 | {
353 | "type": 22,
354 | "length": 33,
355 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
356 | }
357 | ]
358 | },
359 | {
360 | "description": "with no issuer_id and blinded path via Bob (0x424242...), path_key 020202...",
361 | "valid": true,
362 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucs5ypjgef743p5fzqq9nqxh0ah7y87rzv3ud0eleps9kl2d5348hq2k8qzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgqpqqqqqqqqqqqqqqqqqqqqqqqqqqqzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqqzq3zyg3zyg3zygs",
363 | "field info": "path is [id=02020202..., enc=0x00*16], [id=02020202..., enc=0x11*8]",
364 | "fields": [
365 | {
366 | "type": 10,
367 | "length": 12,
368 | "hex": "5465737420766563746f7273"
369 | },
370 | {
371 | "type": 16,
372 | "length": 161,
373 | "hex": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c0202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020200100000000000000000000000000000000002020202020202020202020202020202020202020202020202020202020202020200081111111111111111"
374 | }
375 | ]
376 | },
377 | {
378 | "description": "... and with second blinded path via 1x2x3 (direction 1), path_key 020202...",
379 | "valid": true,
380 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucsl5qj5qeyv5l2cs6y3qqzesrth7mlzrlp3xg7xhulusczm04x6g6nms9trspqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqqsqqqqqqqqqqqqqqqqqqqqqqqqqqpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsqpqg3zyg3zyg3zygpqqqqzqqqqgqqxqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqqgqqqqqqqqqqqqqqqqqqqqqqqqqqqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgqqsg3zyg3zyg3zygtzzqhwcuj966ma9n9nqwqtl032xeyv6755yeflt235pmww58egx6rxry",
381 | "field info": "path is [id=02020202..., enc=0x00*16], [id=02020202..., enc=0x22*8]",
382 | "fields": [
383 | {
384 | "type": 10,
385 | "length": 12,
386 | "hex": "5465737420766563746f7273"
387 | },
388 | {
389 | "type": 16,
390 | "length": 298,
391 | "hex": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c02020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202001000000000000000000000000000000000020202020202020202020202020202020202020202020202020202020202020202000811111111111111110100000100000200030202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020200100000000000000000000000000000000002020202020202020202020202020202020202020202020202020202020202020200082222222222222222"
392 | },
393 | {
394 | "type": 22,
395 | "length": 33,
396 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
397 | }
398 | ]
399 | },
400 | {
401 | "description": "unknown odd field",
402 | "valid": true,
403 | "bolt12": "lno1pgx9getnwss8vetrw3hhyuckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxfppf5x2mrvdamk7unvvs",
404 | "field info": "type 33 is 'helloworld'",
405 | "fields": [
406 | {
407 | "type": 10,
408 | "length": 12,
409 | "hex": "5465737420766563746f7273"
410 | },
411 | {
412 | "type": 22,
413 | "length": 33,
414 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
415 | },
416 | {
417 | "type": 33,
418 | "length": 10,
419 | "hex": "68656c6c6f776f726c64"
420 | }
421 | ]
422 | },
423 | {
424 | "description": "unknown odd experimental field",
425 | "valid": true,
426 | "bolt12": "lno1pgx9getnwss8vetrw3hhyuckyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvx078wdv5gg2dpjkcmr0wahhymry",
427 | "field info": "type 1000000033 is 'helloworld'",
428 | "fields": [
429 | {
430 | "type": 10,
431 | "length": 12,
432 | "hex": "5465737420766563746f7273"
433 | },
434 | {
435 | "type": 22,
436 | "length": 33,
437 | "hex": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619"
438 | },
439 | {
440 | "type": 1000000033,
441 | "length": 10,
442 | "hex": "68656c6c6f776f726c64"
443 | }
444 | ]
445 | },
446 | {
447 | "description": "Malformed: fields out of order",
448 | "valid": false,
449 | "bolt12": "lno1zcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszpgz5znzfgdzs"
450 | },
451 | {
452 | "description": "Malformed: unknown even TLV type 78",
453 | "valid": false,
454 | "bolt12": "lno1pgz5znzfgdz3vggzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpysgr0u2xq4dh3kdevrf4zg6hx8a60jv0gxe0ptgyfc6xkryqqqqqqqq"
455 | },
456 | {
457 | "description": "Malformed: empty",
458 | "valid": false,
459 | "bolt12": "lno1"
460 | },
461 | {
462 | "description": "Malformed: truncated at type",
463 | "valid": false,
464 | "bolt12": "lno1pg"
465 | },
466 | {
467 | "description": "Malformed: truncated in length",
468 | "valid": false,
469 | "bolt12": "lno1pt7s"
470 | },
471 | {
472 | "description": "Malformed: truncated after length",
473 | "valid": false,
474 | "bolt12": "lno1pgpq"
475 | },
476 | {
477 | "description": "Malformed: truncated in description",
478 | "valid": false,
479 | "bolt12": "lno1pgpyz"
480 | },
481 | {
482 | "description": "Malformed: invalid offer_chains length",
483 | "valid": false,
484 | "bolt12": "lno1qgqszzs9g9xyjs69zcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
485 | },
486 | {
487 | "description": "Malformed: truncated currency UTF-8",
488 | "valid": false,
489 | "bolt12": "lno1qcqcqzs9g9xyjs69zcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
490 | },
491 | {
492 | "description": "Malformed: invalid currency UTF-8",
493 | "valid": false,
494 | "bolt12": "lno1qcpgqsg2q4q5cj2rg5tzzqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqg"
495 | },
496 | {
497 | "description": "Malformed: truncated description UTF-8",
498 | "valid": false,
499 | "bolt12": "lno1pgqcq93pqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqy"
500 | },
501 | {
502 | "description": "Malformed: invalid description UTF-8",
503 | "valid": false,
504 | "bolt12": "lno1pgpgqsgkyypqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqs"
505 | },
506 | {
507 | "description": "Malformed: truncated offer_paths",
508 | "valid": false,
509 | "bolt12": "lno1pgz5znzfgdz3qqgpzcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
510 | },
511 | {
512 | "description": "Malformed: zero num_hops in blinded_path",
513 | "valid": false,
514 | "bolt12": "lno1pgz5znzfgdz3qqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsqzcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
515 | },
516 | {
517 | "description": "Malformed: truncated onionmsg_hop in blinded_path",
518 | "valid": false,
519 | "bolt12": "lno1pgz5znzfgdz3qqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqspqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqgkyypqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqs"
520 | },
521 | {
522 | "description": "Malformed: bad first_node_id in blinded_path",
523 | "valid": false,
524 | "bolt12": "lno1pgz5znzfgdz3qqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqspqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqgqzcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
525 | },
526 | {
527 | "description": "Malformed: bad path_key in blinded_path",
528 | "valid": false,
529 | "bolt12": "lno1pgz5znzfgdz3qqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcpqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqgqzcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
530 | },
531 | {
532 | "description": "Malformed: bad blinded_node_id in onionmsg_hop",
533 | "valid": false,
534 | "bolt12": "lno1pgz5znzfgdz3qqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqspqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqgqzcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
535 | },
536 | {
537 | "description": "Malformed: truncated issuer UTF-8",
538 | "valid": false,
539 | "bolt12": "lno1pgz5znzfgdz3yqvqzcssyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsz"
540 | },
541 | {
542 | "description": "Malformed: invalid issuer UTF-8",
543 | "valid": false,
544 | "bolt12": "lno1pgz5znzfgdz3yq5qgytzzqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqg"
545 | },
546 | {
547 | "description": "Malformed: invalid offer_issuer_id",
548 | "valid": false,
549 | "bolt12": "lno1pgz5znzfgdz3vggzqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvpsxqcrqvps"
550 | },
551 | {
552 | "description": "Contains type >= 80",
553 | "valid": false,
554 | "bolt12": "lno1pgz5znzfgdz3vggzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgp9qgr0u2xq4dh3kdevrf4zg6hx8a60jv0gxe0ptgyfc6xkryqqqqqqqq"
555 | },
556 | {
557 | "description": "Contains type > 1999999999",
558 | "valid": false,
559 | "bolt12": "lno1pgz5znzfgdz3vggzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgp06ae4jsq9qgr0u2xq4dh3kdevrf4zg6hx8a60jv0gxe0ptgyfc6xkryqqqqqqqq"
560 | },
561 | {
562 | "description": "Contains unknown even type (1000000002)",
563 | "valid": false,
564 | "bolt12": "lno1pgz5znzfgdz3vggzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgp06wu6egp9qgr0u2xq4dh3kdevrf4zg6hx8a60jv0gxe0ptgyfc6xkryqqqqqqqq"
565 | },
566 | {
567 | "description": "Contains unknown feature 122",
568 | "valid": false,
569 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucvzqzqqqqqqqqqqqqqqqqqqqqqqqqpvggzamrjghtt05kvkvpcp0a79gmy3nt6jsn98ad2xs8de6sl9qmgvcvs"
570 | },
571 | {
572 | "description": "Missing offer_description, but has offer_amount",
573 | "valid": false,
574 | "bolt12": "lno1pqpzwyqkyypwa3eyt44h6txtxquqh7lz5djge4afgfjn7k4rgrkuag0jsd5xvxg"
575 | },
576 | {
577 | "description": "Missing offer_issuer_id and no offer_path",
578 | "valid": false,
579 | "bolt12": "lno1pgx9getnwss8vetrw3hhyuc"
580 | },
581 | {
582 | "description": "Second offer_path is empty",
583 | "valid": false,
584 | "bolt12": "lno1pgx9getnwss8vetrw3hhyucsespjgef743p5fzqq9nqxh0ah7y87rzv3ud0eleps9kl2d5348hq2k8qzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgqpqqqqqqqqqqqqqqqqqqqqqqqqqqqzqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqqzq3zyg3zyg3zygszqqqqyqqqqsqqvpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsq"
585 | }
586 | ]
587 |
--------------------------------------------------------------------------------
/bolt12/signature-test.json:
--------------------------------------------------------------------------------
1 | [
2 | {
3 | "comment": "Simple n1 test, tlv1 = 1000",
4 | "tlv": "n1",
5 | "first-tlv": "010203e8",
6 | "leaves": [
7 | {
8 | "H(`LnLeaf`,010203e8)": "67a2a995433890d8fe0c18a1765ad19e98f1fcfeff14c13a45bbc80964a78cf7",
9 | "H(`LnNonce`|first-tlv,tlv1-type)": "255a95f5b6b3c6997e2838dc4d9348807fb6da8eb7bbc02d30662d144718b6aa",
10 | "H(`LnBranch`,leaf+nonce)": "b013756c8fee86503a0b4abdab4cddeb1af5d344ca6fc2fa8b6c08938caa6f93"
11 | }
12 | ],
13 | "branches": [],
14 | "merkle": "b013756c8fee86503a0b4abdab4cddeb1af5d344ca6fc2fa8b6c08938caa6f93"
15 | },
16 | {
17 | "comment": "n1 test, tlv1 = 1000, tlv2 = 1x2x3",
18 | "tlv": "n1",
19 | "first-tlv": "010203e8",
20 | "leaves": [
21 | {
22 | "H(`LnLeaf`,010203e8)": "67a2a995433890d8fe0c18a1765ad19e98f1fcfeff14c13a45bbc80964a78cf7",
23 | "H(`LnNonce`|first-tlv,tlv1-type)": "255a95f5b6b3c6997e2838dc4d9348807fb6da8eb7bbc02d30662d144718b6aa",
24 | "H(`LnBranch`,leaf+nonce)": "b013756c8fee86503a0b4abdab4cddeb1af5d344ca6fc2fa8b6c08938caa6f93"
25 | },
26 | {
27 | "H(`LnLeaf`,02080000010000020003)": "cc04567fcbff60d4de87afe5142de16b7401531300554838b2d1117341a4ea8d",
28 | "H(`LnNonce`|first-tlv,tlv2-type)": "12bc15565410d8e3251a6fb1c53a2d360f39a9f65afb8403ef875016e34ff678",
29 | "H(`LnBranch`,leaf+nonce)": "19d6ecfa3be88d29c30e56167f58526d7695dfac9cb95e1256deb222c92db4d0"
30 | }
31 | ],
32 | "branches": [
33 | {
34 | "desc": "1: tlv1+nonce and tlv2+nonce",
35 | "H(`LnBranch`,19d6ecfa3be88d29c30e56167f58526d7695dfac9cb95e1256deb222c92db4d0b013756c8fee86503a0b4abdab4cddeb1af5d344ca6fc2fa8b6c08938caa6f93)": "c3774abbf4815aa54ccaa026bff6581f01f3be5fe814c620a252534f434bc0d1"
36 | }
37 | ],
38 | "merkle": "c3774abbf4815aa54ccaa026bff6581f01f3be5fe814c620a252534f434bc0d1"
39 | },
40 | {
41 | "comment": "n1 test, tlv1 = 1000, tlv2 = 1x2x3, tlv3 = 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518, 1, 2",
42 | "tlv": "n1",
43 | "first-tlv": "010203e8",
44 | "leaves": [
45 | {
46 | "H(`LnLeaf`,010203e8)": "67a2a995433890d8fe0c18a1765ad19e98f1fcfeff14c13a45bbc80964a78cf7",
47 | "H(`LnNonce`|first-tlv,1)": "255a95f5b6b3c6997e2838dc4d9348807fb6da8eb7bbc02d30662d144718b6aa",
48 | "H(`LnBranch`,leaf+nonce)": "b013756c8fee86503a0b4abdab4cddeb1af5d344ca6fc2fa8b6c08938caa6f93"
49 | },
50 | {
51 | "H(`LnLeaf`,02080000010000020003)": "cc04567fcbff60d4de87afe5142de16b7401531300554838b2d1117341a4ea8d",
52 | "H(`LnNonce`|first-tlv,2)": "12bc15565410d8e3251a6fb1c53a2d360f39a9f65afb8403ef875016e34ff678",
53 | "H(`LnBranch`,leaf+nonce)": "19d6ecfa3be88d29c30e56167f58526d7695dfac9cb95e1256deb222c92db4d0"
54 | },
55 | {
56 | "H(`LnLeaf`,03310266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c0351800000000000000010000000000000002)": "47da319b36d61a006e0dbcf6642fe4c822c33a6131af67dfa9293b089c5cbd27",
57 | "H(`LnNonce`|first-tlv,3)": "068cf6e9d2db9258a6c1d3304a8f2e9d4d046ea711664c9a96960234f707a084",
58 | "H(`LnBranch`,leaf+nonce)": "7c879819c09f1525e7bc69b84f7928180de584f92c846e01fa2daf5b17e32967"
59 | }
60 | ],
61 | "branches": [
62 | {
63 | "desc": "1: tlv1+nonce and tlv2+nonce",
64 | "H(`LnBranch`,19d6ecfa3be88d29c30e56167f58526d7695dfac9cb95e1256deb222c92db4d0b013756c8fee86503a0b4abdab4cddeb1af5d344ca6fc2fa8b6c08938caa6f93)": "c3774abbf4815aa54ccaa026bff6581f01f3be5fe814c620a252534f434bc0d1"
65 | },
66 | {
67 | "desc": "1 and tlv3+nonce",
68 | "H(`LnBranch`,7c879819c09f1525e7bc69b84f7928180de584f92c846e01fa2daf5b17e32967c3774abbf4815aa54ccaa026bff6581f01f3be5fe814c620a252534f434bc0d1)": "ab2e79b1283b0b31e0b035258de23782df6b89a38cfa7237bde69aed1a658c5d"
69 | }
70 | ],
71 | "merkle": "ab2e79b1283b0b31e0b035258de23782df6b89a38cfa7237bde69aed1a658c5d"
72 | },
73 | {
74 | "comment": "invoice_request test: offer_issuer_id = Alice (privkey 0x414141...), offer_description = 'A Mathematical Treatise', offer_amount = 100, offer_currency = 'USD', invreq_payer_id = Bob (privkey 0x424242...), invreq_metadata = 0x0000000000000000",
75 | "bolt12": "lnr1qqyqqqqqqqqqqqqqqcp4256ypqqkgzshgysy6ct5dpjk6ct5d93kzmpq23ex2ct5d9ek293pqthvwfzadd7jejes8q9lhc4rvjxd022zv5l44g6qah82ru5rdpnpjkppqvjx204vgdzgsqpvcp4mldl3plscny0rt707gvpdh6ndydfacz43euzqhrurageg3n7kafgsek6gz3e9w52parv8gs2hlxzk95tzeswywffxlkeyhml0hh46kndmwf4m6xma3tkq2lu04qz3slje2rfthc89vss",
76 | "tlv": "invoice_request",
77 | "first-tlv": "00080000000000000000",
78 | "leaves": [
79 | {
80 | "H(`LnLeaf`,00080000000000000000)": "cd45d50b8dbb73ba995f92aa48be7c2909331998cb070572f5499bae338a03c6",
81 | "H(`LnNonce`|first-tlv,0)": "edc13c82e89b213a5641b27f0c06c5f31ea948a0cc2fd6495120cc8590cac3f5",
82 | "H(`LnBranch`,leaf+nonce)": "5ced451fad76ab7edc8084b84c8b5086df195b2a503c25b371e6850a280c94ab"
83 | },
84 | {
85 | "H(`LnLeaf`,0603555344)": "ae61bfe63f8fc81b7a02a962182a5b5e01501365806481d52fbdfbca915266fa",
86 | "H(`LnNonce`|first-tlv,6)": "cc9fc57ce5e82252b6cc8908a93f012b13294a82132768e36dd767b3c3c289e8",
87 | "H(`LnBranch`,leaf+nonce)": "a2ea87a666c1524d25132ff59883c96a118728ff76595d239f5806143e3e9c9e"
88 | },
89 | {
90 | "H(`LnLeaf`,080164)": "b4f3adb8ca4f4a4c0e7cd9e0b1cafe8634cf8a864e1a730868bdda39fbd3e336",
91 | "H(`LnNonce`|first-tlv,8)": "376180f1ef3b7973ba4989f9391502bd78a1a8a54929fe9adcaec1dd2bfec648",
92 | "H(`LnBranch`,leaf+nonce)": "fa0bb4f0fa2f2625c63eec9bf3a29c9aa304e64d5aa44d38e050a6bd7d6fc5c0"
93 | },
94 | {
95 | "H(`LnLeaf`,0a1741204d617468656d61746963616c205472656174697365)": "7007775409456c33c47bddd7ce946ecd5a82035f1d5a529cc90e84d146f75a6e",
96 | "H(`LnNonce`|first-tlv,10)": "01926a0c38b4ec71d76b116eeb81ea7999706fdce24a7f5b9d67bf867fd0c4d8",
97 | "H(`LnBranch`,leaf+nonce)": "349379beebd68fd72296e76cb2ae28554b35fa9234853956b81b24c008783230"
98 | },
99 | {
100 | "H(`LnLeaf`,162102eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619)": "bdde38b7b58fa74acee1e943bbc32c04306368cb2aa513856f53f45be461051b",
101 | "H(`LnNonce`|first-tlv,22)": "2e571571c7dd0739dbc4180bb96b7652b055f9e97f80d37337c96689990fdbaa",
102 | "H(`LnBranch`,leaf+nonce)": "384853c9811863028876088ce34e75d784ac027fd564f103ea972cdf96236e47"
103 | },
104 | {
105 | "H(`LnLeaf`,58210324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c)": "f3b92382531e261e16a0f35d65f314ae622306bbb1b206fee00d80153b76eea3",
106 | "H(`LnNonce`|first-tlv,88)": "c31a695332d176217470b705cde5c8cd71cdb611e1f26c5a98f14c0d935c97bd",
107 | "H(`LnBranch`,leaf+nonce)": "73e067757513706491e0da4e8077112e606da55c04239ad13ab609bc82907600"
108 | }
109 | ],
110 | "branches": [
111 | {
112 | "desc": "1: metadata+nonce and currency+nonce",
113 | "H(`LnBranch`,5ced451fad76ab7edc8084b84c8b5086df195b2a503c25b371e6850a280c94aba2ea87a666c1524d25132ff59883c96a118728ff76595d239f5806143e3e9c9e)": "f0aa4611039a3a8a90dc8331fa75c9acf433be7285cac0983902aaaa8f66aaa9"
114 | },
115 | {
116 | "desc": "2: amount+nonce and descripton+nonce",
117 | "H(`LnBranch`,349379beebd68fd72296e76cb2ae28554b35fa9234853956b81b24c008783230fa0bb4f0fa2f2625c63eec9bf3a29c9aa304e64d5aa44d38e050a6bd7d6fc5c0)": "92e6478159d6763b19c5d03a8a834e179116f89e0cec700049e5ce921f8c400e"
118 | },
119 | {
120 | "desc": "3: 1 and 2",
121 | "H(`LnBranch`,92e6478159d6763b19c5d03a8a834e179116f89e0cec700049e5ce921f8c400ef0aa4611039a3a8a90dc8331fa75c9acf433be7285cac0983902aaaa8f66aaa9)": "432097bd1a848ab41eee3695a2c5932c4aea987b27b1a61e58ac950ecce1214a"
122 | },
123 | {
124 | "desc": "4: node_id+nonce and payer_id+nonce",
125 | "H(`LnBranch`,384853c9811863028876088ce34e75d784ac027fd564f103ea972cdf96236e4773e067757513706491e0da4e8077112e606da55c04239ad13ab609bc82907600)": "2ac9b0261d644027939d9a7bd055cb2468b79d92c6811d56a300c6b8ff97c14d"
126 | },
127 | {
128 | "desc": "5: 3 and 4",
129 | "H(`LnBranch`,2ac9b0261d644027939d9a7bd055cb2468b79d92c6811d56a300c6b8ff97c14d432097bd1a848ab41eee3695a2c5932c4aea987b27b1a61e58ac950ecce1214a)": "608407c18ad9a94d9ea2bcdbe170b6c20c462a7833a197621c916f78cf18e624"
130 | }
131 | ],
132 | "merkle": "608407c18ad9a94d9ea2bcdbe170b6c20c462a7833a197621c916f78cf18e624",
133 | "signature_tag": "lightninginvoice_requestsignature",
134 | "H(signature_tag,merkle)": "aefe3aa88a69772c246dcaef75ed3e7566c08ecc4e9f995233526a5651fc34cd",
135 | "signature": "b8f83ea3288cfd6ea510cdb481472575141e8d8744157f98562d162cc1c472526fdb24befefbdebab4dbb726bbd1b7d8aec057f8fa805187e5950d2bbe0e5642"
136 | }
137 | ]
138 |
--------------------------------------------------------------------------------
/proposals/route-blinding.md:
--------------------------------------------------------------------------------
1 | # Route Blinding
2 |
3 | ## Table of Contents
4 |
5 | * [Proposal](#proposal)
6 | * [Introduction](#introduction)
7 | * [Overview](#overview)
8 | * [Notations](#notations)
9 | * [Requirements](#requirements)
10 | * [Encrypted data](#encrypted-data)
11 | * [Creating a blinded route](#creating-a-blinded-route)
12 | * [Sending to a blinded route](#sending-to-a-blinded-route)
13 | * [Receiving from a blinded route](#receiving-from-a-blinded-route)
14 | * [Blinded payments](#blinded-payments)
15 | * [Attacks](#attacks)
16 | * [Unblinding channels with payment probing](#unblinding-channels-with-payment-probing)
17 | * [Unblinding nodes after restart](#unblinding-nodes-after-restart)
18 | * [Tips and Tricks](#tips-and-tricks)
19 | * [Recipient pays fees](#recipient-pays-fees)
20 | * [Dummy hops](#dummy-hops)
21 | * [Wallets and unannounced channels](#wallets-and-unannounced-channels)
22 | * [Blinded route selection](#blinded-route-selection)
23 | * [Blinded trampoline route](#blinded-trampoline-route)
24 | * [FAQ](#faq)
25 | * [Why not use rendezvous](#why-not-use-rendezvous)
26 | * [Why not use HORNET](#why-not-use-hornet)
27 |
28 | ## Proposal
29 |
30 | ### Introduction
31 |
32 | Route blinding is a lightweight technique to provide recipient anonymity by blinding an arbitrary
33 | amount of hops at the end of an onion path. It's more flexible than rendezvous routing because it
34 | simply replaces the public keys of the nodes in the route with random public keys while letting
35 | senders choose what data they put in the onion for each hop. Blinded routes are also reusable in
36 | some cases (e.g. onion messages).
37 |
38 | The downside compared to rendezvous is that senders have more leeway to probe by changing various
39 | variables, so the scheme needs to explicitly defend against probing attacks and may provide less
40 | privacy against some classes of attacks.
41 |
42 | Some use-cases where route blinding is useful include:
43 |
44 | * Sender and recipient anonymity for onion messages
45 | * Recipient anonymity for Bolt 12 offers
46 | * Recipient anonymity when receiving payments
47 | * Using unannounced channels in invoices without revealing them
48 | * Forcing a payment to go through a specific set of intermediaries that can witness the payment
49 |
50 | ### Overview
51 |
52 | At a high level, route blinding works by having the recipient choose an _introduction point_ and a
53 | route to itself from that introduction point. The recipient then blinds each node and channel along
54 | that route with ECDH. The recipient sends details about the blinded route and some cryptographic
55 | material to the sender (via a Bolt 11 invoice or Bolt 12 offer), which lets the sender build an
56 | onion with enough information to allow nodes in the blinded route to incrementally unblind the next
57 | node in the route.
58 |
59 | This scheme requires all the nodes in the blinded route and the sender to activate support for the
60 | feature. It needs a big enough share of the network to support it to provide meaningful privacy
61 | guarantees.
62 |
63 | ### Notations
64 |
65 | * A node `N(i)`'s `node_id` is defined as: `N(i) = k(i) * G` (`k(i)` is the node's private key).
66 | * Blinded `node_id`s are defined as: `B(i) = b(i) * G` (`b(i)` is the blinding factor).
67 | * Sphinx ephemeral public keys are defined as: `E(i) = e(i) * G`.
68 |
69 | ### Requirements
70 |
71 | A node `N(r)` wants to provide a blinded route `N(0) -> N(1) -> ... -> N(r)` that must be used
72 | to receive onions.
73 |
74 | * Intermediate nodes in the blinded route MUST NOT learn the `node_id` or `scid` of other
75 | intermediate nodes except for their immediate predecessor or successor.
76 | * Intermediate nodes in the blinded route MUST NOT learn their distance to the recipient `N(r)`.
77 | * Senders MUST NOT learn the real `node_id` and `scid` of the blinded intermediate hops after the
78 | introduction point `N(0)`.
79 | * If `N(r)` creates multiple blinded routes to itself, senders MUST NOT be able to tell that these
80 | routes lead to the same recipient (unless of course this information is leaked by higher layers
81 | of the protocol, such as using the same `payment_hash` or being generated for the same offer).
82 |
83 | ### Encrypted data
84 |
85 | Route blinding introduces a new TLV field to the onion `tlv_payload`: the `encrypted_data`.
86 |
87 | This field is used to carry data coming from the builder of the route that cannot be modified by
88 | the sender. It needs to contain enough data to let intermediate nodes locate the next node in the
89 | route (usually a `node_id` or `scid`), and may be extended with additional data in the future. It
90 | uses ChaCha20-Poly1305 as AEAD scheme.
91 |
92 | 1. type: 10 (`encrypted_data`)
93 | 2. data:
94 | * [`...*byte`:`encrypted_data`]
95 |
96 | Once decrypted, the content of this encrypted payload is a TLV stream.
97 |
98 | ### Creating a blinded route
99 |
100 | `N(r)` performs the following steps to create a blinded route:
101 |
102 | ```text
103 | Initialization:
104 |
105 | e(0) <- {0;1}^256
106 | E(0) = e(0) * G
107 |
108 | Blinding:
109 |
110 | For i = 0 to r:
111 | ss(i) = H(e(i) * N(i)) = H(k(i) * E(i)) // shared secret known only by N(r) and N(i)
112 | B(i) = HMAC256("blinded_node_id", ss(i)) * N(i) // Blinded node_id for N(i), private key known only by N(i)
113 | rho(i) = HMAC256("rho", ss(i)) // Key used to encrypt payload for N(i) by N(r)
114 | e(i+1) = H(E(i) || ss(i)) * e(i) // Ephemeral private key, only known by N(r)
115 | E(i+1) = H(E(i) || ss(i)) * E(i) // NB: N(i) must not learn e(i)
116 | ```
117 |
118 | Note that this is exactly the same construction as Sphinx, but at each hop we use the shared secret
119 | to derive a blinded `node_id` for `N(i)` for which the private key will only be known by `N(i)`.
120 |
121 | The recipient then creates `encrypted_data(i)` by encrypting application-specific data with
122 | ChaCha20-Poly1305 using the `rho(i)` key.
123 |
124 | To use the blinded route, senders need the following data:
125 |
126 | * The real `node_id` of the introduction point `N(0)` (to locate the beginning of the route)
127 | * The list of blinded `node_id`s: `[B(1),...,B(r)]`
128 | * The encrypted data for each node: `[encrypted_data(0),...,encrypted_data(r)]`
129 | * The first blinding `path_key`: `E(0)`
130 |
131 | ### Sending to a blinded route
132 |
133 | The sender finds a route to the introduction point `N(0)`, and extends it with the blinded route.
134 | It then creates an onion for that whole route, and includes `E(0)` and `encrypted_data(0)` in the
135 | onion payload for `N(0)`. It includes `encrypted_data(i)` in the onion payload for `B(i)`.
136 |
137 | When `N(0)` receives the onion and decrypts it, it finds `E(0)` in the payload and is able to
138 | compute the following:
139 |
140 | ```text
141 | ss(0) = H(k(0) * E(0))
142 | rho(0) = HMAC256("rho", ss(0))
143 | E(1) = H(E(0) || ss(0)) * E(0)
144 | ```
145 |
146 | It uses `rho(0)` to decrypt the `encrypted_data(0)` and discovers that `B(1)` is actually `N(1)`.
147 | It forwards the onion to `N(1)` and includes `E(1)` in a TLV field in the lightning message
148 | (e.g. in the extension field of an `update_add_htlc` message).
149 |
150 | All the following intermediate nodes `N(i)` do the following steps:
151 |
152 | ```text
153 | E(i) <- extracted from the lightning message's fields
154 | ss(i) = H(k(i) * E(i))
155 | b(i) = HMAC256("blinded_node_id", ss(i)) * k(i)
156 | Use b(i) instead of k(i) to decrypt the incoming onion using sphinx
157 | rho(i) = HMAC256("rho", ss(i))
158 | Use rho(i) to decrypt the `encrypted_data` inside the onion and discover the next node
159 | E(i+1) = H(E(i) || ss(i)) * E(i)
160 | Forward the onion to the next node and include E(i+1) in a TLV field in the message
161 | ```
162 |
163 | ### Receiving from a blinded route
164 |
165 | When `N(r)` receives the onion message and `E(r)`, they do the same unwrapping as intermediate
166 | nodes. The difference is that the onion will be a final onion.
167 |
168 | `N(r)` must also validate that the blinded route was used in the context it was created for, and is
169 | a route that they created. It's important to note than anyone can create valid blinded routes to
170 | anyone else. Alice for example is able to create a blinded route `Bob -> Carol -> Dave`. In most
171 | cases, Dave wants to ignore messages that come through routes that were created by someone else.
172 |
173 | The details of this validation step depends on the actual application using route blinding. For
174 | example, when using a blinded route for payments, the recipient must verify that the route was
175 | used in conjunction with the right `payment_hash`. It can do so by storing the `payment_preimage`
176 | in the `encrypted_data` payload to itself and verifying it when receiving the payment: malicious
177 | senders don't know the preimage beforehand, so they won't be able to create a satisfying route.
178 |
179 | Without this validation step, the recipient exposes itself to malicious probing, which could let
180 | attackers deanonymize the route.
181 |
182 | ### Blinded payments
183 |
184 | This section provides more details on how route blinding can be used for payments.
185 |
186 | In order to protect against malicious probing (detailed in the [Attacks](#attacks) section), it is
187 | the recipient who chooses what payment relay parameters will be used inside the route (e.g. fees)
188 | and encodes them in the `encrypted_data` payload for each blinded node. The sender will not set the
189 | `amt_to_forward` and `outgoing_cltv_value` fields in the onion payloads for blinded intermediate
190 | nodes: these nodes will instead follow the instructions found in their `encrypted_data`.
191 |
192 | The `encrypted_data` for each intermediate node will contain the following fields:
193 |
194 | * `short_channel_id`: outgoing channel that should be used to route the payment
195 | * `fee_base_msat`: base fee that must be applied before relaying the payment
196 | * `fee_proportional_millionths`: proportional fee that must be applied before relaying the payment
197 | * `cltv_expiry_delta`: cltv expiry delta that must be applied before relaying the payment
198 | * `max_cltv_expiry`: maximum expiry allowed for this payment
199 | * `htlc_minimum_msat`: minimum htlc amount that should be accepted
200 | * `allowed_features`: features related to payment relay that the sender is allowed to use
201 |
202 | The recipient must use values that provide a good enough anonymity set, by looking at nearby
203 | channels and selecting values that would work for a large enough number of those channels.
204 | Otherwise it could be easy for a malicious sender to figure out which channels are hidden inside
205 | the blinded route if for example the selected fees are lower than most other candidates.
206 |
207 | The recipient also includes the `payment_preimage` (or another private unique identifier for the
208 | payment) in the `path_id` field of the `encrypted_data` payload for itself: this will let the
209 | recipient verify that the route is only used for that specific payment and was generated by them.
210 |
211 | If a node inside the blinded route receives a payment that doesn't use the parameters provided in
212 | the `encrypted_data`, it must reject the payment and respond with an unparsable error onion. That
213 | ensures the payer won't know which node failed and for what reason (otherwise that would provide
214 | data that the payer could use to probe nodes inside the route).
215 |
216 | Note that we are also providing a `max_cltv_expiry` field: this ensures that the blinded route
217 | expires after some time, restricting future probing attempts.
218 |
219 | If we assume that all nodes support `var_onion_option`, we don't need to include the
220 | `allowed_features` field for now as there are no other features that affect payment relay and
221 | could be used as a probing vector. However, future updates may add such features (e.g. PTLC
222 | support), in which case the `allowed_features` field must not be empty.
223 |
224 | Let's go through an example to clarify those requirements.
225 |
226 | Alice creates an invoice with the following blinded route: `Carol -> Bob -> Alice`.
227 | The channels along that route have the following settings:
228 |
229 | * `Carol -> Bob`
230 | * `fee_base_msat`: 10
231 | * `fee_proportional_millionths`: 250
232 | * `cltv_expiry_delta`: 144
233 | * `htlc_minimum_msat`: 1
234 | * `Bob -> Alice`
235 | * `fee_base_msat`: 50
236 | * `fee_proportional_millionths`: 100
237 | * `cltv_expiry_delta`: 48
238 | * `htlc_minimum_msat`: 1000
239 |
240 | Alice chooses the following parameters for the blinded route, that satisfy the requirements of the
241 | channels described above and adds a safety margin in case nodes update their relay parameters:
242 |
243 | * `fee_base_msat`: 100
244 | * `fee_proportional_millionths`: 500
245 | * `htlc_minimum_msat`: 1000
246 | * `cltv_expiry_delta`: 144
247 |
248 | Alice uses the same values for both channels for simplicity's sake. Alice can now compute aggregate
249 | values for the complete route (iteratively starting from the end of the route), using integer
250 | arithmetic to compute `ceil(a/b)` as `(a+b-1)/b` (we round values up, otherwise the sender may
251 | receive slightly less than intended):
252 |
253 | * `route_fee_base_msat(n+1) = (fee_base_msat(n+1) * 1000000 + route_fee_base_msat(n) * (1000000 + fee_proportional_millionths(n+1)) + 1000000 - 1) / 1000000`
254 | * `route_fee_proportional_millionths(n+1) = ((route_fee_proportional_millionths(n) + fee_proportional_millionths(n+1)) * 1000000 + route_fee_proportional_millionths(n) * fee_proportional_millionths(n+1) + 1000000 - 1) / 1000000`
255 |
256 | Alice wants to use a `min_final_cltv_expiry_delta` of 12 blocks, which she adds to the route's
257 | total `cltv_expiry_delta`. This yields the following values:
258 |
259 | * `route_fee_base_msat`: 201
260 | * `route_fee_proportional_millionths`: 1001
261 | * `route_cltv_expiry_delta`: 300
262 |
263 | Let's assume the current block height is 1000. Alice wants the route to be used in the next 200
264 | blocks, meaning that the `max_cltv_expiry` she will communicate to the payer will be 1200. She
265 | also wants a `min_final_cltv_expiry_delta` of 12 though and so in the encrypted payload to herself,
266 | she sets `max_cltv_expiry = 1212` and adds `cltv_expiry_delta` for each hop after that. Alice then
267 | transmits the following information to the sender (most likely via an invoice):
268 |
269 | * Blinded route: `[N(carol), B(bob), B(alice)]`
270 | * First blinding `path_key`: `E(carol)`
271 | * Aggregated route relay parameters and constraints:
272 | * `fee_base_msat`: 201
273 | * `fee_proportional_millionths`: 1001
274 | * `htlc_minimum_msat`: 1000
275 | * `cltv_expiry_delta`: 300
276 | * `max_cltv_expiry`: 1200 (may be conveyed via invoice expiration, assuming 10 minute blocks)
277 | * `allowed_features`: empty
278 | * Encrypted data for blinded nodes:
279 | * `encrypted_payload(alice)`:
280 | * `path_id`: `payment_preimage`
281 | * `max_cltv_expiry`: 1212
282 | * `encrypted_payload(bob)`:
283 | * `outgoing_channel_id`: `scid_bob_alice`
284 | * `fee_base_msat`: 100
285 | * `fee_proportional_millionths`: 500
286 | * `htlc_minimum_msat`: 1000
287 | * `max_cltv_expiry`: 1356
288 | * `encrypted_payload(carol)`:
289 | * `outgoing_channel_id`: `scid_carol_bob`
290 | * `fee_base_msat`: 100
291 | * `fee_proportional_millionths`: 500
292 | * `htlc_minimum_msat`: 1000
293 | * `max_cltv_expiry`: 1500
294 |
295 | Note that the introduction point (Carol) uses the real `node_id`, not the blinded one, because the
296 | sender needs to be able to locate this introduction point and find a route to it. The sender will
297 | send the first blinding `path_key` `E(carol)` in the onion `hop_payload` for Carol, which will
298 | allow Carol to compute the blinding shared secret and correctly forward. We put this blinding
299 | `path_key` in the onion instead of using a tlv in `update_add_htlc` because intermediate nodes
300 | added before the blinded route may not support route blinding and wouldn't know how to relay it.
301 |
302 | Erin wants to send 100 000 msat to this blinded route.
303 | She can reach Carol via Dave: `Erin -> Dave -> Carol`, where the channel between Dave and Carol uses
304 | the following relay parameters:
305 |
306 | * `fee_base_msat`: 10
307 | * `fee_proportional_millionths`: 100
308 | * `cltv_expiry_delta`: 24
309 |
310 | Erin uses the aggregated route relay parameters to compute how much should be sent to Carol:
311 |
312 | * `amount = 100000 + 201 + (1001 * 100000 + 1000000 - 1) / 1000000 = 100302 msat`
313 |
314 | Erin chooses a final expiry of 1100, which is below Alice's `max_cltv_expiry`. This value may be
315 | chosen by adding a random cltv offset to the current block height as described in
316 | [Recommendations for Routing](../07-routing-gossip.md#recommendations-for-routing).
317 |
318 | Erin computes the expiry that should be sent to Carol:
319 |
320 | * `expiry = 1100 + 300 = 1400`
321 |
322 | When a node in the blinded route receives an htlc, the onion will not contain the `amt_to_forward`
323 | or `outgoing_cltv_value`. They will have to compute them based on the fields contained in their
324 | `encrypted_data` (`fee_base_msat`, `fee_proportional_millionths` and `cltv_expiry_delta`).
325 |
326 | For example, here is how Carol will compute the values for the htlc she relays to Bob:
327 |
328 | * `amount = ((100302 - fee_base_msat) * 1000000 + 1000000 + fee_proportional_millionths - 1) / (1000000 + fee_proportional_millionths) = 100152 msat`
329 | * `expiry = 1400 - cltv_expiry_delta = 1256`
330 |
331 | And here is how Bob computes the values for the htlc he relays to Alice:
332 |
333 | * `amount = ((100152 - fee_base_msat) * 1000000 + 1000000 + fee_proportional_millionths - 1) / (1000000 + fee_proportional_millionths) = 100002 msat`
334 | * `expiry = 1256 - cltv_expiry_delta = 1112`
335 |
336 | Note that as the rounding errors aggregate, the recipient will receive slightly more than what was
337 | expected. The sender includes `amt_to_forward` in the onion payload for the recipient to let them
338 | verify that the received amount is (slightly) greater than what the sender intended to send (which
339 | protects against intermediate nodes that would try to relay a lower amount).
340 |
341 | The messages exchanged will contain the following values:
342 |
343 | ```text
344 | Erin Dave Carol Bob Alice
345 | | update_add_htlc | update_add_htlc | update_add_htlc | update_add_htlc |
346 | | +--------------------------------+ | +------------------------------------------+ | +------------------------------------------+ | +--------------------------------+ |
347 | | | amount: 100322 msat | | | amount: 100302 msat | | | amount: 100152 msat | | | amount: 100002 msat | |
348 | | | expiry: 1424 | | | expiry: 1400 | | | expiry: 1256 | | | expiry: 1112 | |
349 | | | onion_routing_packet: | | | onion_routing_packet: | | | onion_routing_packet: | | | onion_routing_packet: | |
350 | | | +----------------------------+ | | | +--------------------------------------+ | | | +--------------------------------------+ | | | +----------------------------+ | |
351 | | --> | | amount_fwd: 100302 msat | | --> | --> | | path_key: E(carol) | | --> | --> | | encrypted_data: | | --> | --> | | amount_fwd: 100000 msat | | --> |
352 | | | | outgoing_expiry: 1400 | | | | | encrypted_data: | | | | | +----------------------------------+ | | | | | outgoing_expiry: 1112 | | |
353 | | | | scid: scid_dave_to_carol | | | | | +----------------------------------+ | | | | | | scid: scid_bob_to_alice | | | | | | encrypted_data: | | |
354 | | | +----------------------------+ | | | | | scid: scid_carol_to_bob | | | | | | | fee_base_msat: 100 | | | | | | +-----------------------+ | | |
355 | | | | path_key: E(carol) | | | | | | fee_base_msat: 100 | | | | | | | fee_proportional_millionths: 500 | | | | | | | path_id: preimage | | | |
356 | | | | encrypted_data(carol) | | | | | | fee_proportional_millionths: 500 | | | | | | | htlc_minimum_msat: 1000 | | | | | | | max_cltv_expiry: 1200 | | | |
357 | | | +----------------------------+ | | | | | htlc_minimum_msat: 1000 | | | | | | | cltv_expiry_delta: 144 | | | | | | +-----------------------+ | | |
358 | | | | encrypted_data(bob) | | | | | | cltv_expiry_delta: 144 | | | | | | | max_cltv_expiry: 1356 | | | | | +----------------------------+ | |
359 | | | +----------------------------+ | | | | | max_cltv_expiry: 1500 | | | | | | +----------------------------------+ | | | | tlv_extension | |
360 | | | | amount_fwd: 100000 msat | | | | | +----------------------------------+ | | | | +--------------------------------------+ | | | +----------------------------+ | |
361 | | | | outgoing_expiry: 1112 | | | | +--------------------------------------+ | | | | amount_fwd: 100000 msat | | | | | path_key: E(alice) | | |
362 | | | | encrypted_data(alice) | | | | | encrypted_data(bob) | | | | | outgoing_expiry: 1112 | | | | +----------------------------+ | |
363 | | | +----------------------------+ | | | +--------------------------------------+ | | | | encrypted_data(alice) | | | +--------------------------------+ |
364 | | +--------------------------------+ | | | amount_fwd: 100000 msat | | | | +--------------------------------------+ | | |
365 | | | | | outgoing_expiry: 1112 | | | | tlv_extension | | |
366 | | | | | encrypted_data(alice) | | | | +--------------------------------------+ | | |
367 | | | | +--------------------------------------+ | | | | path_key: E(bob) | | | |
368 | | | +------------------------------------------+ | | +--------------------------------------+ | | |
369 | | | | +------------------------------------------+ | |
370 | | | | | |
371 | ```
372 |
373 | Note that all onion payloads are described in each `update_add_htlc` for clarity, but only the
374 | first one can be decrypted by the intermediate node that receives the message (standard Bolt 4
375 | onion encryption).
376 |
377 | ## Attacks
378 |
379 | ### Unblinding channels with payment probing
380 |
381 | Recipients must be careful when using route blinding for payments to avoid letting attackers
382 | guess which nodes are hidden inside of the route. Let's walk through an attack to understand
383 | why.
384 |
385 | Let's assume that our routing graph looks like this:
386 |
387 | ```text
388 | +-------+ +-------+
389 | | X | | X |
390 | +-------+ +-------+
391 | | |
392 | | |
393 | +-------+ +-------+ +-------+ +-------+
394 | | X |------| Carol |------| Bob |------| Alice |
395 | +-------+ +-------+ +-------+ +-------+
396 | | |
397 | | |
398 | +-------+ +-------+
399 | | X | | X |
400 | +-------+ +-------+
401 | ```
402 |
403 | Alice creates a blinded route `Carol -> Bob -> Alice`.
404 | Alice has chosen what fee settings will be used inside the blinded route.
405 | Let's assume she has chosen `fee_base_msat = 10` and `fee_proportional_millionths = 100`.
406 |
407 | The attacker knows that the recipient is at most two hops away from Carol. Instead of making the
408 | payment, the attacker watches for new `channel_update`s for every channel in a two-hops radius
409 | around Carol. At some point, the attacker sees a `channel_update` for the channel `Bob -> Alice`
410 | that sets `fee_proportional_millionths = 150`, which exceeds what Alice has chosen for the blinded
411 | route. The attacker then tries to make the payment.
412 |
413 | When Bob receives the payment, the fees are below its current settings, so it should reject it.
414 | The attacker would then receive a failure, and be able to infer that it's very likely that Alice
415 | is the final recipient.
416 |
417 | If the attackers are able to frequently request invoices from the recipient (e.g. from a Bolt 12
418 | offer), they don't even have to attempt the payment to detect this. They can simply periodically
419 | request invoices from the recipient and detect when the recipient raises the fees or cltv of the
420 | blinded route, and match that with recent `channel_update`s that they received.
421 |
422 | Similarly, feature bits that apply to payment relaying behavior can be used to fingerprint nodes
423 | inside the blinded route: this is why `allowed_features` are committed inside the `encrypted_data`.
424 |
425 | If nodes across the network use different values for `htlc_minimum_msat`, it can also be used to
426 | fingerprint nodes: that's why it is also committed inside the `encrypted_data`.
427 |
428 | This type of attack is the reason why all parameters that affect payment relaying behavior (fees,
429 | cltv, features, etc) are chosen by the recipient. The recipient should add a large enough margin
430 | to the current values actually used by nodes inside the route to protect against future raises.
431 | This is also why blinded routes used for payments have a `max_cltv_expiry` set by the recipient,
432 | even though that doesn't fully address the issue if the attackers are able to frequently request
433 | new blinded routes.
434 |
435 | Altruistic relaying nodes inside a blinded route could choose to relay payments with fees below
436 | their current settings, which would break this heuristic: however their economic incentive is to
437 | reject them, so we cannot rely on them to protect recipient privacy.
438 |
439 | Similarly, we mandate relaying nodes to only accept payments using exactly the fees provided in
440 | the `encrypted_data` payload. Otherwise, when observing a `channel_update` that raises a specific
441 | channel's fees, the attackers could try to use these new fees in a payment attempt: if the payment
442 | goes through, they would have even more confidence about the channel used in the blinded route.
443 | The incentives for relaying nodes aren't great, because we're asking them to reject payments that
444 | give them the right amount of fees to protect recipient privacy.
445 |
446 | ### Unblinding nodes after restart
447 |
448 | The attacks described in the previous section only applied to scenarios that use route blinding
449 | for payments. However, a variation of the same technique can be used for any scenario relying on
450 | route blinding to relay messages.
451 |
452 | If attackers suspect that a given node `N` may be part of a blinded route, they can wait for that
453 | node to go offline, and try using the blinded route while the node is offline. If the blinded
454 | route fails, it's likely that this node was indeed part of the blinded route. By repeating this
455 | sampling regularly, attackers can increase the confidence in their unblinding.
456 |
457 | To address this, recipients should choose nodes with high uptime for their blinded routes and
458 | periodically refresh them.
459 |
460 | ## Tips and Tricks
461 |
462 | ### Recipient pays fees
463 |
464 | It may be unfair to make payers pay more fees to accommodate the recipient's wish for anonymity.
465 | It should instead be the recipient that pays the fees of the blinded hops (and the payer pays the
466 | fees to reach the introduction point).
467 |
468 | If a merchant is selling an item for `N` satoshis, it should create an invoice for `N-f` satoshis,
469 | where `f` is the fee of the blinded part of the route.
470 |
471 | ### Dummy hops
472 |
473 | The sender knows an upper bound on the distance between the recipient and `N(0)`. If the recipient
474 | is close to `N(0)`, this might not be ideal. In such cases, the recipient may add any number of
475 | dummy hops at the end of the blinded route by using `N(j) = N(r)`. The sender will not be able to
476 | distinguish those from normal blinded hops.
477 |
478 | NB:
479 |
480 | * the recipient needs to fully validate each dummy hop's onion payload to detect tampering (and
481 | must ensure that these hops have been used and not truncated)
482 | * the recipient must use padding to ensure all `encrypted_data` payloads have the same length,
483 | otherwise the payer will be able to guess which hop is actually the recipient
484 |
485 | ### Wallets and unannounced channels
486 |
487 | Route blinding is particularly useful for wallets that are connected to nodes via unannounced
488 | channels. Such wallets could use a single blinded hop, which effectively hides their `node_id`
489 | and `scid` from the sender. It obviously reveals to the blinded node that the next node is the
490 | final recipient, but a wallet that's not online all the time with a stable IP will never be able
491 | to hide that information from the nodes it connects to anyway (even with rendezvous).
492 |
493 | ### Blinded route selection
494 |
495 | There is a wide array of strategies that a recipient may use when creating a blinded route to
496 | ensure good privacy while maintaining good payment reliability. We will walk through some of
497 | these strategies below. Note that these are only examples, implementations should find strategies
498 | that suit their users' needs.
499 |
500 | If the recipient is not a public node and has a small number of peers, then it's very simple:
501 | they can include one path per peer. A mobile wallet's topology for example will typically look
502 | like this:
503 |
504 | ```text
505 | +-------+ +-------+
506 | +----------| Carol | | X |
507 | | +-------+ +-------+
508 | | | |
509 | | | |
510 | +-------+ +-------+ +-------+ +-------+
511 | | Alice |------| Bob |------| X |------| X |
512 | +-------+ +-------+ +-------+ +-------+
513 | | |
514 | | |
515 | | +-------+
516 | +-------------------------| Dave |
517 | +-------+
518 | ```
519 |
520 | Alice could provide a blinded route containing one blinded path per peer and dummy hops:
521 |
522 | * Bob -> Blinded(Alice) -> Blinded(Alice) -> Blinded(Alice)
523 | * Carol -> Blinded(Alice) -> Blinded(Alice) -> Blinded(Alice)
524 | * Dave -> Blinded(Alice) -> Blinded(Alice) -> Blinded(Alice)
525 |
526 | Alice is able to use all of her inbound liquidity while benefiting from a large anonymity set: she
527 | could be any node at most three hops away from Bob, Carol and Dave.
528 |
529 | If the recipient is a public node, its strategy will be different. It should use introduction nodes
530 | that have many peers to obtain a good anonymity set. Let's assume that Alice's neighbourhood has
531 | the following topology:
532 |
533 | ```text
534 | +-------+ +-------+
535 | | X | | X |
536 | +-------+ +-------+
537 | | |
538 | | |
539 | +-------+ +-------+ +-------+
540 | | N1 |------| N2 |------| X |
541 | +-------+ +-------+ +-------+
542 | | | |
543 | | | |
544 | +-------+ +-------+ +-------+ +-------+
545 | | Alice |------| N3 |------| N4 |------| X |
546 | +-------+ +-------+ +-------+ +-------+
547 | ```
548 |
549 | Alice can run a BFS of depth 2 to identify that N2 and N4 are good introduction nodes that provide
550 | a large anonymity set. She can then provide the following blinded paths:
551 |
552 | * N2 -> Blinded(N1) -> Blinded(Alice) -> Blinded(Alice)
553 | * N4 -> Blinded(N3) -> Blinded(Alice) -> Blinded(Alice)
554 |
555 | Alice should analyze the payment relay parameters of all channels in her anonymity set and choose
556 | fees/cltv that would work for a large enough subset of them.
557 |
558 | Note that Alice chose non-overlapping paths: otherwise these paths may not have enough liquidity
559 | to relay the payment she expects to receive, unless the path capacity is much larger than the
560 | expected payment.
561 |
562 | When the receiver expects to receive large payments, liquidity may become an issue if it is
563 | scattered among too many peers. The receiver may be forced to use introduction nodes that are
564 | direct peers to ensure that enough liquidity is available (in which case it's particularly useful
565 | to include dummy hops in the blinded paths).
566 |
567 | ### Blinded trampoline route
568 |
569 | Route blinding can also be used with trampoline very easily. Instead of providing the
570 | `outgoing_channel_id` in `encrypted_data`, we simply need to provide the `outgoing_node_id`.
571 |
572 | Each trampoline node can then decrypt the `node_id` of the next node and compute `E(i)` for the
573 | next trampoline node. That `E(i)` can then be sent in the outer onion payload instead of using the
574 | lightning message's fields, which is even cleaner and doesn't require nodes between trampoline
575 | nodes to understand route blinding.
576 |
577 | Using a blinded trampoline route is a good solution for public nodes that have many peers and
578 | run into liquidity issues affecting payment reliability. Such recipients can choose trampoline
579 | nodes that will be able to find many paths towards them:
580 |
581 | ```text
582 | +-------+ +-------+
583 | +----------| X |--------+ +--------| X |----------+
584 | | +-------+ | | +-------+ |
585 | | | | |
586 | | | | |
587 | +-------+ +-------+ +-------+ +-------+ +-------+
588 | | T1 |------| X |------| Alice |------| X |------| T2 |
589 | +-------+ +-------+ +-------+ +-------+ +-------+
590 | | | | |
591 | | | | |
592 | | +-------+ | | +-------+ |
593 | +----------| X |--------+ +--------| X |----------+
594 | +-------+ +-------+
595 | ```
596 |
597 | Alice can provide the following blinded trampoline paths:
598 |
599 | * T1 -> Blinded(Alice)
600 | * T2 -> Blinded(Alice)
601 |
602 | T1 and T2 will be able to find many paths towards Alice and retry whenever some paths fail,
603 | working around the potential liquidity constraints.
604 |
605 | ## FAQ
606 |
607 | ### Why not use rendezvous
608 |
609 | While rendezvous is more private, it's also less flexible: senders cannot add data to the partial
610 | onion nor reuse it. When used for payments, the amount must be fixed ahead of time in the partial
611 | onion, which doesn't combine well with multi-part payments or temporary liquidity issues.
612 |
613 | Route blinding lets senders choose most of the data they put in the onion payloads, which makes
614 | it much more flexible, at the expense of introducing more probing surface for attackers.
615 |
616 | ### Why not use HORNET
617 |
618 | HORNET requires a slow session setup before it can provide useful speedups. In cases where you
619 | expect to send a single message per session (which is the case for payments and onion messages),
620 | HORNET actually performs worse than Sphinx in latency, bandwidth and privacy.
621 |
--------------------------------------------------------------------------------
/tools/bolt3-bitcoind-test.sh:
--------------------------------------------------------------------------------
1 | #! /bin/sh
2 |
3 | # To run all tests, try:
4 | # grep 'name: .*commitment tx' ../03-transactions.md | cut -d: -f2- | while read t; do ./bolt3-test-vector.sh $t || break; done
5 |
6 | TESTDIR=/tmp/bolt3-testdir.$$
7 | BOLT3=../03-transactions.md
8 |
9 | set -e
10 | CLI="bitcoin-cli -datadir=$TESTDIR"
11 | TEST=$TESTDIR/test
12 |
13 | VERBOSE=:
14 | VERBOSEPIPE=:
15 | if [ x"$1" = x"--verbose" ]; then
16 | VERBOSE=echo
17 | VERBOSEPIPE=cat
18 | shift
19 | fi
20 |
21 | # FIXME: This doesn't work in 0.14 (see bitcoin-core commit
22 | # 7d4e9509ade0c258728011d8f6544ec3e75d63dc)
23 | #FEELESS_TXS_OK=${FEELESS_TXS_OK:-true}
24 | FEELESS_TXS_OK=${FEELESS_TXS_OK:-false}
25 |
26 | # Comment this out to postmortem
27 | trap "$CLI stop >/dev/null 2>&1 || true; sleep 1; rm -rf $TESTDIR" EXIT
28 |
29 | if [ $# -lt 1 ]; then
30 | echo Usage: $0 "[--verbose] ..." >&2
31 | exit 1
32 | fi
33 |
34 | # Usage
35 | extract_fields()
36 | {
37 | grep "^ $1:" $2 || true
38 | }
39 |
40 | # Usage
41 | extract_field()
42 | {
43 | if [ $(grep -c "^ $1:" $2) != 1 ]; then
44 | echo "Ambiguous field $1" >&2
45 | exit 1
46 | fi
47 | extract_fields "$@" | cut -d: -f2-
48 | }
49 |
50 | # Usage
51 | htlc_property()
52 | {
53 | extract_field "htlc $1 $2" $3
54 | }
55 |
56 | # Usage
57 | extract_test()
58 | {
59 | print=:
60 | found=false
61 | while read LINE; do
62 | case "$LINE" in
63 | "name: $1")
64 | print=echo
65 | $print " $LINE"
66 | found=true
67 | ;;
68 | "name:"*|"")
69 | print=true
70 | ;;
71 | *)
72 | $print " $LINE"
73 | ;;
74 | esac
75 | done < $BOLT3
76 |
77 | if ! $found; then
78 | echo "No test $1 found" >&2
79 | exit 1
80 | fi
81 | }
82 |
83 | mkdir $TESTDIR
84 | echo regtest=1 > $TESTDIR/bitcoin.conf
85 | echo rpcbind=127.0.0.1 >> $TESTDIR/bitcoin.conf
86 | echo rpcport=18333 >> $TESTDIR/bitcoin.conf
87 | echo rpcpassword=$(od -tx1 -A none -N20 < /dev/urandom | tr -d ' ') >> $TESTDIR/bitcoin.conf
88 |
89 | if $FEELESS_TXS_OK; then
90 | echo minrelaytxfee=0 >> $TESTDIR/bitcoin.conf
91 | else
92 | echo minrelaytxfee=0.00000001 >> $TESTDIR/bitcoin.conf
93 | fi
94 |
95 | $VERBOSE Starting bitcoind
96 | bitcoind -datadir=$TESTDIR &
97 |
98 | i=0
99 | while ! $CLI getinfo >/dev/null 2>&1; do
100 | sleep 0.1
101 | i=$(($i + 1))
102 | if [ $i -ge 50 ]; then
103 | echo Bitcoind failed to start >&2
104 | exit 1
105 | fi
106 | done
107 |
108 | $VERBOSE Checking bitcoind genesis block matches BOLT3
109 | GENESIS=$($CLI getblock $($CLI getblockhash 0) false)
110 |
111 | if [ $GENESIS != $(extract_field 'Block 0 (genesis)' $BOLT3) ]; then
112 | echo Bad genesis block >&2
113 | exit 1
114 | fi
115 |
116 | $VERBOSE Submitting block '#1' from BOLT3
117 | $CLI submitblock $(extract_field 'Block 1' $BOLT3)
118 | # To activate segwit via BIP9, we need at least 432 blocks! Also lets us spend tx.
119 |
120 | $VERBOSE Activating SegWit
121 | $CLI generate 432 > /dev/null
122 |
123 | $VERBOSE Sending funding transaction from BOLT3
124 | TXID=$($CLI sendrawtransaction $(extract_field 'funding tx' $BOLT3))
125 | if [ $TXID != $(extract_field '# txid' $BOLT3) ]; then
126 | echo Bad funding txid >&2
127 | exit 1
128 | fi
129 |
130 | echo -n Running \""$*"\":\
131 |
132 | extract_test "$*" > $TEST
133 | if ! $FEELESS_TXS_OK && [ $(extract_field 'local_feerate_per_kw' $TEST) = 0 ]
134 | then
135 | echo SKIPPED
136 | $VERBOSE "Override by prepending FEELESS_TXS_OK=true to commandline"
137 | exit 0
138 | fi
139 |
140 | # In verbose mode, we need a CR here.
141 | $VERBOSE
142 |
143 | TX=$(extract_field 'output commit_tx' $TEST)
144 | $VERBOSE -n "Submitting commit_tx: "
145 | $CLI sendrawtransaction $TX | $VERBOSEPIPE
146 |
147 | # We can use success txs immediately
148 | extract_fields 'output htlc_success_tx [0-9]*' $TEST | while read TX; do
149 | $VERBOSE -n "Submitting ${TX%%:*}: "
150 | $CLI sendrawtransaction ${TX#*:} | $VERBOSEPIPE
151 | done
152 |
153 | # Timeout txs have to wait for timeout; fortunately they're in order.
154 | extract_fields 'output htlc_timeout_tx [0-9]*' $TEST | while read TX; do
155 | TITLE=${TX%%:*}
156 | HTLC=${TITLE##* }
157 | EXPIRY=$(htlc_property $HTLC expiry $BOLT3)
158 | # Should fail before expiry.
159 | $CLI generate $(($EXPIRY - 1 - $($CLI getblockcount) )) >/dev/null
160 | HEIGHT=$EXPIRY-1
161 | $VERBOSE -n "Submitting ${TX%%:*} TOO EARLY: "
162 | if $CLI sendrawtransaction ${TX#*:} > $TESTDIR/too-early 2>&1; then
163 | $VERBOSE $TESTDIR/too-early
164 | echo "Timeout worked at blockheight $($CLI getblockcount) not $EXPIRY" >&2
165 | exit 1
166 | fi
167 | tail -n1 $TESTDIR/too-early | $VERBOSEPIPE
168 | $CLI generate 1 >/dev/null
169 | $VERBOSE -n "Submitting ${TX%%:*}: "
170 | $CLI sendrawtransaction ${TX#*:} | $VERBOSEPIPE
171 | done
172 |
173 | echo Success
174 | exit 0
175 |
--------------------------------------------------------------------------------
/tools/extract-formats.py:
--------------------------------------------------------------------------------
1 | #! /usr/bin/python3
2 | # Simple script to parse specs and produce CSV files.
3 | # Released by Rusty Russell under CC0:
4 | # https://creativecommons.org/publicdomain/zero/1.0/
5 |
6 | # Outputs:
7 | #
8 | # Standard message types:
9 | # msgtype,,
10 | # msgdata,,,,[]
11 | #
12 | # TLV types:
13 | # tlvtype,,,
14 | # tlvdata,,,,,[]
15 | #
16 | # Subtypes:
17 | # subtype,
18 | # subtypedata,,,,[]
19 |
20 | from optparse import OptionParser
21 | import sys
22 | import re
23 | import fileinput
24 |
25 | # We allow either ordered or unordered lists.
26 | typeline = re.compile(
27 | r'(1\.|\*) type: (?P[-0-9A-Za-z_|]+) \(`(?P[A-Za-z0-9_]+)`\)( \(`?(?P