diff --git a/lnbook/ch12.md b/lnbook/ch12.md
index 72d4f55..dc1a55a 100644
--- a/lnbook/ch12.md
+++ b/lnbook/ch12.md
@@ -2,11 +2,556 @@
 
 > 📖 원문: [Chapter 12. Pathfinding and Payment Delivery](https://github.com/lnbook/lnbook/blob/develop/12_path_finding.asciidoc)
 
-
 ### 목차
 
-- [제목](#제목)
+- [라이트닝 프로토콜에서 경로 찾기](#라이트닝-프로토콜에서-경로-찾기)
+  - [관련 BOLT는 어디있을까?](#관련-bolt는-어디있을까)
+- [경로 찾기: 어떤 문제를 해결하나?](#경로-찾기-어떤-문제를-해결하나)
+  - [최적의 경로 선택하기](#최적의-경로-선택하기)
+  - [수학 및 컴퓨터 과학 분야에서의 경로 찾기](#수학-및-컴퓨터-과학-분야에서의-경로-찾기)
+  - [용량, 잔액, 유동성](#용량-잔액-유동성)
+  - [잔액의 불확실성](#잔액의-불확실성)
+  - [경로 찾기의 복잡성](#경로-찾기의-복잡성)
+  - [단순화하기](#단순화하기)
+- [경로 찾기와 결제 전달 프로세스](#경로-찾기와-결제-전달-프로세스)
+- [채널 그래프 구성하기](#채널-그래프-구성하기)
+  - [채널 그래프에서의 불확실성](#채널-그래프에서의-불확실성)
+  - [유동성 불확실성과 확률](#유동성-불확실성과-확률)
+  - [수수료 및 기타 채널 지표](#수수료-및-기타-채널-지표)
+- [후보 경로 찾기](#후보-경로-찾기)
+- [결제 전달 (시행착오 루프)](#결제-전달-시행착오-루프)
+  - [첫 번째 시도 (Path #1)](#첫-번째-시도-path-1)
+    - [실패로부터 학습하기](#실패로부터-학습하기)
+  - [두 번째 시도 (Path #4)](#두-번째-시도-path-4)
+    - [성공으로부터 학습하기](#성공으로부터-학습하기)
+    - [케케묵은 지식?](#케케묵은-지식)
+- [다중 분할 결제](#다중-분할-결제)
+  - [MPP 사용하기](#mpp-사용하기)
+    - [결제 쪼개기](#결제-쪼개기)
+  - [여러 번의 시도에 걸친 시행착오](#여러-번의-시도에-걸친-시행착오)
+- [결론](#결론)
 
 ---
 
-## 제목 
\ No newline at end of file
+라이트닝 네트워크에서의 결제 전송은 발신자에서 수신자까지의 경로를 찾는 과정, 즉 경로 찾기에 달려 있다. 라우팅은 발신자가 수행하므로 발신자는 목적지에 도달할 수 있는 적절한 경로를 찾아야 한다. 이 경로는 [10장 어니언 라우팅](./ch10.md)에서 살펴본 것처럼 어니언으로 인코딩된다.
+
+이 장에서는 경로 찾기 문제를 살펴보고 채널 잔액의 불확실성이 이 문제를 어떻게 복잡하게 만드는지 이해하며 일반적인 경로 찾기 구현이 이 문제를 어떻게 해결하려고 시도하는지 살펴본다.
+
+<br>
+
+## 라이트닝 프로토콜에서 경로 찾기
+
+경로 찾기, 경로 선택, 다중 분할 결제(MPP), 결제 시도 시행착오 루프는 프로토콜 의 최상위 계층에 있는 결제 계층(payment layer)의 대부분을 차지한다.
+
+해당 구성 요소는 그림 1.에 강조 표시되어 있다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1201.png" width="750">
+      그림 1. 라이트닝 프로토콜에서의 결제 전달
+  </figure>
+
+<br/>
+
+### 관련 BOLT는 어디있을까?
+
+지금까지 라이트닝 네트워크의 일부인 몇 가지 기술을 살펴봤고, 그 정확한 사양이 BOLT 표준의 일부인 것을 확인했다. 하지만 경로 찾기가 BOLT의 일부가 아니라는 사실에 놀랄 수 있다!
+
+그 이유는 경로 찾기는 서로 다른 구현 간에 어떤 형태의 조정이나 상호 운용성을 필요로 하는 활동이 아니기 때문이다. 앞서 살펴본 것처럼 경로는 발신자가 선택한다. 라우팅 세부 사항은 BOLT에 자세히 명시되어 있지만 경로 검색 및 선택은 전적으로 발신자에게 달려있다. 따라서 각 노드 구현체는 경로를 찾기 위해 서로 다른 전략과 알고리즘을 선택할 수 있다. 실제로 서로 다른 노드, 클라이언트 및 지갑 구현은 경로 찾기 알고리즘을 차별화 포인트로 삼아 경쟁할 수도 있다.
+
+<br>
+
+## 경로 찾기: 어떤 문제를 해결하나?
+
+경로 찾기라는 용어는 두 노드를 연결하는 *단일 경로*를 찾는다는 의미이기 때문에 다소 오해의 소지가 있다. 초창기 라이트닝 네트워크의 규모가 작고 상호 연결이 잘 되지 않았을 때는 실제로 수신인에게 도달하기 위한 결제 채널에 참여하는 방법을 찾는 것이 문제였다.
+
+하지만 라이트닝 네트워크가 폭발적으로 성장하면서 경로 찾기 문제의 성격이 바뀌었다. 이 책을 마무리하는 2021년 중반, 라이트닝 네트워크는 최소 55,000개의 공개 채널로 연결된 20,000개의 노드로 구성되어 있으며, 총 용량은 약 2,000 BTC에 달한다. 한 노드는 평균 8.8개의 채널을 가지고 있으며, 가장 많이 연결된 상위 10개 노드는 400~2,000개의 채널을 가지고 있다. 그림 2.는 LN 채널 그래프의 작은 하위 집합에 대한 시각화이다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1202.png" width="750">
+      그림 2. 2021년 7월 기준 라이트닝 네트워크의 일부 시각화
+      <br>
+      (원문 레파지토리 code/lngraph의 파이썬 코드로 생성)
+  </figure>
+
+<br/>
+<br/>
+
+발신자와 수신자가 여러 잘 연결된 노드들과 연결되어 있고 적절한 용량의 채널이 하나 이상 가지고 있는 경우 발신자와 수신자 사이에 수천 개의 경로가 존재한다. 이때 문제는 이 수천 개의 가능한 경로 중에서 결제 전달에 성공할 수 있는 *최적의 경로를 선택하는 것*이 된다.
+
+<br>
+
+### 최적의 경로 선택하기
+
+최적의 경로를 선택하려면 먼저 "최선"의 의미를 정의해야 한다. 다음과 같은 다양한 기준이 있을 수 있다.
+
+- 유동성이 충분한 경로. 결제를 라우팅하기에 유동성이 충분하지 않은 경로는 당연히 적합한 경로가 아니다.
+
+- 수수료가 낮은 경로. 여러 후보가 있다면 수수료가 낮은 경로를 선택하고 싶다.
+
+- 타임락이 짧은 경로. 자금을 너무 오래 묶어두는 것을 피하고 싶을 수 있으므로 타임락이 짧은 경로를 선택할 수 있다.
+
+이러한 모든 기준은 어느 정도 바람직할 수 있으며, 여러 측면을 고려하여 유리한 경로를 선택하는 것은 쉬운 일이 아니다. 이같은 최적화 문제는 너무 복잡해서 '최적의' 해법을 찾기 어려울 수도 있지만, 그래도 최적에 가까운 근사치를 구할 수 있는 경우가 있는데 이조차 가능하지 않다면 경로 찾기가 난해한 문제가 될 수 있기 때문에 이는 좋은 소식이 아닐 수 없다.
+
+<br>
+
+### 수학 및 컴퓨터 과학 분야에서의 경로 찾기
+
+라이트닝 네트워크의 경로 찾기는 수학에서는 그래프 이론(_graph theory_)의 일반적인 범주에 속하며, 컴퓨터 과학에서는 그래프 탐색(_graph traversal_)이라는 보다 구체적인 범주에 속한다.
+
+LN 같은 네트워크는 그래프라는 수학적 구조로 표현할 수 있으며, 노드는 간선(결제 채널)으로 서로 연결된다. 라이트닝 네트워크는 채널 잔액이 두 채널 파트너 간에 분할되고 결제 유동성이 각 방향에 따라 다르기 때문에 노드가 _비대칭적으로_ 연결되는 *방향 그래프*를 형성한다. 간선에 용량 제약이 있는 방향 그래프를 흐름 네트워크라 하며, 이는 교통 및 기타 유사한 네트워크를 최적화하는 데 사용되는 수학적 구조이다. 흐름 네트워크는 솔루션이 비용을 최소화하면서 특정 흐름을 달성해야 할 때 프레임워크로 사용할 수 있으며, 이를 최소 비용 플로우 문제(MCFP, minimum cost flow problem)라고 한다.
+
+> 💡 흐름 네트워크(flow network)
+>
+> 그래프 이론에서 흐름 네트워크(또는 전송 네트워크)는 각 간선에 용량이 있고 각 간선이 흐름을 수신하는 방향이 지정된 그래프이다. 간선에서 흐름의 양은 간선의 용량(capacity)을 초과할 수 없다. 운용 과학(Operation Research)이라는 분야에서 종종 방향 그래프를 네트워크, 정점을 노드, 간선을 호(arc)라 한다. 흐름은 나가는 흐름만 있는 시점(source)이나 들어오는 흐름만 있는 종점(sink)이 아닌 한, 노드로 유입되는 흐름의 양이 노드로 나가는 흐름의 양과 같아야 한다는 제한을 충족해야 한다. 컴퓨터 네트워크의 트래픽, 수요에 따른 순환, 파이프의 유체, 전기 회로의 전류 또는 노드 네트워크를 통해 무언가가 이동하는 유사한 모든 것을 모델링하는 데 사용할 수 있다. (출처: [위키백과 - flow network](https://en.wikipedia.org/wiki/Flow_network))
+
+<br>
+
+### 용량, 잔액, 유동성
+
+A 지점에서 B 지점으로 사토시를 전송하는 문제를 더 잘 이해하려면 용량, 잔액, 유동성이라는 세 가지 주요 용어를 더 잘 정의할 필요가 있다. 이 용어로 결제 채널의 결제 라우팅 기능을 설명한다.
+
+A←→B를 연결하는 결제 채널에서,
+
+**_용량(capacity)_** <br>
+&nbsp;&nbsp;&nbsp;&nbsp;펀딩 트랜잭션으로 2-of-2 다중서명에 자금을 조달한 총 사토시 양이다. 이는 채널에서 보유할 수 있는 최대 가치를 나타낸다. 채널 용량은 가십 프로토콜에 의해 발표되며 노드들에게 알려진다.
+
+**_잔액(Balance)_** <br>
+&nbsp;&nbsp;&nbsp;&nbsp;각 채널 파트너가 다른 채널 파트너에게 전송할 수 있는 사토시의 양이다. A의 잔액의 하위 집합은 노드 B로 전송할 수 있으며(A→B), B의 잔액의 하위 집합은 반대 방향으로 전송할 수 있다(A←B).
+
+**_유동성(liquidity)_** <br>
+&nbsp;&nbsp;&nbsp;&nbsp;실제로 채널을 통해 한 방향으로 전송할 수 있는 사용 가능한 (하위 집합) 잔액이다. A의 유동성은 A의 잔액에서 채널 준비금(channel_reserve)과 A가 커밋한 모든 처리되지 않은 HTLC(pending_HTLC)를 뺀 값과 같다.
+
+가십 공지를 통해 네트워크에 알려진 유일한 값은 채널의 총 용량이다. 이 용량 중 알려지지 않은 일부가 각 파트너의 잔액으로 분배된다. 이 잔액의 일부 하위 집합은 채널을 통해 한 방향으로만 전송할 수 있다.
+
+- capacity = balance(A) + balance(B)
+- liquidity(A) = balance(A) - channel_reserve(A) - pending_HTLC(A)
+
+<br>
+
+### 잔액의 불확실성
+
+모든 채널의 정확한 채널 잔액을 알고 있다면, 훌륭한 컴퓨터 과학 프로그램에서 가르치는 표준 경로 찾기 알고리즘을 사용하여 하나 이상의 결제 경로를 계산할 수 있다. 그러나 우리는 채널 잔액을 알지 못하며, 노드가 채널 공지를 통해 광고하는 총 채널 용량만 알고 있을 뿐이다. 결제가 성공적으로 이루어지려면 채널의 송금 측에 적절한 잔액이 있어야 한다. 채널 파트너 간에 용량이 어떻게 분배되어 있는지 알지 못한다면 결제를 보내려는 방향에 충분한 잔액이 있는지 알 수 없다.
+
+채널 업데이트에서 잔액을 발표하지 않는 이유는 개인정보 보호(privacy)와 확장성(scalability)의 두 가지 이유 때문이다. 첫째, 잔액을 발표하면 잔액 변화를 통계적으로 분석하여 결제를 감시할 수 있기 때문에 라이트닝 네트워크의 프라이버시가 저하될 수 있다. 둘째, 노드가 결제할 때마다 잔액을 (전 세계적으로) 발표하면 라이트닝 네트워크의 확장성이 모든 참여자에게 브로드캐스트되는 온체인 비트코인 트랜잭션만큼 나빠질 수 있다. 따라서 잔액은 발표되지 않다. 잔액의 불확실성에 직면한 경로 찾기 문제를 해결하려면 혁신적인 경로 찾기 전략이 필요하다. 이러한 전략은 네트워크를 통해 경로를 찾는 것이 발신자의 책임인 소스 기반 어니언 라우팅인 라우팅 알고리즘과 밀접하게 관련되어 있어야만 한다.
+
+이 잔액 불확실성 문제는 수학적으로 _유동성의 범위_(range of liquidity)로 설명할 수 있으며, 이는 알려진 정보를 기반으로 유동성의 하한과 상한을 나타낸다. 채널의 용량을 알고 있고 채널 예비 잔액(양쪽 끝에서 허용되는 최소 잔액)을 알고 있으므로 유동성은 다음과 같이 정의할 수 있다.
+
+- min(liquidity) = channel_reserve
+- max(liquidity) = capacity – channel_reserve
+
+또는 범위로
+
+- channel_reserve <= liquidity <= (capacity – channel_reserve)
+
+채널 유동성 불확실성 범위(channel liquidity uncertainty range)는 가능한 최소 유동성과 최대 유동성 사이의 범위이다. 이 정보는 두 채널 파트너를 외에 네트워크는 알 수 없다. 하지만 앞으로 살펴보겠지만, 결제 시도로부터 반환된 실패한 HTLC(failed HTLC)를 사용하여 유동성 추정치를 업데이트하고 불확실성을 줄일 수 있다. 예를 들어, 채널이 최대 유동성 추정치보다 작은 HTLC를 이행할 수 없다는 HTLC 실패 코드를 받으면 최대 유동성을 실패한 HTLC의 양으로 업데이트할 수 있다는 뜻이다. 간단히 말해, 유동성이 N 사토시의 HTLC를 처리할 수 있다고 생각했는데 M 사토시(M < N)를 전달하지 못했다는 사실을 알게 되면, 추정치를 상한선인 M-1로 업데이트할 수 있다. 상한선을 찾으려다 천장에 부딪혔으므로, 상한선이 생각했던 것 보다 낮음을 의미한다.
+
+<br>
+
+### 경로 찾기의 복잡성
+
+그래프에서 경로를 찾는 것은 최신 컴퓨터가 상당히 효율적으로 해결할 수 있는 문제이다. 개발자는 간선의 가중치가 모두 같을 경우 주로 넓이 우선 탐색을 선택한다. 간선의 가중치가 같지 않은 경우에는 [A\*](https://en.wikipedia.org/wiki/A*_search_algorithm)("A-star"로 발음)와 같은 다익스트라(Dijkstra) 알고리즘을 기반의 알고리즘이 사용된다. 이 경우 간선의 가중치는 라우팅 수수료를 나타낼 수 있고 전송할 금액보다 큰 용량을 가진 간선만 검색에 포함된다. 이 기본 형태에서 라이트닝 네트워크의 경로 찾기는 매우 간단하고 직관적이다.
+
+그러나 채널 유동성을 발신자가 알 수 없다. 이점은 간단한 이론적 컴퓨터 과학 문제를 다소 복잡한 실제 문제로 바꾸어 놓는다. 이제 우리는 부분적인 지식만으로 경로 찾기 문제를 해결해야 한다. 예를 들어, 어떤 간선의 용량이 충분히 커 보이기 때문에 지불을 전달할 수 있는 간선인지 의심할 수 있다. 하지만 직접 사용해 보거나 채널 소유자에게 직접 물어보지 않는 한 확신할 수 없다. 채널 소유자에게 직접 물어볼 수 있다고 해도, 다른 채널 소유자에게 물어보고 경로를 계산하고 어니언을 구성하여 전송할 때쯤이면 잔액이 변경될 수 있다. 우리가 가진 정보가 제한적일 뿐만 아니라 우리가 가진 정보는 매우 동적이며 우리가 모르는 사이에 언제든지 변경될 수 있다.
+
+<br>
+
+### 단순화하기
+
+라이트닝 노드에 구현된 경로 찾기 메커니즘은 먼저 특정 기능에 따라 필터링 및 정렬된 후보 경로 목록을 생성하는 것이다. 그런 다음 노드나 지갑은 결제를 성공적으로 전달하는 경로를 찾을 때까지 결제를 전달하는 시도를 함으로써 시행착오를 반복하여 경로를 탐색한다.
+
+<table>
+  <td>참고</td>
+  <td>이러한 맹목적 프로빙(blind probing)은 라이트닝 노드나 지갑에서 수행하며 소프트웨어 사용자가 직접 관찰하지는 않다. 그러나 결제가 즉시 완료되지 않으면 사용자는 프로빙이 진행 중이라고 의심할 수 있다.</td>
+<table>
+
+블라인드 프로빙이 최적은 아니며 개선의 여지가 많지만, 이 간단한 전략도 소규모 결제와 잘 연결된 노드에서는 놀랍도록 잘 작동한다는 점에 유의해야 한다.
+
+대부분의 라이트닝 노드와 지갑 구현은 후보 경로 목록에 순서를 매기거나 가중치를 부여하여 이 접근 방식을 개선한다. 일부 구현은 수수료 또는 수수료와 용량의 조합을 기준으로 후보 경로의 순서를 정한다.
+
+<br>
+
+## 경로 찾기와 결제 전달 프로세스
+
+경로 찾기 및 결제 전달에는 여러 단계가 포함되며, 여기에 나열된 단계가 있다. 구현마다 다른 알고리즘과 전략을 사용할 수 있지만 기본 단계는 매우 유사할 가능성이 높다.
+
+1. 각 채널의 용량이 포함된 공지와 업데이트로 채널 그래프를 만들고, 보내려는 금액에 비해 용량이 부족한 채널은 무시하고 그래프를 필터링한다.
+
+2. 발신자와 수신자를 연결하는 경로를 찾는다.
+
+3. 경로에 일정한 가중치를 부여한다. 이는 이전 단계 알고리즘의 일부일 수 있다.
+
+4. 결제가 성공할 때까지 각 경로를 순서대로 시도한다.(시행착오 루프)
+
+5. 선택적으로 반환된 HTLC 실패를 사용하여 그래프를 업데이트하여 불확실성을 줄인다.
+
+이 단계들을 세 가지 주요 활동으로 나눌 수 있다.
+
+- 채널 그래프 구성
+
+- 경로 찾기(일부 휴리스틱에 의해 필터링 및 정렬)
+
+- 결제 시도
+
+실패 반환을 사용하여 그래프를 업데이트하거나 다중 분할 결제를 수행하는 경우 결제 라운드에서 이 세 가지 활동을 반복할 수 있다. ([다중 분할 결제 참조](./ch12.md/#다중-분할-결제)).
+
+다음 섹션에서는 이러한 각 단계와 고급 결제 전략에 대해 더 자세히 살펴보자.
+
+<br>
+
+## 채널 그래프 구성하기
+
+[11장](./ch11.md)에서는 노드가 가십에 사용하는 세 가지 주요 메시지인 node_announcement, channel_announcement, channel_update에 대해 다루었다. 이 세 가지 메시지를 통해 모든 노드는 채널 그래프 형태로 라이트닝 네트워크의 "지도"를 점진적으로 구성할 수 있다. 이러한 각 메시지는 채널 그래프에 중요한 정보를 제공한다.
+
+**_node_announcement_** <br>
+여기에는 노드 ID(공개키), 네트워크 주소(예: IPv4/6 또는 Tor), 기능/특징 등 라이트닝 네트워크의 노드에 대한 정보가 포함되어 있다.
+
+**_channel_announcement_** <br>
+여기에는 두 노드 간의 공개 채널의 용량과 채널 ID, 채널의 존재와 소유권에 대한 증거가 포함된다.
+
+**_channel_update_** <br>
+여기에는 지정된 채널을 통해 나가는 결제를 라우팅하기 위한 노드의 수수료와 타임락(CLTV) 기대치가 포함되어 있다.
+
+수학적 그래프에 비유하자면, node_announcement는 그래프의 노드 또는 정점을 생성하는 데 필요한 정보이다. channel_announcement를 통해 결제 채널을 나타내는 그래프의 간선을 생성할 수 있다. 결제 채널의 각 방향마다 고유한 잔액이 있으므로 방향성 그래프를 생성한다. channel_update를 사용하면 수수료와 타임락을 통합하여 그래프 간선의 비용 또는 가중치를 설정할 수 있다.
+
+경로 탐색에 사용할 알고리즘에 따라 그래프 간선에 여러 가지 비용 함수를 설정할 수 있다.
+
+여기서는 비용 함수는 무시하고 node_announcement 및 channel_announcement 메시지를 사용하여 노드와 채널을 보여주는 채널 그래프를 간단히 설정해 보겠다.
+
+이 장에서는 셀레나가 라시드에게 100만 사토시를 지불하는 경로를 찾는 방법을 살펴보겠다. 먼저 셀레나는 라이트닝 네트워크 가십의 정보를 사용하여 노드와 채널을 발견하기 위해 채널 그래프를 구성한다. 그런 다음 셀레나는 채널 그래프를 탐색하여 라시드에게 송금할 수 있는 경로를 찾는다.
+
+이것이 셀레나의 채널 그래프이다. 절대적인 채널 그래프와 같은 것은 존재하지 않으며, 채널 그래프는 항상 채널 그래프를 구성한 노드의 관점에서만 존재한다. (아래 지도-영토 관계 참조)
+
+<table>
+  <td>팁</td>
+  <td>셀레나는 결제를 전송할 때만 채널 그래프를 구성하는 것이 아니다. 오히려 셀레나의 노드는 지속적으로 채널 그래프를 구축하고 업데이트한다. 셀레나의 노드가 시작되어 네트워크의 피어와 연결되는 순간부터 가십에 참여하고 모든 메시지를 사용하여 네트워크에 대해 최대한 많은 것을 학습한다.</td>
+</table>
+<br>
+
+**지도-영토 관계**(Map-Territory Relation)<br>
+[위키백과의 지도-영토 관계 페이지(https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation)에서 "지도-영토 관계는 지리적 영역과 지도 사이의 관계에서와 같이 객체와 해당 객체의 표현 사이의 관계를 설명한다."라고 설명한다.
+
+지도와 영토의 관계는 루이스 캐럴의 단편 소설 '실비와 브루노의 결론'에서 가장 잘 설명되어 있는데, 이 소설에서는 지도가 표시하는 영토를 1:1 축척으로 축소한 가상의 지도가 완벽한 정확도를 갖지만 펼치면 전체 영토를 덮기 때문에 완전히 쓸모없게 된다는 이야기가 나온다.
+
+이것이 라이트닝 네트워크에 어떤 의미가 있을까? 라이트닝 네트워크는 영역이며, 채널 그래프는 해당 영역의 지도이다.
+
+라이트닝 네트워크의 완전한 최신 지도를 나타내는 이론적(플라톤적 이상 - 현실에서 불가능함을 나타냄.) 채널 그래프를 상상할 수 있지만, 그러한 지도는 라이트닝 네트워크 그 자체일 뿐이다. 각 노드에는 공지로 구성된 자체 채널 그래프가 있으며, 이는 불완전하고 부정확하며 오래된 것일 수밖에 없다!
+
+지도는 결코 영토를 완전하고 정확하게 묘사할 수 없다.
+
+셀레나는 node_announcement 메시지를 수신하고 의도한 수신자인 라시드 외에 다른 네 개의 노드를 발견한다. 결과 그래프는 6개의 노드로 구성된 네트워크를 나타낸다. 셀레나와 라시드는 각각 발신자와 수신자이며, 앨리스, 밥, 자비에, 얀은 중개 노드이다. 셀레나의 초기 그래프는 그림 3.에 표시된 노드 목록일 뿐이다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1203.png" width="650">
+      그림 3. 노드 공지
+  </figure>
+
+<br/>
+<br/>
+
+셀레나는 또한 해당 채널 용량에 해당하는 7개의 channel_announcement 메시지를 수신하여 채널 그래프에 표시된 네트워크의 기본 "지도"를 구성할 수 있다. (Alice, Bob, Selena, Xavier, Yan, Rashid라는 이름은 각자의 이니셜 A, B, S, X, R로 대체되었다.)
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1204.png" width="650">
+      그림 4. 채널 그래프
+  </figure>
+
+<br/>
+<br/>
+
+#### 채널 그래프에서의 불확실성
+
+채널 그래프에서 볼 수 있듯이 셀레나는 채널의 잔액을 전혀 알지 못한다. 셀레나의 초기 채널 그래프에는 가장 높은 수준의 불확실성을 포함한다.
+
+하지만 잠깐, 셀레나는 채널 잔액을 일부 알고 있다! 그녀는 자신의 노드가 다른 노드와 연결한 채널의 잔액을 알고 있다. 이는 별것 아닌 것처럼 보이지만, 사실 경로를 구성하는 데 매우 중요한 정보이다. 셀레나는 자신의 채널의 실제 유동성을 알고 있기 때문이다. 이 정보를 표시하기 위해 채널 그래프를 업데이트해 보겠다. 알려진 잔액과 알려지지 않은 잔액이 있는 채널 그래프에서와 같이 알려지지 않은 잔액을 나타내기 위해 "?" 기호를 사용하겠다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1205.png" width="650">
+      그림 5. 알려진 잔액과 알려지지 않은 잔액이 있는 채널 그래프
+  </figure>
+
+<br/>
+<br/>
+
+"?" 기호가 불길해 보이지만, 확실성이 부족하다고 해서 완전한 무지와 같은 것은 아니다. 시도한 HTLC의 성공/실패로 그래프를 업데이트하여 불확실성을 정량화하고 줄일 수 있다.
+
+우리는 가능한 최대 및 최소 유동성을 알고 있고 더 작은(더 정확한) 범위에 대한 확률을 계산할 수 있기 때문에 불확실성을 정량화할 수 있다.
+
+HTLC 전송을 시도하면 채널 잔액에 대해 자세히 알 수 있다. 전송 성공하면 잔액이 적어도 특정 금액을 전송하기에 충분하다는 뜻이다. 반면 '일시적 채널 실패' 오류가 발생하면 특정 금액에 대한 유동성이 부족하기 때문일 가능성이 높다.
+
+<table>
+  <td>팁</td>
+  <td>"성공한 HTLC에서 배울 게 뭐가 있나?"라고 생각할 수도 있다. 결국 성공했다면 "끝난 것"이니까. 하지만 여러 부분으로 나뉜 결제의 한 부분을 보내는 것일 수도 있다는 점을 고려해보자. 또한 짧은 시간 내에 다른 단일 부분 결제를 전송할 수도 있다. 유동성에 대해 배운 모든 것은 다음 시도에 유용하다!</td>
+</table>
+
+<br>
+
+### 유동성 불확실성과 확률
+
+채널의 유동성의 불확실성을 정량화하기 위해 확률 이론을 적용할 수 있다. 결제 전달 확률에 대한 기본 모델을 통해 다소 뻔하지만 중요한 결론을 도출할 수 있다.
+
+- 결제 금액이 작을수록 경로를 통해 성공적으로 전달될 확률이 높다.
+
+- 용량이 큰 채널일수록 특정 금액에 대한 결제 전달 확률이 높다.
+
+- 채널(홉)이 많을수록 성공 확률은 낮아진다.
+
+이는 당연한 이야기일 수 있지만, 특히 여러 번에 걸친 결제를 사용할 때 중요한 의미를 갖는다. (여러 번에 걸친 결제 참조) 수학은 어렵지 않다.
+
+확률 이론을 사용하여 이러한 결론에 어떻게 도달했는지 살펴보자.
+
+먼저, 용량 c를 가진 채널의 한쪽에 (0, c) 또는 "0과 c 사이의 범위"의 알 수 없는 값을 가진 유동성이 있다고 가정해 보자. 예를 들어 용량이 5인 경우 유동성은 (0, 5) 범위에 있을 것이다. 이제 유동성이 정확히 5가 되어야만 성공할 수 있기 때문에 5개의 사토시를 보내려는 경우 성공 확률은 6분의 1(16.66%)에 불과하다는 것을 알 수 있다.
+
+더 간단하게 설명하자면, 유동성의 가능한 값이 0, 1, 2, 3, 4, 5인 경우 6개의 가능한 값 중 하나만 있어도 결제를 전송할 수 있다. 이 예제를 계속 진행하기 위해 결제 금액이 3이라면 유동성이 3, 4 또는 5이면 성공할 수 있다. 따라서 성공 확률은 6분의 3(50%)이다. 단일 채널의 성공 확률 함수를 수학으로 표현하면 다음과 같다.
+
+$P_c(a) = (c + 1 - a) / (c + 1)$ (a: 금액, c: 용량)
+
+이 방정식에서 보낼 금액이 0에 가까우면 확률이 1에 가까워지고, 금액이 용량을 초과하면 확률이 0이 된다는 것을 알 수 있다.
+
+다시 말해 "결제 금액이 작을수록 성공적으로 전달될 확률이 높다" 또는 "용량이 큰 채널일수록 특정 금액에 대한 전달 확률이 높다", "용량이 부족한 채널에서는 결제를 전송할 수 없다"는 뜻이다.
+
+이제 여러 채널로 구성된 경로의 성공 확률에 대해 생각해 보자. 첫 번째 채널의 성공 확률이 50%라고 가정해 보자.(P = 0.5) 두 번째 채널의 성공 확률이 50%(P = 0.5)라면 전체 성공 확률은 25%(P = 0.25)라는 것을 직관적으로 알 수 있다.
+
+이를 경로의 각 채널에 대한 확률의 곱으로 결제 성공 확률을 계산하는 방정식으로 표현할 수 있다.
+
+$P_{payment} = \prod_{i=1}^n P_i$ <br>
+여기서 $P_i$는 하나의 경로 또는 채널에서 성공할 확률이고, $P_{payment}$는 모든 경로/채널에서 결제에 성공할 전체 확률이다.
+
+이 방정식에서 단일 채널에서의 성공 확률은 항상 1보다 작거나 같기 때문에 여러 채널에서의 확률은 기하급수적으로 감소한다는 것을 알 수 있다.
+
+즉, "더 많은 채널(홉)을 사용할수록 성공 확률이 낮아진다"는 뜻이다.
+
+<table>
+  <td>참고</td>
+  <td>채널의 유동성 불확실성 뒤에는 많은 수학적 이론과 모델링이 있다. 채널 유동성의 불확실성 구간을 모델링하는 기본적인 작업은 이 책의 공저자인 Pickhardt 등이 작성한 논문
+  <a href="https://arxiv.org/abs/2103.08576">"Security and Privacy of Lightning Network Payments with Uncertain Channel Balances(불확실한 채널 잔액을 사용한 라이트닝 네트워크 결제의 보안 및 개인정보 보호)"</a>에서 확인할 수 있다.</td>
+</table>
+<br>
+
+### 수수료 및 기타 채널 지표
+
+다음으로, 발신자는 중개 노드에서 받은 channel_update 메시지에서 정보를 그래프에 추가한다. 채널 업데이트에는 채널에 대한 풍부한 정보와 채널 파트너 중 한 명의 기대치가 포함되어 있다.
+
+채널 그래프 수수료 및 기타 채널 지표에서 셀레나가 A, B, X, Y의 channel_update 메시지를 기반으로 채널 그래프를 업데이트하는 방법을 확인할 수 있다. channel_flags에 포함된 채널 ID와 채널 방향은 셀레나에게 이 업데이트가 어떤 채널과 어떤 방향을 가리키는지 알려준다. 각 채널 파트너는 하나 이상의 channel_update 메시지를 통해 채널에 대한 예상 수수료 및 기타 정보를 알린다. 예를 들어 왼쪽 상단에는 채널 A—​B와 A에서 ​B 방향으로 앨리스가 보낸 channel_update가 표시된다. 이 업데이트를 통해 앨리스는 특정 채널을 통해 밥에게 HTLC를 라우팅하기 위해 네트워크에 얼마의 수수료를 부과할지 알려준다. 밥은 완전히 다른 예상 수수료로 반대 방향에 대한 채널 업데이트를 발표할 수 있다.(이 다이어그램에는 표시되지 않음) 모든 노드는 언제든지 새로운 channel_update를 전송하여 수수료 또는 타임락 기대치를 변경할 수 있다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1206.png" width="650">
+      그림 6. 채널 그래프 수수료 및 기타 채널 지표
+  </figure>
+
+<br/>
+<br/>
+
+수수료와 타임락 정보는 경로 선택 지표로서 뿐만 아니라 매우 중요하다. [10장 어니언 라우팅](./ch10.md)에서 살펴본 것처럼 발신자는 어니언을 만들기 위해 각 홉에서 수수료와 타임락(cltv_expiry_delta)을 합산해야 한다. 각 중개 홉은 다음 홉으로 보낼 발신 HTLC보다 더 높은 금액과 만료 타임락을 가진 수신 HTLC를 기대하기 때문에 수신자에서 발신자까지 경로를 따라 거꾸로 수수료 계산 프로세스가 진행된다. 예를 들어 밥이 라시드에게 송금할 때 수수료 1,000사토시와 만료 타임락 델타 30블록을 원한다면, 앨리스가 보내는 HTLC에 해당 금액과 만료 델타를 추가해야 한다.
+
+또한 채널은 결제 금액뿐만 아니라 이후 모든 홉의 누적 수수료에 대해서도 충분한 유동성을 보유해야 한다는 점도 중요하다. 셀레나가 자비에에게 보내는 채널(S→X)은 100만 사토시를 결제하기에 충분한 유동성을 가지고 있지만, 수수료를 고려하면 유동성이 충분하지 않다. 결제와 모든 수수료에 대해 충분한 유동성을 가진 경로만 고려하기 때문에 수수료를 알아야 한다.
+
+<br>
+
+## 후보 경로 찾기
+
+이와 같이 방향이 지정된 그래프에서 적합한 경로를 찾는 것은 잘 연구된 컴퓨터 과학 문제로, 원하는 최적화 및 리소스 제약 조건에 따라 다양한 알고리즘으로 해결할 수 있다.(일반적으로 최단 경로 문제라 한다.)
+
+이 문제를 해결하는 가장 유명한 알고리즘은 1956년 네덜란드의 수학자 E. W. Dijkstra가 발명한 것으로, 간단히 Dijkstra 알고리즘이라고 불린다. 원래의 Dijkstra 알고리즘 외에도 휴리스틱 기반 알고리즘인 A\*와 같은 다양한 변형 및 최적화 알고리즘이 있다.
+
+앞서 언급했듯이 수신자에서 발신자까지 누적되는 수수료를 고려하기 위해 '검색'을 역으로 적용해야 한다. 따라서 Dijkstra, A\* 또는 다른 알고리즘은 수수료, 예상 유동성, 타임락 델타(또는 일부 조합)를 각 홉의 비용 함수로 사용하여 수신자에서 발신자까지의 경로를 검색한다.
+
+셀레나는 이러한 알고리즘 중 하나를 사용하여 최단 경로를 기준으로 정렬한, 라시드로 가는 몇 가지 가능한 경로를 계산한다.
+
+1. S→A→B→R
+
+2. S→X→Y→R
+
+3. S→X→B→R
+
+4. S→A→B→X→Y→R
+
+하지만 앞서 살펴본 바와 같이, 수수료를 고려하면 S→X 채널은 100만 사토시 결제를 위한 충분한 유동성을 가지고 있지 않다. 따라서 경로 2와 3은 실행 가능하지 않다. 따라서 경로 1과 4가 가능한 결제 경로로 남다.
+
+셀레나는 두 가지 가능한 경로를 통해 전송을 시도할 준비가 되었다!
+
+<br>
+
+## 결제 전달 (시행착오 루프)
+
+셀레나의 노드는 HTLC를 구성하고, 어니언을 구축하고, 결제 전송을 시도함으로써 시행착오 루프를 시작한다. 각 시도마다 세 가지 결과가 발생할 수 있다.
+
+- 성공적인 결과(update_fulfill_htlc)
+
+- 오류(update_fail_htlc)
+
+- 응답 없는 결제 중단(성공도 실패도 아님.)
+
+결제가 실패하면 그래프를 업데이트(채널의 지표 변경)하고 대체 경로를 다시 계산하여 다른 경로를 통해 결제를 다시 시도할 수 있다.
+
+결제가 실패하면 그래프를 업데이트(채널의 지표 변경)하고 대체 경로를 다시 계산하여 다른 경로를 통해 결제를 다시 시도할 수 있다.
+
+[결제 중단]에서 결제가 중단되면 어떤 일이 발생하는지 살펴보았다. 중요한 세부 사항은 결제가 중단되면 다른 HTLC로 재시도할 수 없기 때문에 결국 (중단된 결제와 재시도한 결제) 모두 진행되어 이중 결제가 발생할 수 있기 때문에 최악의 결과라는 점이다.
+
+<br>
+
+### 첫 번째 시도 (Path #1)
+
+셀레나는 첫 번째 경로(S→A→B→R)를 시도한다. 그녀는 어니언을 구성하여 전송하지만 밥의 노드로부터 실패 코드를 수신한다. 밥은 B→R 채널을 전달할 수 없는 채널로 식별하는 channel_update를 통해 일시적인 채널 실패를 보고한다. 이 시도는 그림 7.과 같다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1207.png" width="700">
+      그림 7. Path #1 시도가 실패한다.
+  </figure>
+
+<br/>
+
+#### 실패로부터 학습하기
+
+셀레나는 이 실패 코드를 통해 밥이 해당 채널에서 라시드에게 지불금을 전달하기에 충분한 유동성을 가지고 있지 않다고 추론할 수 있다. 중요한 점은 이 실패가 해당 채널의 유동성에 대한 불확실성을 좁힌다는 것이다! 이전에는 셀레나의 노드가 채널에서 밥 측의 유동성이 (0, 400만) 범위 어딘가에 있다고 가정했다. 이제 셀레나는 유동성이 (0, 999999) 범위에 있다고 가정할 수 있다. 마찬가지로 셀레나는 이제 라시드 측 채널의 유동성이 (0, 400만)가 아닌 (100만, 400만) 범위에 있다고 가정할 수 있다. 셀레나는 이번 실패를 통해 많은 것을 배웠다.
+
+### 두 번째 시도 (Path #4)
+
+이제 셀레나는 네 번째 후보 경로(S→A→B→X→Y→R)를 시도한다. 이 경로는 더 긴 경로이며 더 많은 수수료가 발생하지만 지금으로썬 지불금을 전달할 수 있는 최상의 옵션이다.
+
+다행히 그림 8.처럼 결제가 성공했음을 나타내는 update_fulfill_htlc 메시지를 앨리스로부터 수신한다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1208.png" width="700">
+      그림 8. Path #4 시도가 성공한다.
+  </figure>
+
+<br/>
+
+#### 성공으로부터 학습하기
+
+셀레나는 이 성공적인 결제를 통해 많은 것을 배웠다. 이제 셀레나는 S→A→B→X→Y→R 경로의 모든 채널에 결제를 전달하기에 충분한 유동성이 있다는 것을 알게 되었다. 또한 각 채널이 HTLC 금액(100만 달러 + 수수료)을 채널의 다른 쪽 끝으로 이동했다는 사실도 알게 되었다. 이를 통해 셀레나는 해당 경로에 있는 모든 채널의 수신 측 유동성 범위를 다시 계산하여 최소 유동성을 1백만 달러 + 수수료로 대체할 수 있다.
+
+#### 케케묵은 지식?
+
+셀레나는 이제 라이트닝 네트워크에 대한 훨씬 더 나은 '지도'를 갖게 되었다.(적어도 이 7개 채널에 관한 한) 이 지식은 이후 셀레나가 결제를 시도할 때 유용하게 사용될 것이다.
+
+그러나 이 지식은 다른 노드가 결제를 전송하거나 라우팅함에 따라 다소 "케케묵은(stale)" 정보가 된다. 셀레나는 송금자가 아닌 이상 이러한 결제 내역을 전혀 볼 수 없다. 셀레나가 결제 라우팅에 관여하더라도 어니언 라우팅 메커니즘은 셀레나가 한 홉(자신의 채널)에 대한 변경 사항만 볼 수 있음을 의미한다.
+
+따라서 셀레나의 노드는 이 지식이 오래되어 더 이상 유용하지 않다고 가정하기 전에 이 지식을 얼마나 오래 보관할지 고려해야 한다.
+
+<br>
+
+## 다중 분할 결제
+
+다중 분할 결제(multipart payments, MPP)는 2020년 라이트닝 네트워크에 도입된 기능으로, 이미 널리 사용되고 있다. 다중 분할 결제를 사용하면 결제를 여러 부분으로 분할하여 여러 경로를 통해 의도한 수취인에게 HTLC로 전송할 수 있으므로 전체 결제의 원자성을 유지할 수 있다. 여기서 원자성이란 결제의 모든 HTLC 부분이 최종적으로 이행되거나 전체 결제가 실패하고 모든 HTLC 부분이 실패하는 것을 의미한다. 부분적으로 결제가 성공할 가능성은 없다.
+
+다중 분할 결제는 단일 채널에 "맞지 않는" 금액을 충분한 유동성이 있는 작은 금액으로 분할하여 전송할 수 있기 때문에 라이트닝 네트워크에서 중요한 개선 사항이다. 또한, 다중 분할 결제는 단일 경로 결제에 비해 결제 성공 확률을 높이는 것으로 나타났다.
+
+<table>
+  <td>팁</td>
+  <td>이제 MPP를 사용할 수 있으므로 단일 경로 결제를 MPP의 하위 범주로 생각하는 것이 가장 좋다. 기본적으로 단일 경로는 크기 1의 여러 부분일 뿐이다. 결제 규모와 사용 가능한 유동성으로 인해 단일 부분으로 전달이 불가능한 경우를 제외하고는 모든 결제를 다중 분할 결제로 간주할 수 있다.</td>
+</table>
+<br>
+
+### MPP 사용하기
+
+MPP는 사용자가 선택하는 것이 아니라 노드 경로 찾기 및 결제 전달 전략이다. 그래프 생성, 경로 선택, 시행착오 루프와 같은 기본 단계는 동일하게 구현된다. 차이점은 경로를 선택하는 동안 전송을 최적화하기 위해 결제를 분할하는 방법도 고려해야 한다는 점이다.
+
+이 예제에서는 MPP를 통해 경로 찾기 문제를 즉각적으로 개선할 수 있는 몇 가지 방법을 확인할 수 있다. 먼저, 100만 사토시와 수수료를 전송하기에 유동성이 충분하지 않은 것으로 알려진 S→X 채널을 활용할 수 있다. 해당 채널을 따라 더 작은 부분을 전송함으로써 이전에는 사용할 수 없었던 경로를 사용할 수 있다. 둘째, 100만 사토시를 전송하기에는 부족하지만 더 적은 양을 전송하는 데는 충분할 수 있는 유동성이 알려지지 않은 B→R 채널이 있다.
+
+#### 결제 쪼개기
+
+근본적인 질문은 지불을 분할하는 방법이다. 보다 구체적으로, 최적의 분할 횟수와 각 분할에 대한 최적의 금액은 얼마일까?
+
+이는 새로운 전략이 등장하고 있는 지속적인 연구 분야이다. 다중 분할 결제는 단일 경로 결제와는 다른 알고리즘 접근 방식을 따르지만, 다중 분할 최적화를 통해 단일 경로 솔루션이 나올 수도 있다.(즉, 단일 경로가 다중 분할 경로 찾기 알고리즘이 제안하는 최적 솔루션일 수 있다.)
+
+기억하겠지만, 유동성/잔액의 불확실성은 MPP 경로 찾기에 적용할 수 있는 몇 가지 (다소 당연한) 결론으로 이어진다는 사실을 발견했다.
+
+- 소액 결제일수록 성공 확률이 높다.
+
+- 더 많은 채널을 사용할수록 성공 확률은 (기하급수적으로) 낮아진다.
+
+첫 번째 인사이트를 통해 큰 금액(예: 100만 사토시)을 작은 금액으로 분할하면 각각의 작은 금액이 성공할 확률이 높아진다는 결론을 내릴 수 있다. 더 적은 금액을 송금하면 유동성이 충분한 경로의 수가 더 많아질 것이다.
+
+극단적으로 생각해보면 100만 사토시 결제를 100만 개의 개별 사토시로 분할하는 것은 어떨까? 두 번째 인사이트에 답이 있다. 백만 개의 단일 사토시 HTLC를 전송하는 데 더 많은 채널/경로를 사용하게 되므로 성공 확률이 기하급수적으로 떨어질 것이다.
+
+앞의 두 가지 인사이트는 성공 가능성을 극대화할 수 있는 최적의 지점(sweet spot)을 만들어낸다. 즉, 분할을 너무 많이 하지 않으면서도 작은 단위로 분할하는 것이다!
+
+주어진 채널 그래프에서 분할 크기와 분할 횟수의 최적 균형을 정량화하는 것은 이 책의 범위를 벗어나는 것이지만, 현재 활발히 연구되고 있는 분야이다. 현재 일부 구현에서는 결제를 2분의 1, 4분의 1 등으로 분할하는 매우 간단한 전략을 사용한다.
+
+<table>
+  <td>참고</td>
+  <td>결제를 여러 크기로 분할하여 경로에 할당할 때 관련된 최소 비용 흐름이라는 최적화 문제에 대해 자세히 알아보려면 이 책의 공저자인 René Pickhardt와 Stefan Richter가 작성한 논문 <a href="https://arxiv.org/abs/2107.05322">"Optimally Reliable & Cheap Payment Flows on the Lightning Network(라이트닝 네트워크에서 최적으로 안정적이고 저렴한 결제 흐름)"</a>을 참조하자.</td>
+<table>
+<br>
+
+예시에서 셀레나의 노드는 100만 사토시 결제를 각각 60만과 40만 사토시로 분할하여 두 개의 다른 경로로 보내려고 시도한다. 이는 그림 9.와 같다.
+
+이제 S→X 채널을 사용할 수 있고 (셀레나에게는 운 좋게도) B→R 채널에 60만 사토시를 위한 충분한 유동성이 있기 때문에 이전에는 불가능했던 경로를 통해 두 부분으로 분할하는 데 성공했다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1209.png" width="700">
+      그림 9. 분할 결제의 두 부분으로 보내기
+  </figure>
+
+<br/>
+
+### 여러 번의 시도에 걸친 시행착오
+
+다중 분할 결제를 사용하면 결제 전달 과정에서 다소 수정된 시행착오 루프가 발생한다. 각 시도에서 여러 경로를 시도하기 때문에 네 가지 결과가 발생할 수 있다.
+
+- 모든 부분이 성공하여 결제가 성공한다.
+
+- 일부만 성공하고 일부는 실패하여 오류가 반환된다.
+
+- 모두 실패하고 오류가 반환된다.
+
+- 일부분이 중단되고 오류가 반환되지 않는다.
+
+두 번째, 일부만 실패하여 오류가 반환되고 일부가 성공하는 경우, 이제 시행착오 루프를 반복할 수 있지만 잔여량에 대해서만 반복할 수 있다.
+
+예를 들어 셀레나가 라시드에게 도달할 수 있는 수백 개의 가능한 경로가 있는 훨씬 더 큰 채널 그래프를 가지고 있다고 가정해 보자. 셀레나의 경로 찾기 알고리즘은 다양한 크기의 26개 부분으로 구성된 최적의 결제 분할을 찾을 수 있다. 첫 번째 시도에서 26개의 분할을 모두 전송하려고 시도한 후, 그 중 3개의 분할이 오류로 실패했다.
+
+이 3개의 분할이 예를 들어 155,000 사토시로 구성된 경우, 셀레나는 155,000 사토시에 대해서만 경로 찾기 작업을 다시 시작한다. 다음 시도에서는 완전히 다른 경로(잔여량 155,000 사토시에 최적화된 경로)를 찾고, 155,000 사토시를 완전히 다른 분할로 나눌 수 있다!
+
+<table>
+  <td>팁</td>
+  <td>26번의 분할이 많은 것 같지만, 라이트닝 네트워크에서 테스트한 결과 345번으로 분할하여 0.3679 BTC를 성공적으로 지급한 적이 있다.</td>
+</table>
+<br>
+
+또한 셀레나의 노드는 첫 번째 시도의 성공과 실패를 통해 수집한 정보를 사용하여 채널 그래프를 업데이트하여 두 번째 시도에서 가장 최적의 경로와 분할을 찾다.
+
+셀레나의 노드가 155,000 사토시의 잔액을 보내는 가장 좋은 방법은 80,000 사토시, 42,000 사토시, 15,000 사토시, 11,000 사토시, 65,000 사토시, 500 사토시로 6등분하는 것이라고 계산한다고 가정해보자. 다음 시도에서 셀레나는 11,000 사토시 부분이 실패했음을 나타내는 오류 하나만 얻는다. 다시 셀레나는 수집한 정보를 기반으로 채널 그래프를 업데이트하고 경로 탐색을 다시 실행하여 11,000 사토시의 잔여분을 전송한다. 이번에는 각각 6000 사토시와 5000 사토시 두 개를 전송하는 데 성공한다.
+
+MPP를 사용하여 여러 차례에 걸쳐 결제를 전송하는 이 예는 그림 10.과 같다.
+
+<br/>
+
+  <figure>
+    <img src="https://github.com/lnbook/lnbook/raw/develop/images/mtln_1210.png" width="700">
+      그림 10. MPP로 여러 차례에 걸쳐 결제 보내기
+  </figure>
+
+<br/>
+<br/>
+
+결국 셀레나의 노드는 세 번의 경로 탐색을 통해 1백만 개의 사토시를 30개 부분으로 나누어 전송했다.
+
+<br>
+
+## 결론
+
+이 장에서는 경로 찾기와 결제 전달에 대해 살펴보았다. 채널 그래프를 사용하여 발신자에서 수신자까지의 경로를 찾는 방법을 살펴보았다. 또한 발신자가 후보 경로에서 결제 전달을 시도하고 시행착오를 반복하는 과정도 살펴봤다.
+
+또한 발신자 관점에서 채널 유동성의 불확실성과 이것이 경로 찾기에 미치는 영향도 살펴보았다. 불확실성을 정량화하고 확률 이론을 사용하여 몇 가지 유용한 결론을 도출할 수 있는 방법을 살펴봤다. 또한 성공적인 결제와 실패한 결제를 통해 학습함으로써 불확실성을 줄일 수 있는 방법도 확인했다.
+
+마지막으로, 새로 배포된 다중 분할 결제 기능을 통해 결제를 여러 부분으로 분할하여 고액 결제의 성공 확률을 높일 수 있는 방법도 살펴봤다.