From 4833167a229a7288e99f764770e800f10a4d9673 Mon Sep 17 00:00:00 2001
From: Austin Krauss <34213201+Beige-Coffee@users.noreply.github.com>
Date: Mon, 18 Nov 2024 10:18:24 -0800
Subject: [PATCH] Add Probing Documentation & Best Practices (#283)

---
 docs/.vuepress/config.js     |   5 +
 docs/assets/abcd_ln_path.png | Bin 0 -> 15376 bytes
 docs/probing.md              | 328 +++++++++++++++++++++++++++++++++++
 3 files changed, 333 insertions(+)
 create mode 100644 docs/assets/abcd_ln_path.png
 create mode 100644 docs/probing.md

diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
index 6993f2da..43c70726 100644
--- a/docs/.vuepress/config.js
+++ b/docs/.vuepress/config.js
@@ -76,6 +76,7 @@ const docsSidebar = [
       },
       "/key_management",
       "/fee_estimation",
+      "/probing",
       "/examples",
     ],
   },
@@ -240,6 +241,10 @@ module.exports = {
               text: "Fee Estimation",
               link: "/fee_estimation/",
             },
+            {
+              text: "Probing and Path Finding",
+              link: "/probing/",
+            },
             {
               text: "Examples",
               link: "/examples/",
diff --git a/docs/assets/abcd_ln_path.png b/docs/assets/abcd_ln_path.png
new file mode 100644
index 0000000000000000000000000000000000000000..be266a005ee1c691c34ebcbfdc257cdbe2397d3f
GIT binary patch
literal 15376
zcmd_RWmud&(*TMU7Kh^Qg`$fWcXxM(;_fcR9a^k76nA%bclQFt-TiFe&mNxh^ZYzq
z_r05)WF(VhlFTq+^0H!xaJX<_U|@(6;=+nxV34Swaufg>^f^d#*8>Iyu3;`DBrhQ(
zL@e)M`_<ga1PqKS&N{Y5sz)EaPp($8G{^<z^Y2)dLPbL?`(hkns*hTI1IF>~fweE<
zioa5Q0~?!*90h8=G;-ZjDcd<XVL|Xpw(1q<tMJ`_;X}H^r^mt$FOI|^0h{}2{U<T0
zx9o&~@i~&Q7exRczSyQJGRN2)YJ>BB6$z^RL}Oj0x!tm%+E&xB&RtJ0)#4?c$SqEA
zYFdJCUy762nqM51=80|Fi=W$ITCq1IZG?w+yY%LMI#Xj}sJEflzAXncG&A(OW~Sch
zcJb6?hs)-QSVUbE_W}8f`A&8&02=R85di1ov{UXIvpFAGu58#Rid%WnplVX49U!*P
z0G!1vX9#&!AiC{N!>e~sr)6R1ZyKN%np+FOrWd;S7k^4ZNJdG$G^ROaUwWEGk`fk%
z8@E+((P-{76EwgC*c!})rz>}br{GIWXTlTg2TYSv%#u`0kgiot)Fr;k$beCU$^bC%
z5OXjnPzfCL;(}h#u*3(0!GOL$f?nY)i2tdDM9qTypE6j~--ZH8LJ|_7ZzUrK6B8Rp
zGg~J_7{8w&QuF4@>Q3r1(ws)N*7OF(wuUD3Zq{~xQNXy}I6*~g6DI>=H)|^!M@}~$
z(*LyJ1eO1S8Ayr$)5OV=hg4lgo><7%!GxHN9!L))<%J_ACgyf9{>rH+Ec)N*pkF+s
zW=>9aoD2-EuCDa1%=ESnrVNZ692^WlCI%)ZI#3HbM|T@112;MwN3#DS@;`KhO&pCJ
z%<Y`aZEcAE(ls!&b#~$*CH>3jfB*hVP7^ot|Knui_}|?Eb&%n24Fe-Rkl}x6gHXBu
zLOJEl-At@Bgw3r%>H+cKWn^LG{!jb=SIz%%{0FA`|6#I!Vf`oOKWhGssp4qjAY^L|
zV(G;De<SnX$p5VTZ$xf}zdiqlCjLv!|AB(^%nQfO@V{fm3l|vE<_iY)g<e8fK-mra
zBpoIVUF3FPWArOicsMv2w7dZS2aKA%qCK2(x8EBGIcYiA3TKg~-F5-s0w2&wJpy2F
zqzkdZK2QLtr~?cW$qig7pO4hqSZBDnxLRsfcxKkFJToUwoeEFOUvG~NJ#KVWf__T|
z3PO<czk8y{QEZGkKaqidB!2hE_=!Sc_(O^N{o^5~fnXu6?(XaT7Y!EDLdbuCG*Gip
z<1pwyeR@aqV-~6a!FxU*2gAXlLQCx!8DV3={`o`!4&VKTjpbK`G7~lqiU^bVr%-+%
zpghbwIsKrjN%_f0X|$!K-}RN8pDcj$efP;@F~D(AHMR^5|J8q7)Y<o<6Z@9}CPN3|
zu+YB0muoUK3+cV+u*M>OqQa_;$;tmv-d~wTp`71~F8=>}m7<#_aLR@8rC>^F<BYU<
zEYy1|E}(@q{cDsqzxc~*hi#i$|A7@ljM-<7B-GW}lkV5A#KROfuD|Q3B(Kum)3+f8
zPl8oe3ICBe*Eaaf!FW(@X}yhAG+%-CxuP&NLra`E397h6SW@yx_rfu+L1$*)IzdwJ
z=O^zqW;=M;MzJi1HgOI2wX21K22_<gs#}p6^EJ=kiJNGJ6&Ze-9#lJHPj`{1;5`O^
zY74Qq!TQ0V`u!PErb$>1s*puPGzJ)1sHRc3*$QAwwP+Nlx;c;baUt)~Qt1m?GNul6
z+ai8Vv>PndiRnO+t=X@NLfD}AtqYox<Ri$q667{eX&F49uF}!^mSUREaq3vukb&O;
zMpH1p$E-(~lr@NkEctD(*KDO&qJ<XauxcAyds-<A>p!z8ujBIcDcm+&)mdmUR22`@
zF~k?twc?=y2_px({Hl8_;jp}*q6GXMQ?A%{wGW~nPFv25AFmIlt4*X1)>;~BEf?r@
zsySDvX=rw5<oFWKI^J}VICfCXXYyr8WrSJdq?3UH6(K){n&woshSojL(iipee!gaS
zo;LM9&THAyc|TrDlzO@woUS$nbkH@dD!OcVyUqn@_@ezeoGaNasc2VJb@ixe@qW5}
z<kr6*=Q`V85nblFT@>PUJx%NMGi7l;ob7!C5&XPj(_(G7HuOOWd_?)dV&6k_@6BE#
z?6_J>{Wo<0gK!I}|4EXbPuzy@n+~VTF_ra7y^NJ!okha)#Q;&*jSSn8aCo?dq-9-Q
z_DdKfycIZ|uF^*IP$A3ux|KY3Tbr3#*l{g91{(p_k0-vD>+e?eOJ9pIT3wjkgdUeB
zU!4}<f3pS25B~^pT}=)xRS+#f^N4^>gG5G@+DnI1vrVGaAU&Ed`)*yo^l96*sfshm
zp&7SMn}RAtfp8@+`{lM)KwY;<`<Jz693!$Yc~0e*?1p^a7E$k8&H7=!yjC34qW&H~
zcuTBu*)02>WNcoqMs0^7iU3JI;~qrz*@U-mNSstgiKgRep9ctB(`a>D)eC5pD1Mt4
zq<_j4jha3x<X(viPj_9{P-`8ND3DGeg&}my(nwH}<53~>eZJ^z#=_FSPxHQAy6i=h
zBd=a)^K^CJ3c{)-iCr|)a=V#R+dc0=Zm=$DbGsa(908$GFtp$2;5*MMgr$FjMvV77
zYh$nSS#w?(x>?Z6RQKJ_4sp``h=;H4cQLstNTS0g&&Xvf9_DnW(n!S4m89qUqT;e*
z&2H@#gU_Kj&U3fgYttIxy5_8A_yQuZ0NuP~cU(0v{7d5dXfds3t$00Xe0x1e=o^a~
zuyhqjbrM_yNHrIrkqK$3W(=#6EqG|-wqy8oU#~LX2K(`BOHmbk@d`d0ovI}OZ-$(6
zTM4pSEnZY!jBcpo=7(I``b|a$iY5nxIX@gS!DG_K61c81Zm&fW@##V%;j2?34$sK(
zJ_y^M&6Ol&l|u>`ZC&n;<cYwK$i%qn=SHzjM+q!;^kHfZPUlHgVSi!NrEeJ41Y`DS
z(RF7Xo(a6(g|pC=^fcn{%=uYWDA;AU?gz%N+%L+jk^ff7Td8Lvs>U;I93KRaH7tUq
z^GlCYS#~q%{-j~UDTol`&!cf)IL4z%5V-&RJ!n<wG}Oir@@TI6Je|~rjHR;6`P^@X
z^tQ8acrjNUCk0g*4Ol?t<m3pBb6-h&pJjUArf7Rz^xdpOXfh1X;TgPr>oPIE8e?aV
zsPoxy+m6yavN>mp!T!)gn7+_-DbOR+dC#-=OR}s2ey<OT4k?J*tS_hwVM58Mw;X25
zOj+LxtGO^(l&)!VW#;Yc0Udp)4`vXx<$P&e$MY@&ll!HyK!cE*z?5JFbS#?e7Xe$T
zf#652B)IF_*Op=(8e4<pEN&vcc?;~))Nh;C0`B3^95dL<$y{lSM!}`pP1WN>ttJOh
z&N;3d-t1NI3fSkLumYsr@KM=LS(tErCbeeG_q-GF-3E_Gc5TO_04?BKi5IbOlh|lL
zO)vs?v+z~#yS3(Xv1C-ih{<lKGjQss`!BPUW+Vd<&`DcZdR`=j+Il_@yVDJ}8-a5+
ze3<Kqp>3pAiDSH;9u@T8u%JYH$YQv2&hU=Ra9;nU+E%KIy<Qjancq=sm;O0RF$Ec4
zlxn9L8TL6&=rYeTtp-eNw|o`IEjo~en>n5B5B@pFY5o(VR<S5J0r#b9waz@AqZzip
zw@6HFxKZq9ens@xPso(1U+i<74yHwPJx}VOE0BaR3@ZY&oe`j0mlif9Abx^nOWEMI
z6)k2pG!k+)U>0|h1y>UW3}XqhD4Yt(SN-JkZP#Uci;PzEMMS-}cWS8m<W6BZq&!?%
z?;>-!u3y>{+jdgF;?%Uf7>wh%2ZSI#&*+LUc+K#6H2+S1kt&-RWs~Y1)(fuXw;tWN
z#*@1c4R1nsSljpsiZE7NYCIC)ShLTKc*b9j0N|3>Mhk{|lw#?N<?ll`><*U~2x5o0
zoDw5C*l>E&^?5L9d)Uv7QMFGu37Dh^TyDKv_k0YJ=K1>ea<`CrP7=@w))fLMyM8*Z
ziCO=1<7-ys7lCf*w$*O;W@nirCt(CdN0FrClHwBen+yRtNT(C3AG;S_@m@T)QWy})
zBRuM(T|Z)$C)fw@NVDu37(@Tq)b7Gt0kiPXu;D`k35`%VhfJ!Iu_+oNzyX?s!j?&l
zt#`|o6;2`Oy=?nqO$CL1m)w9>^Ps{8{wTXVn({_L`nGFDe;dJLl8STvm7qt<0s|Zr
zsyhd|elXoE?oI*pKu2Bo-2~2$zn`xrCJr&9P{EP4Knu<(Q)X7o<Mvo%k2`;qb;Fn(
z;NTwFr9w<~cA4D(!mS0~#ldqhl1740DLESlfE#dbYb-iG5d}kCPNEALE>)Xw*4&N@
zhF*M2_V%FI&8)h=*y3L$p|0OIz5{76|5vRl@|R7pHho=ACt^_(T!wNbx+8Oj<4sX6
z<Q^J)q$6JP#z=49{1H-ULS5+IF4vP~R%=D0U&#<7cFZd?gg^TFy)Y1NX@3fKx6|#9
z-1B$2`J8vb;2mEt6sypzH4#D|YT35sO?@eY@!3AXXrmJrf>{3xQVB-HOO#Jd()EyF
z$lWqp&~cTq8i2TA59@*VfbZc7^@tD<N0E)PrG7+ZQ{CKU&lWdZ^}i$fmext*A3LKg
zuoNYlzEooh&#6RK3mcV>qSPV5(_e9fJx`F!tf@fX#O?*!kZLBl+ZEfBGqoVUP>MoP
z9|Q3(x4eOVCmo+!KjR5OT+F%Q5Z}(*)jWfY_A*19x@cbiwKc!kex2n4T&a^4*LEbc
zMO33PQh*7v5M)2h>UuuYPC?SdD)Z?Ou$p0EU<BC7(2A4qc<sKIZn~jjxn#$fHd?Wy
zOJko%qkEr~LYo^4_#HB~s&~jB2t8BhkeAPV^vAs?S-Zj`we9Wo$s=jWW*VcrBIz0v
z+K%MFn)5}F=5#V!=!U))tiTe1$wPDSG4(7w`DN*Yg01VaIi<fCQSPb<+4(uHKqwWb
z$o5mD0Nu1Z3($e0J7$Uqu(6HId(R(2Y1{E~`>5_n-|^NB>F=I>iIEo@z2VoPHe8C+
zbS2(sBb+7gmvyrt6<<c;KTpQY@)-e+EZ-;|$G_8xy~E5qL<Gq{;_0ZOW1azBlrCV^
zt_SgP;T5?DY+1-j8omWILvAgb>a6zS5E(puP+G#`+;7)h^$2>*H%#@|M6rSuglSkb
z`OaJIw3STyE*p__x<h)UKK3G~DtVnG0I^Yk<mXex70m5Q3pdN|t;YP=Y(b?BM83~e
zNG5`LmY{_hhiBV5rC)TTwf_j;CL$D;1mzLI{Sw!HR+&_NXrT)PcGfNEmN;WYrS8wT
z&8eszSVrS8i{3p*jQQzgrdusawaM}>M8S||x{JG7V}HbcWySLL)Mh1}JOg7Oek5^I
z&=)tJ5$g`z?M&5&%C+N1$xzNrmP9Z#j1n*iW(+Fm(j8*k148$Fm*f46T~ySRVCcB6
z{er97s9WDEP008QpM0&-;S-|IiIse1_6;Oszsw0T_}xx}-awt_v=2cAEtW$N?F=)J
z-pR?ZFSZ@!iqM3Up6W@pY*0_y#t0j?jqcY}KT32+7b$R-qMK16rFz2Aa8Gsc@kpd+
zfg6t{kp7i3U(jJRvHL0LBEn#%qUjGV&jKv2*aYVhEh5B*7Rzd0_-D^4fJG#rhK{vN
zZ=ucX9yf7v1(R;<r)Nhw4yx+Di1YdrKTF{F`ciXtZ9g{u9y!@LE&t|vi5!p-zn7OZ
z1P2o_o3{|EAiV0gjH!)sIBLi~mVe9aYSLCv;+L6hAR5Ce8K+4qYFae+<sh^zS3;78
z?Rh5)>}G}+KjP<o6M-PB<3Vu&-$lht<W{|8WfVhE1oLRZUl|)CM~7VWQtj5SJN7mk
zWY;bShPHKVEzT2}zOPOA9{brIfj~E@sfMvp<hawHL4_Sasx~YB<UOaeN(&y&Obv!w
zJ?ZsuUc_5)1$}O8#tn~}XuWHA!Q9W#13<_Ls3Pv$=5<Zy^U#;L#_Hprs0NP$S#=vn
zhL093EQV<PD#4L>?6Q~)x}_l*EL8z7k2f<<`c(P>B+n`G1+OnpN8ZU~;1{8GFub>m
zMjoj}*ZUYNd`>y_4Zoho0tSFKUzr+F$wc>&4?u^p>@yVT{w^4z(j>+UeD#zqeME>E
zSa?E2E|?m=8}>Ro3nT{hb2sod`nxrSMWTAAiGh9pht8B6C-ZN$h-j@FCBYci-&*ey
z?>5T*I0&06Nz;el+q)6UL+5~hAke%p%`{o_q06lZ%IN?!`57EI52*x=!sAcIp!Ha8
zBa?K;a-Fp*-LBa3ar_P?yEcnkWHac7dfo@xUi*q;v?w5W_h&Js+BBP6Fm03>P4`Uj
zUif@N?8H5*z~LE2Tr8hGzv$kYuzVqA0%tLhNtxE~u9Z#aJU|jjzS^qnL7EwwQd}?7
zVsAs(hN#ipp1?*;&O=w_fZF4y;r`SmNCf}1PrxZK#^)J|#Fi2h!4tKR#E1pWO@}Rq
zOU9ARK?pp~KF|wTbgpEg8~BrvNUM>9g*vm2?LTGG4R!1-iR)M@@hv!EsfKoqb*1$+
zVje{@-fztfVOWgD-Sr^p+#hIS^N7B_Y{6^gTY9V7o;Es0Q_&ia{Tr81J&-zEspO%=
zHhxNQMvpH+&j;v|Hfey}>HD;@ah+*S-UnRSr$rRPj>7=rmbX7zcsG#<1<zXIFWxN0
zI43)Ct0bvRh*2+IA-0KZAU5=3kU`Kj>7KwS5Q(GB{}{saw<C3m??GsGivyx!>Jl^K
z;EuO-LE{1b2z3(uh9<ce3DJwhLo$LiPylk<(T|#d`A_LbGt-?>raQ&gzgDd|)r$53
z2!bz;oDXISVlvcW`!QRQsoV(NHvKgnjk0<$PZ^xi34xt1Gp^(}x{L>ex2fYZn<3+e
zW^`RBF4#<{5OT=VEMHl|V=czo^y*HZB;a;?<`+#NjMlIVZ;{oFV(yGMy@)p-Zoc!|
zYCTYLGF#T>^QqOtV8*|WzswSqHQk!-Q|1n2oc*ECE&oOmei8A?Q`nMaa1J^<CTiI<
z<*m=GAcheC7)UsJnbS8Sj7;^wQ?$u9)=zCRWcHzJ$ehE<!6_IT$p#XiGmhVBW4brF
z>nfis^n4ld`3`Qe8SrZHiYB>*+DQx+!<(E58~sxX&%^W2Ltk<3SI3Fo?HBP*27}xp
ztBS^U;pj89M#+e+CDiDKHJ6nGi6g}aDDSlj4=y8xAexwdd%3_3&E8{WnGFE8;E!%H
zzi~$&bPuxU``NT1M{^v_{&*o-F30)Rv=0yY;Bk2Kx~<`Q9W^7Ca%`s}wdH?cbzjEQ
zxv+kL`?sU`%xSriSwTi{=95L^qWVSfbp$ajnUkI|dp|1FZ@?tgP;M@CgS$QszM!(!
zTHoG{l0D08UU9s>6h1t7Up36{u-{SdtT$jV#v0|y_}ozHsST_u=n~ack+4~S2@Uiq
zkah2jBa<<uwC2B(o;^3_DZ;*TYGOarD$I4@dUH|*34vWS*+e(T!N;2sz&pSkX#=lU
zSciYyjZUD#Z}NENcXVL+%-}HWH0XHx`s%MS`4F&@$^-A0{QPo$KARrupL_`VN|;9G
zr$O+t-o2>`zJ+g+F=P&5vin*Q=`Rt>rOx#-`ptp2gMC&e75AzQoCsZKc+PwDX|zLE
zuLpn%FB_373Izwv7s7<o*dGf#dPZdP*B(7gh7W+}Gd)tL|KfRo>r)Xqb$=7jw)=^}
zQN?8REZ~*f1}XKxl~-WISJ|0MtAe}32TPbXYid@)em2yO$>@PwZDL*I7%Of9CN{+K
zsf`KR_-J7l9G^krujes}+;14W`}~<+;9mFs1!srp?Y@2-q0^5G=#y^4l7|{6C9_i}
z-YEhxvk~**H{=Ov4u3i)mHm?A?Bwu|Zesb93Gj2c?X7eABMNzyAqA<!Z`+Id1N}_M
zl2ns96fuQi%83gDQ7e$b`jc4#hc=Rs_F_H3YqVQA{Ht)bIp7e!y!XS<iuXpYza+1J
zsk{!-IWFNt01EaOPcQ$Zbu$mVUeCx~f_ws=pZG>YJ)t<A4}U?ga!j?s@9dA}XPoZr
z;xm(`jViZKd=N70W+t5}kehH-b$h`_`C`^_<zSbvs%;pB3-EY-Zfa`6u83!cI9aay
z&PSBiFv8`r6~h-kbi7ofGHMU@TN|GOt@S(Tf^+KMRK&11pdkhrof-8a1Cml5zyi}g
z^I+M~5kojBV@~!UO_o8Eh+@U$7Fg6~qeJ@>%g_&=i5l$Fo-r|lC$6VF*x7=kP{B=V
zbvBX0@f%p$#3h_{yUz<W&4gZ&N&i6{L(+NXvE^Uyyy*5P?X=5hi9xeBT5;mkw88Na
z{MojO&H_O}(N#$*U-W#WiX{=N`4o_EDZ4)58j;Se^*XNd>+yUQ<Oq2f0jo%3hB%s~
zVy}=LUE0-dlaEte4I%UxoU=UNStqIVagRHrBz4K1s5TM}9KxsG{JO*y!}pYi9>n$o
ziC}j2=MM;y&9@7Mo??SiqXDE3m#uE8d<^jYg`zDdNMsovS^!)`vK-Sh{e9~Yq}e6G
zNsZO*;)Hu5Vs>1c0TNhIv{E79sQK68DyPrno9qxK7(OG6S1b4sIxSWAHb{Jgsh$uR
z#gWuVo%{9zW>jM@Gk0egBf~GLt__Z-`)UA&L_8t!CPb382gWV@JUakFV`c9h`--!g
zn4amz)h41_CK!#;y0570US-QIH;1=sMhw&{nS6eL;_c$f+s49camMzwaZI!#Y`63T
zFd*P#{O&ppMk%wJ>f@V_I?mM_v(+#GRM)*uQ^58r%kI+C19nG}T4AJ0(Sr<Vt#`t;
zT;IJU7S<~kv{8fXjlhNQChxQE;DgqjW2$E@({;yW)u}+!nAh0cwHO^(zr60|!+j0~
zZzdV4sQeKd{%-#Ob+YrkTE)j3@0*4KqML7unH`=Qd|wEOeQav|$6byN%o6l019MGT
zFwPWuURJ<OuFoynsXs_|?pF}mcBs&>?y(JkpKs?{s%A`J@7r!;k%b2lyuh)-QzDOp
zyfW6$Yi8SfXTnH?w)za<+Y4vazg_p*+M}^H%usJ?h<^;7-EEq_J`8)-ImkTKIU^9&
z5xBZMtBfz?ZaUYHZ!XL;s`giVO-i4_LKG5xAy7LF!!!EC^zppq!t*tcV%i20M67(4
zd-CU*m@U+0Br+bK4bDa$|EaKgsGiVIXkBg6D*ecx*y3vrPx;Tq4OrS+XV8=lnU=8=
z9Tq|NOf0>#$Z63u$d@%p%WV%;Q_vnOWg#?k-uBO>kjhp~L|T_y{(cwR1FbM86k`i7
zr4K#6L~Q6t`{#YJv0mm;?Bz!d$at46%prw0!IwKESk}uLQEWalTC>Qn>gh20t-nkG
z_aLf>Q3^?4>FriSJHH2$Y_WqRwbaDn&Mg}imxZlWeu0zc=SO}f-P03f2-M3+NPW0o
z2^q6}aK2i?IBZhDL4GJGl$k}=tfQZ$?0;f|dNzLk87#`$)lBnynFb+(0K<_l6lXp`
z7r@6&=X%xX5;ds%)O20Xk>-qUjBV|&3kd0Yyms<=s3gf0*#EV!#CjoJuYkk1N7UC2
zYbj`HQ^!}#lHuMjFczALizmi=a2iSjI-H-2@;^_q8|rsR67=sBVD4wNr#-Y+VA6@m
z@+~|OvF%f9IbM~~tvB;tcO8K)@*!S1-${d@_&bp?nD*(qMH$C=gP`=Kn{_x`1DGyD
zf!6GOtYi=={fKTnrLfRY)W-e$_GoMqCqxjs<*@>K7dBNYqkNA)O42-<1Vww;)igIN
zjyj)?cHvSOy<S8Tnw-CbMM}6SwUsweIilvD<TqLfs}mv8lnzA@!eXPKFwg{~B4_T6
zOLvxFFg4CyY?+j(|JhRu^<1d9`|6$u^x_z?B`G%P_YA(ndLbjk-?Ld1>6f0Z`5tV`
zqu;3EsgzBmd;R)n`kby=HZ1iKY_RxAS>`P?)|9iXyU_ihsZiU~v&gDG=*noXdFaR9
zIHG^!&!pXo0gMr8R)+=T4K6+jDWy}xStXNc_kqevM?Ize4{yna7$V_}$9Fu1;u)En
z({}hWoo+{=ismc4y&68Lo#iM<UBW4;HiU|-L9tmeIas~e?Ye{TSDQKzlV}VF*7S$~
z?gV*l33@_g>Jxyq;NGrR2vSOGC!_%mM-y?U<$WB#wl~OV44UP2<X(P}2fMy*C84N3
zxi#qj{-hA+kY)<HRgMs@&wHs3kHVBmx)V#zY15*A92C}{lZ>nAh#VShDdEX(NVy#L
zCfBF*bC?%ySZvsHSo+b>)S7>k0dQniHR0(Xgyr7BD=(Zb8$Rcs^aIL;blji<=DrkV
z(L7jK^LK%H(=i}RXtB0)20`JHX7PNa*1Sqai?}Lo0Ki5HV|y%2Uj6oo07KYdvlenV
z9(uR}+sh^G-#hb#0F11hZIWu#vt%R<26-J=k8`7nipa;Y3w3nU#Fd1%Uhukgp&6>5
zFZe=zm5CYpcDGZWK&$uR+gk>LV_F!0Igk15inQFfCtOm$uqt4=clpgN_uR&DslfbT
zJmPNLlLT=BKQDJDmE|2TF|C$OUJm+l{-42@n>0MsKZ%j41fqed{ZNr1DKk0Ctdfx3
zlY6#Gu*${rYfKm&N4En}36=T0B!o%PV4USSM2I(R1Ozr$O#befea5{fr);aqmo9T~
zyRg{}3nPb{sjc3RRZj-)qPA0?yM$$SaOKw{0jq@<lA8<WMiBjwy)-XCr?2-6Kq!=!
z6;X{BS+!y5Y!qzyR@4d9WIpy!cdNgx@*+Ksng;M25yn8#sHfAcb?DPB=<8sV{;<kv
z4QA!*Zr|0ZmEDer+703kuqzAUWGy+?PnB(-*I`?>^vC1QWLN(XKHynF)R^|~ymFNt
zNM}zh0jTv+dSjISM&w3ekQS`M*AolJr%e%lt^c`9xzMb`Bd*!<?;i#Q&5ZBbx~Gkh
z)x;VnK50qg=|eE85CCXYwC>%dkxe3lPpn2Xa~qxtEAz_Nx)t+CNr5>jSiNYXf#Bek
z_sm;ji%4#w9>qy~DzTV`gm96_fGC(K|2GHm&cH~o8xigKvM6}LOdz)v=TeQWIyJSh
z%f8`(tMC$0Um7AS0kw@|ir+=CcN6iaqlGYi@;oPx6{UneYy<NJ!Xc)m-O`I|^4LVb
z17`p9!ZZQfsY|WQ^&F8#PX;MlHTsy6#f#YT#XKGk_IN)jsN>vOI(b5a(IZG5*@A|)
z$G|y#>YONOW7G6$`&pdUPZ><4id)#Z5Gzqt`f}eblqc;fXSN*LVTol?Yb1O4`7NOg
zF)tW}N}x3DKnDU5h)I=wYh{&TX&TMAX{~*F&K5=S&Il-Z9A*zo!`|!)>>Rw8MXJ9I
zfj-#{jCmcCTKlxP=r2qur3Fy{241^AVef*|aOq$#(?R9nt-kL9;e+v@=sc}IBga2O
z^RVcgprHBx=f-}xwH4;opk3i7s|7bTh4pgaFX<>#ODqJHn<IvK9|V=T@;2O!ctHr>
zPnFMijf4^SLOS&u#BIE9mo<4;)+<5R$&Z$=C>kYyA~(4<w_(n<N{!q)Z87_dcj4m7
z8W1HyqK*#pra*2T!RhJ*PxkM!3y#j#cc<Z|<5=KIiOUswx?d0M8gYaWjby{-O11;o
zDb}70I|!2`^n-q?K?zmj`mfij+$=o?>(kXTRSXHW`qWU-zq~f<_MCXi$F1@d-*(<H
z@L(kzF{ssGes22x_>rSs@B0acH_|Jazt_i3VTX{DI$7$u9boe3%Y?g;yeKC0;{b1O
zR|P#PiXNiR-`j5CM?zOhcB>Rnm-0N-`=67(C9JsHHyuFDmtizL{jqSrSPEsc8cT6m
z=Aad_rInDD4?HO#(E5C}*LyuW{f*w)R<y^d*{9z=f$6L!InBqW>Uo>#uH5=Gv!jdH
z??J-jOg|y-;1qyHh}2$9&gie*%yMJxxs_75`lVJ<v!s8b;cI@a&%7&20~W1+O?1T%
zj?DRV7EHvT5F#b=JsoXQI?YcP=$a`DJ9hcjoFUgC;QRUQ7zstTTFhcb1iIm#AsYEw
z4H*U;r|7sSn}Qb%{%U%mW{?oBexLXBekRYlzO7?8o{B-3U7WejdZc_=XCh`(Tn|BH
zuSQt@aAi3Cwj-%=o4$*Bwf(|4@z>PDEkhFsE<Z(t^BIqqCL{2+DEerN@-)=^uJ(ii
z!s2r`?OM#6N#nOTh-ml6L=8%WRA8|%VHUG2g@RQwPcX#MHB{*ya@m$*N*^G)-?v*l
z$OJKw9B&``CRuFG6TVV{`+np<!uVC&zr`k@vWZK!hxj?}?vL`|x9$BPGX#cw^W@I`
zt+{F^du{63fn)kz@Qi1HCTZ0SMz;?6KRNjAXGp1UZCgssiH1L>J@?=E=QPDg{PR)x
zaUPe&b}u^)c9$Lfs?ig^V9%I!{)*+N2jIJz#YsQZ3MQGJjhDwty=ssGO1_bBNhS=5
z!j+9$CPsi^P-DaHWhj2$pbHy8Ll)VQ6GI<TGAf0`)LvY%vBkjwd;VQBY{W=G4YHq3
zL}6<#$TVv5_N27NpfG5}Q^{9d3V{Ez59LU|`_)__FXiva5FU9hD@n@ohr1bM`xEeo
z<L}9b6(rSti6l!^mg@A4t-?+8Wx~iCSaHZ3QNyUih&N+u_U?`j$}THpwCo#7#RUXJ
zPx`{^UKG?F#fvU(TC$vF>PXLy%n-m6oSkY0ST9DtPgi@Ir=#!*@GsGL#dW8nKMB7R
zdVa0%q2wWm15E*H9k>!#3XQl&FBfUim{7ntVuRV4clYI9ZaCBym8fb_Vl--l*v@xz
z1s%rTcK<`~gH|J^D2b7cZsJOhyuq0mjoqWLVyk7fpm@P<NeUER*HaOS%a`fKYh{lx
zAM--1rQIb;QYLdjWuG_Jav_1>LSzzd98rB*z9(a0Po~L3=(d-m3lWENgL!9^0^Vzg
zlDhqPOUa#JnvxIMlvs!|hxHs-J|SB=3f^o;O3l`SnnuOz0}k`DVIxZ@`|C8NT7grK
zT2o9#Eni@q-ckn0n3NL6_}<WyPFw&(umzYS;J%V?h+>5VIiK1eN$ItUctuR#a)lqS
zO&)%ZT~YPco{Oe=c~sG=IuE`@N0_Ax@u0nsPbauX6{X6`dpva{<y3EUsq*L_f0Jau
z>US368NOM2QuhdZq!SclUt%E#$PxHx)s3pIEEhdqFj8U+g}o(}&hO=v%IKDb{q&2O
zo1#P?xtb6*9)+B14v3beI+sslrFt-M-z>Lq-|;!xhB-n^xE6soy1aeMVN&f2cU`6Z
zW$3vL!H*IsjPoFZ0lnC6Kd}5Ec*)jh3dX2EgmG;MkDy6Gp=U!)uXkq)R#oae-q!F@
zo60H{M*LTQXse<(ejE`1AyF>BZ&oh>p{ZH;)#q!C!ok&L<{LoTV|hBvx&hfT_wqoD
ztonMTk-GpPkkE79cJ{Zd@BRApTH%=e#p{n`1dawpyfP{$)k35dJ^E1CM^qWNGU+42
z>$lllnwtwZJ<U3#Aue0t-JZJ~rc2Nk>&))6|6Cw3HgWO0!YGUv<%vkK!O*F{^Kqmo
zY&*BwLq*%yOCO;%8&^smiI;7N8c*S(`JkBE+G`W?CY6aL(HkoPc|B~HXMY>Cy@y<;
zFnJ6%sf01r_Vgc|A$mlG<Kjj}R;IC%->+ap?E8i>F_)Jbx-G4{aTNE6v8|Jndm~F9
z&N1bUm`w@?AqF@&K0evss3p|%p+E-<>=Qu;2@vJV@kNgWnW_%2<&GF<LdNe|OB1H#
z17VMgaNl0JWamic?g$=XgjjS^7LuDkM~f|mQxVSMu_=>y0YK7lm`gVC@2Qp5PS=^^
z#mDfK{s=A35H8*hVDetPVI+8T9o(94Ai**zBeR9${9;{cAPzk2Dj*tgI>O>c|8x!c
z!H<!6yeUg~Jz1CJj@t?c3C!iFBfdN<znGMpgig6cI7z3cc*ZiQ^;);-R6q2p>&oCv
zC&n5`tl!6TDV=iNk)_W2(*lQOk=@WL#U=eWA+Z@F{Z2AFVmAL<_8TNOEQ(tNu`kDb
zaba5?wZS>2F_~E%fs1zn8}a6r$Hkh1ySHf2Ex$f`Xce;hJT!s>I=LA|#{Ji()*M0A
zNz%yY)w4MH1gq0j^K_C*;UGpF0TDjDFwt$MtvLtxt#pT`!%rnv-$D>gfX3yA+@auL
z&@>eg!*Y$MQ;m=@{nERLQVH{A31R}QU~5b{EL*IyGT)oW9oP~83wWgGt4gR%`)QIG
zdGZu$2*vRWD%W7$x35?7MYq3yZigV1PeViDdZH)>bTMoO`RUt5Gz}-$!E2f;B+9AY
z1nsR;C8Z~v3N6U^%6e+jf9L0fAh0$89%dbouQY$2)?+VK)>VD9gf<d*an84xt%r|<
zoh8xDRHbK-D-&m_mQ!-p5HBCr6pIX<w-yPeTBt`=cG=7Z2Aq=ssD&ZvX)%9oc=|RD
zm0{sO8The?p)@-U3@W-?8K&4+d)_=02AhpH)qnk>SrZ*Y)?Ef1?zz?JF0Shy-u{y=
zIBi}MYm+UMjP^Tv$^%9yP|*!)T`}9q?G=E<@oY8{`sMc`sWnxu3hfHgJRfxrSXoCb
zvq}jgXK&8-=31`Q?pVyouHo)Yfb?7EbVEj488Tk0{S&^v&f9j3;h2x!waER1E0p{N
zWBfAEuzulgrNB1M=5vpaC-youhA13|HGdWNrBzB=A+_$gBsVW7$L04mW~)5ajA}<o
zr@oO|kCc-XAC2*^IX&J70R4T#K<pb;U!GZZob=MEOV3wxm0_u`3E$1C`T)i#fhqhQ
zai`rhlC=fkQS3?<IS9uKUk<KGi_A!>Qyx$6xJHU&hy`<+Zcv|C8}YRv7*p5$M1MNP
zTd$!z%Ln=jHXnbKm5u=;kV{~mpqVFZP%RdKan=ZxNGhqG_pnrSoDaO=xs}94Y`d!h
zOP-;9UiE0YTjbKF5ycvaB&6recR6UN(llb*&SU>r=lx}@-l@Z^3cKLZ$m^-@1Kv6+
z*${;#Ji-Uh*2<#At-EB%Ira3<0r!$1-+eMm*Cm3!aqx%=O)_ffwh)`b!Rlv?z-Dh-
zJXRPY4zi-{1Yf<G;)~@7g)Y6~PG?wxd~{6k#*wJ!(r&i%t}1vzzWIuX5!u6SBZiGw
zXhcd;$?w*@iaJ5nbidZN8uYZvaP>+>2?E{uCrFC+y6a`NC?`U0`T-+L{qlymT>jg$
z=jT9#$gB%!Z_0uWqVG><rK*VWCYODC_9r6zxPi&o0>>WgDoujPSMjzMzCEa)tJaW)
zYHyj6cS}eHH>9DY_wlElmN|>0iUy38*hMy=Taq~zj}gVcc6h(mRsXEgl5W;cs2gIR
z*%=Pfa~c;)o(XWT)B7D{@kNk~fE`h4_Un9#58PtM_&i_tFS!>HnjX5h(s@;!M<9Nd
z$Fxy3SL6jeELI+G^72tK5ILY7Kk0SG;pPaD^{rlU<#Uh-*bCt#DZD@lgJFx3Nfnbi
z-b~jr{zCRwD%nyaMO?J_05|d8tR9RQq%!Lt4M=FA1f_;}Q+re@hpET(tON_+MD$Zn
zx|^>EuP=P5*;Y>#I@4dD4yg&$TE<*RaQK?ElR|>|tH$hrE5{w*CW@yoTF*%{%N}dC
zR)wIIhs27BkbaLS<+Z{J9oMAE<PF|f!Dd}<l(@#Rkxuf5$r~XA7((^n+pZ5Osw)?^
zC)>_(u~p$riNhQ1aH;g;8DUo)iyrURF7@ku6sG{@eli5>x3KsYEs+YEm)RaJ5(|Dt
zw<{ypvrbLamPhRA()0xPB2r*GM+`>AMuj&yudiC#x<z5E0{}^Yy`UJXk+b(zLIRR*
zD6&O&Hj~Nj_n*Ur<3X~MAP-CY2UfDf%`Z;N^&sc|VReZLAX~mG6bbtPN|I66IVb&9
zfF+LMiK7wU3WA}q3j&2KBDVgCh-QZ1=Ts4nFEY16J|~yf-J3R9h^NTmn95>$3hRA`
zoMtY)0hg%Lm!m+*rmvy9C;S_Pg9{e&V2u~qF@Tb8Fz9>nWy*#r*oO*YKvvqZYyC}v
zyRQ4t<N*;OV`Jsi*{GApX%V%?0rl&RK=+_q{>K~Nmk4J|dTRX$%V7i0+-MFl3ml7j
z(?=7I)G(yGJTkB~Ave@lU@6TbTPyd}B}y(T^e(U!aQ{arLoGK(Ad}=fr3l&<!L1pr
zWrazo5sv7?j|I9IhHg2O-@+u|T>gc{@q#c@utYu0hCjF?+W`W(5eJY~e9$9H^D;^?
zwuc_&!^`NY1w~6^UaMUeiwjAV!5^wtv0uRGg##I~zf-O5s;wEb#*v(Q!LXLne1&P1
zLu?850f3GeCF6=im;sOFvub@2M!%7JMGV;_1BKekH4h_870a4WmQ(ARJNETiU5tfY
zzw%sE-UP(Sef@kkgiQVXtFe)aF-2*OtcfBNO25^xmK@Nk3Fwnb=!vGD?=i^P=*@cz
zmvVQnW~F5<(-0G2*0&2=eL1sWo&74juJoOyUY>~7jYs}-OXJr<>FWgnc<5jf-alD4
z(?U@;-=<Q|QALi))-favK6Vzm61C%@)pmDZ0gpXs$kF?upc1mcztzwzGeWU_f)+{f
zOq!O#Cc{SQk^U1T>m>^q(V(QloaZ=gs?$7Al9hL74)94)(^1b83*~m$aP}a_a|<WA
z&oJ7TZppGYo8_5n<|7y6lQx43cF&9Dr}l5qix_UNm^*2WC;~|L$R0AP+uE$Lta0Gg
z(5abN%NCQmX)xl>C{UswjLTv>)M>Idc3T2Pop+9w=~ANbPO0ZeL@X2P?t*cHzzH&5
zowe4^bCg3vzxAde0j@gL_s-gIzSG!JC5+WqQoAtoO5>sz4Hyy-qC~Pxn{JTuFf(cb
z=ZoQ1vc)iqj%ws3251LY*43_3l1cnx3UQ)7-}uBRLIU`mV2*IVk+I4&-*jXultv<r
z>f{7ZDU-MYiL)AnY-^o}29C2hpJF_UrCScBaPS^O@5P*a#`2Lxn~xk*J7BZ8`w9tw
zEK_Ijk1&uBh)ny>$Z{!deCkGLnA>T&+tjU9F~tuKD6jsg$Hdq;z3XyiReRDh1OIin
zkOJGnH8b<a!u0SsImrWg2PJyI90gV%vQ#n)mDg|$_&0UBDhIFyXjOn&aH3rrzxscN
zfP=5~4jPNS(z%b%8a2v75c}CO{;}>J{1sE&<poss^qyXAHuv7MHuD5c=2%?MrIb(k
z!KZ`uL>C*@b3#A^f_j~>zD(c9BT3bI8<AS#w_n;asnpvftfI8`m(ZA-%fj&Z-6@N|
zSHNgbZJ5AY-6xs%Kll5VGdx4B!vr!darLu3<ZuJ+p!AQs`_>hL9E~57S#SFd78BKs
z=`-;>%cT$0|Fdh4kyOgEVjBsH1b$(?MhvlUl@`Iz^0Jl;)pfiaGJ+5BLvx<VpLVDz
z9g9GnQbys9e&;9>Cw_y9w-<hxfOq`&Kj}k)(nGw?W0OVRxsc93f}BOV9=N0M?|ex2
zexQssB5v}paqq~t3j2u$CS^chz0XwPCFUpVhCvR~Ab*#Y!GJnwqp1Yr&<^qsWndSH
zz~2p!xDvN;e|X0#mLJYP&65;5Q-?zAxJ|b|TADA)Tk^G0@_ly5CL;s~J1Muz+bGh%
z&=dbAp1?*9y-PgFnuOhHl?x=euaOfro(?R0eznwYzJnWy^-UZU#S8f;fk_uR<n1bI
z+_joqYeP5feMj1~S#4-OGcI{GGGUM7A&?;JJH$%i(33FtF(OQxrB?WMnSmCOAhQt#
z>tFdSxH81(YSa6(NaWlni;^jPl%K2<NGd_MA2!fsk<ZK4BzuJ3z}-qQrG2<{!jNh6
zhh$MPy7`o%lc^Og=;}wlO_?M$qDs2K5H-RGQ@(J(MYX-HW}?jB-=>@&W4Z5^p8WPN
zj@6{G4R-lvEc9r)bV*q2pOZ>#sOM5LD!7q4UJP*{T-TM$5dGV3Y2t^@)CNbCMoga4
zyDzt^8@X9ODeisRD#Cu+U}`cEE|N_;xp0;pMEqBNkU8wmSm^#tgLwV&Je<^Fl_?Wm
ziE3D>7A2EuVz`uIbpxD~W)(L*$h~*4wjjywELl4~mgXTFcD%|%8-lMp`)m6sEf()z
zGEaXT)XD?|Qs8{1W0WGDQ?b{`@BR_lnd`^b@_cFJ(6O{`ezfzDNLPn|a%_2g@rV1F
z;@xceI4DhQD=G{+R)~)o9@R^H)87=Kn6A^BR`RdSUM_h&zr5Vh`03zvX+|ISJ_pE{
zG&Y|z<FmWXtwG=?X2}`3;UmAe#B+8>4`p3XM$!`1*&AW>mC@{c{LECYZIyR&cfLVc
zso0*aN{e%lj^irRHt1;4p$&)`PX#19Es~Qfy<#O)GI>Vxu{zeLdbYZX11aC>a+3!l
z#d6zy^z7m#Jg=7J*PpP$M2^h<+KbBXxDdC$X2MOd=KPyU%ug>6(=(sm&tQ4j9j}bg
ze82w63X$Pe^99}|HPX~8mb-ha^1j-4Tu_`K+JU42uPAQ5@8Fx15QqaG9u91h)!r?7
zV(<mn$xu52MuzuBqU&#BmiokZSD|-nuN*B4b&Jzb_kDI$z~3~g$_&c0;CCiMn-XLT
zoO@f}4*^sJ$WyJ)Be#zDZt*tCg6zprsQdeY24I40QkO?YE8aV)?b1OuX#w@>oowVN
zv>>|{aKr7+{=Vyfo#5qUe?Gh$O=5MBt$;dmzqEM=?sNvx&=wnof0rr7UkOSn1I%CT
sti1#K9f4>xMkiyvOO^B2N4@v$;J)-~$zNXln*k~zA}d@js2}kE0C;xvO8@`>

literal 0
HcmV?d00001

diff --git a/docs/probing.md b/docs/probing.md
new file mode 100644
index 00000000..1bd051ae
--- /dev/null
+++ b/docs/probing.md
@@ -0,0 +1,328 @@
+# Probing and Path Finding
+
+## The Challenge of Routing Payments on the Lightning Network
+The Lightning Development Kit (LDK) provides you with the software tools to build a node on the Lightning Network. The Lightning Network is a collection of tens of thousands of nodes that, together, enable cheap and private Bitcoin transactions.
+
+The challenge is that your node is just one among tens of thousands. While each node has its own internal representation of the Lightning Network graph, the information within this graph is incomplete to optimally route payments. This is largely because, when nodes announce new (or updated) channels to the network, they do not specify how the capacity is distributed between the two channel parties, making it difficult to know for certain if a given channel is a viable option when routing payments. To complicate matters further, liquidity distributions across channels fluctuate as payments move throughout the network. Without regular monitoring, your node’s estimates can quickly become outdated. There’s also the added uncertainty of whether a given channel is online when initiating a payment, increasing the likelihood of payment failure.
+
+This presents two fundamental challenges when routing payments on the Lightning Network:
+1) **Missing Information**: Nodes may not know if a given channel's liquidity is prohibitively unbalanced.
+2) **Path-Finding Optimization**: If multiple payment paths exist, we must decide which path is the best.
+
+To help address both of the above challenges, LDK provides a [```ProbabilisticScorer```](https://docs.rs/lightning/latest/lightning/routing/scoring/struct.ProbabilisticScorer.html) struct. This structure holds information about our node's current view of the Lightning Network graph, including estimates of available liquidity within each channel. It also records historical liquidity observations, which are updated each time our node either fails or succeeds at making a payment (or probe).
+
+Ultimately, a ```ProbabilisticScorer``` is used to identify the optimal path for routing a payment by scoring each channel in a candidate path. With this information, the ```ProbabilisticScorer``` helps identify routes with a high probability of success while minimizing transaction fees.
+
+### Estimating Channel Ballance Distribution
+There is a bit of a "cold-start problem" when encountering a new channel, as we have little information on which to base our initial estimates for available liquidity. Therefore, it's important to start gathering data to build up our LDK node's internal estimates of channel balance distributions. To do this, we **"probe"** the network. **Probing** is a process where we send a payment with an *invalid* payment hash along a route. Since the payment hash is invalid, we know the payment will ultimately fail, so we're not concerned with losing funds. However, we can pay special attention to how the payment fails and learn important information about the Lightning Network graph. 
+
+For example, imagine our node has, via the gossip protocol, learned about the below path:
+
+![Path](./assets/abcd_ln_path.png)
+
+We know each channel's capacity, but we don't know how that capacity is distributed within the channel (**note**, we do know how our channel capacity is distributed between us and Alice). For example, would a 400,000 sats payment make its way from us to Dianne, or would it fail because almost all 2,000,000 sats are on Bob's side of his channel with Charlie? 
+
+To answer this question, we decide to send a test payment (probe) of 400,000 sats to Dianne. If we do this, there are two possible outcomes:
+
+1) The payment reaches Dianne, but she doesn't recognize the payment hash (because we sent an invalid one), so she sends an error back to us. If this happens, we've now learned that each channel has an available liquidity of at least 400,000 sats.
+2) If the payment fails along the way, we'll get an error informing us *where* (which channel) the payment failed. If this happens, we've now learned which channel does not have the ability to forward a 400,000 sat payment.
+
+If we'd like, we can repeat this process with varying amounts of sats to gain a more precise estimate of each channel's available liquidity for this route. We can then do the same for many other routes, thus building up a robust view of the Lightning Network and, ultimately, empowering us to select the optimal path when routing payments in the future.
+
+Probing best practices are discussed in more detail in  [**Best Practices**](#best-practices), however, for now, it's sufficient to note that LDK will update its view of the graph each time real and test payments either succeed or fail. Successes and failures are communicated to our LDK node via the [ScoreUpdate](https://docs.rs/lightning/latest/lightning/routing/scoring/trait.ScoreUpdate.html) trait. These successes and failures serve as historical data points and influence our node's current estimate of available liquidity for each channel.
+
+Given that the Lightning Network graph is constantly changing as payments flow throughout the ecosystem, our LDK node must account for the passage of time and assume that channel balances will change even if our node has not probed or otherwise interacted with a channel in a while. To accomplish this, LDK provides ```ProbabilisticScoringDecayParameters```. These parameters configure how each channel’s available liquidity estimates are updated over time. For example, one ```ProbabilisticScoringDecayParameters```configuration is ```liquidity_offset_half_life```. This configuration determines how frequently a channel's upper bound and lower bound available liquidity estimations are updated. For example, after the set time passes (default 6 hours), the channel’s lower bound estimate is cut in half, and the upper bound moves halfway to the channel’s total capacity. For example, if a channel has a 1 million sat capacity, and our node currently estimates its lower bound to be 200,000 sats and an upper bound to be 600,000 sats, then, after ```liquidity_offset_half_life```, it will be updated to 100,000 sats and 800,000 sats. The ```ProbabilisticScoringDecayParameters``` can be customized, but default settings are also available. For more details, please see the ```ProbabilisticScoringDecayParameters``` [docs](https://docs.rs/lightning/latest/lightning/routing/scoring/struct.ProbabilisticScoringDecayParameters.html).
+
+### Finding the Optimal Path
+The ```ProbabilisticScorer``` assists in finding the optimal path by providing our node with a perspective of the Lightning Network graph and the estimated available liquidity for each channel. To assist in finding the optimal payment route, LDK provides ```ProbabilisticScoringFeeParameters```. These fee parameters impact how our node optimizes its routing decisions. Broadly speaking, ```ProbabilisticScoringFeeParameters``` contains various parameters that help select paths with desirable properties (ex: fewer hops, reliable, private, low fees, etc.). For example, one setting is ```liquidity_penalty_amount_multiplier_msat```. This configuration defines a multiplier that is used in conjunction with the payment amount flowing over the given channel and our node's estimated probability of successfully routing the total amount (i.e., the payment and any inflight HTLCs) through the channel. This configuration will give a larger penalty to channels that have a low probability of success, and that penalty will grow larger as the payment amount increases.
+
+Similar to the ```ProbabilisticScoringDecayParameters```, ```ProbabilisticScoringFeeParameters``` parameters are customizable, but defaults are provided. For more information, please visit the ```ProbabilisticScoringFeeParameters``` [docs](https://docs.rs/lightning/latest/lightning/routing/scoring/struct.ProbabilisticScoringFeeParameters.html).
+
+## The ```ProbabilisticScorer```
+
+As discussed earlier, the ```ProbabilisticScorer``` (seen below) is responsible for maintaining and updating our node's estimates of available channel liquidity.
+
+A ```ProbabilisticScorer``` has the following fields:
+- ```decay_params```: This field holds the decay parameters (```ProbabilisticScoringDecayParameters```) for the scorer. As mentioned above, these are customizable, but LDK also provides defaults. You can read more about them in the [docs](https://docs.rs/lightning/latest/lightning/routing/scoring/struct.ProbabilisticScoringDecayParameters.html).
+- ```network_graph```: This field holds a reference to the network graph.
+- ```logger```: This field holds a reference to the logger.
+
+Once implemented, the ```ProbabilisticScorer```, along with its parameters (```ProbabilisticScoringDecayParameters``` and ```ProbabilisticScoringFeeParameters```), becomes the backbone of path-finding in LDK. The next section will describe best practices for implementing, training, and serving the ```ProbabilisticScorer``` within your application.
+
+``` rust
+pub struct ProbabilisticScorer<G: Deref<Target = NetworkGraph<L>>, L: Deref>
+where L::Target: Logger {
+	decay_params: ProbabilisticScoringDecayParameters,
+	network_graph: G,
+	logger: L,
+}
+```
+
+## Best Practices
+
+Before digging into best practices for probing, it's important to note that popular Lightning Network implementations such as Core Lightning (CLN), Lightning Network Daemon (LND), and Lightning Development Kit (LDK), have different internal representations of the Lightning Network. Therefore, it's not possible to simply "feed" CLN, LND, or LDK the same scoring file or information when setting up path-finding functionality.
+
+### General Architecture Approaches
+Now, let's review general architectural approaches for implementing and updating a ```ProbabilisticScorer``` in an LDK node. Before getting into the weeds, it's important to note that a ```ProbabilisticScorer``` does not perform the probing itself. Instead, it is passed as a parameter when our node finds a route. For a simple analogy, imagine you're seeking advice on how to get from New York City to Washington, DC. There are many paths you can take, but the path you choose will depend on the person you ask. One may suggest taking a train, another a bus, and another a plane.
+
+Similarly, the route-finding functionality in LDK is separate from the ```ProbabilisticScorer```, but it takes the scorer as input. If you provide a well-trained scorer, you will likely get a different route than if you provide a fresh scorer.
+
+#### Background Process
+The first approach to updating the ```ProbabilisticScorer``` within our application is to program our node to periodically probe in the background. For example, once a minute, our node can attempt to probe a random amount to a random node, updating the scorer with the successes and failures over time. The advantages to this approach are that our node always has access to real-time updates, and we have full control over the probing process. However, running a prober in the background may add additional resource constraints (CPU, memory, bandwidth, etc.) and complexity to our application.
+
+#### Create A Separate Prober Application
+Another approach for integrating the ```ProbabilisticScorer``` is to set up a separate application to perform the probing. In this scenario, the application will periodically probe the network, update the ```ProbabilisticScorer```, and make the serialized scorer available for us to fetch and incorporate into our application. For example, it may serialize and serve the scorer via an HTTP server or make it available on a file system shared by the two applications. The advantages of this approach are that we can simplify our application by moving this functionality to another application, thus reducing the resource usage of our node. However, this approach adds coordination complexity to our application and introduces the risk that our node's ```ProbabilisticScorer``` does not have the most current representation of the network.
+
+### Probing
+Regardless of which architectural approach you're taking, if you're setting up your own scoring functionality, you'll want to probe the network so that you can build a robust internal representation of the Lightning Network and optimally route payments. To accomplish this, there are a few options you can explore:
+
+1) **Random Probing**: As discussed above, one simple approach to update your scorer is to pay a random amount to a random node every minute. While this may sound rudimentary, it's an effective way to build an internal state for how simple it is.
+2) **Leverage Your Routing History**: If you record a history of payments forwarded by your node, you can leverage that by identifying large or well-ranked nodes that are 1 or 2 hops beyond frequent next-hops from your node. The goal here is to attempt to identify heavily used paths for payments that route through your node. Of course, you do not know the final destination of each payment, which is why you will need to use some heuristics (ex: channel capacity, node rank, etc.) to estimate which paths are heavily used.
+3) **Probe Large Nodes**: As mentioned above, it can be beneficial to probe large nodes on the network, such as ACINQ. This is because large nodes can often be the final destination for payments, so probing these nodes will help your LDK node understand which paths are viable for varying payment amounts. It's also worth noting that since many channels on the Lightning Network are connected to large nodes, you will likely succeed in probing large nodes via the "Random Probing" approach.
+4) **Use Multiple ```ProbabilisticScorer```**: Your node can leverage multiple ```ProbabilisticScorer``` at once. Remember, each scorer has its own internal liquidity estimates and payment history for each channel it knows about. Therefore, it may be beneficial to use a new scorer, which has not been updated, to select a route and then update a different scorer. This approach would help ensure that your node doesn't keep probing the same paths, as your node's updated scorer will likely begin to identify and prefer certain paths once it's sufficiently updated.
+5) **Vary The Payment Amount**: An intelligent probing setup will vary payment amounts. Two important reasons for doing this are listed below.
+   - **Finding New Routes**: Remember, a central part of the path-finding algorithm involves generating penalties for each channel so that your node can select the best path. A key variable when calculating the penalty for each channel is the payment amount. You will likely get different paths for the same source --> destination payment, depending on the amount.
+   - **Refining Channel Liquidity Estimates**: You can refine your node's estimates of a channel's liquidity by selectively probing that channel with an amount that falls between your node's minimum and maximum liquidity estimates for that channel. To do this, you would leverage [```lightning::routing::router::build_route_from_hops```](https://docs.rs/lightning/latest/lightning/routing/router/fn.build_route_from_hops.html). This function allows you to construct a custom route by providing the public keys of the nodes along the route. The success or failure of this probe payment will help your node narrow its liquidity estimate for the channel so that it's closer to the actual available liquidity.
+
+### A Note For Mobile Developers
+For mobile applications, developers should explore **Rapid Gossip Sync (RGS)**, which provides a quick and efficient way to update your node's view of the Lightning Network graph. By leveraging RGS, your application can quickly retrieve an up-to-date snapshot of the network graph from a semi-trusted server, significantly reducing sync time and data usage. For more information on RGS, you can read LDK's RGS [article](https://lightningdevkit.org/blog/announcing-rapid-gossip-sync/).
+
+## Setting Up A ```ProbabilisticScorer```
+
+Now that we've reviewed the ```ProbabilisticScorer``` and provided an overview of what it does within LDK, let's discuss how to implement it so that our node can find the optimal route for a payment.
+
+#### Initializing the ```ProbabilisticScorer```
+We'll start by initializing the ```ProbabilisticScorer```. For this example, we'll assume that various components, such as a ```Logger``` and ```ChannelManager```, have already been created. If you would like to view the documentation on how to initialize these, please see the [docs](https://lightningdevkit.org/building-a-node-with-ldk/setting-up-a-channel-manager/).
+
+```rust
+// Initialize the Logger.
+let logger = Arc::new(FilesystemLogger::new(ldk_data_dir.clone()));
+
+// Initialize the Network Graph.
+let network_graph_path = format!("{}/network_graph", ldk_data_dir.clone());
+let network_graph = Arc::new(disk::read_network(Path::new(&network_graph_path), args.network, logger.clone()));
+
+// Initialize the Scorer.
+let scorer_path = format!("{}/scorer", ldk_data_dir.clone());
+let scorer = Arc::new(RwLock::new(disk::read_scorer(
+    Path::new(&scorer_path),
+    Arc::clone(&network_graph),
+    Arc::clone(&logger),
+)));
+```
+
+To create the ```scorer```, the above code utilizes a ```read_scorer``` function, which resides in our application's ```disk.rs``` file. The function has been provided below. In it, you can see that we are first attempting to read the scorer from our application's data folder. If a scorer is available, we will use that. If not, we'll create a new scorer. It's worth noting that, if we decided to retrieve a scorer via an alternative method such as an HTTP server, we could adjust this function to include that logic.
+
+```rust
+pub(crate) fn read_scorer(
+	path: &Path, graph: Arc<NetworkGraph>, logger: Arc<FilesystemLogger>,
+) -> ProbabilisticScorer<Arc<NetworkGraph>, Arc<FilesystemLogger>> {
+	let params = ProbabilisticScoringDecayParameters::default();
+	if let Ok(file) = File::open(path) {
+		let args = (params.clone(), Arc::clone(&graph), Arc::clone(&logger));
+		if let Ok(scorer) = ProbabilisticScorer::read(&mut BufReader::new(file), args) {
+			return scorer;
+		}
+	}
+	ProbabilisticScorer::new(params, graph, logger)
+}
+```
+
+#### Setting Up Our Probing Logic
+For this example, we'll build a simple prober that fetches a random node from our ```NetworkGraph``` and attempts to send that node a random payment. We'll start by creating a function that fetches a random node from our ```NetworkGraph```. If we cannot find a node, the function will return, and we will not probe any nodes. If we're able to identify a node to probe, then we'll select a random payment amount of up to 500,000,000 milli-satoshis. As a reminder, 1 satoshi = 1,000 milli-satoshis. Finally, we'll get the public key for the node we selected and call ```send_probe```, which is defined later in this documentation.
+
+```rust
+fn send_rand_probe(
+    channel_manager: &ChannelManager, graph: &NetworkGraph,
+    logger: &disk::FilesystemLogger,
+    scorer: &RwLock<ProbabilisticScorer<Arc<NetworkGraph>, Arc<disk::FilesystemLogger>>>
+) {
+    let recipient = {
+	// Get read-only lock on graph.
+        let read_only_graph = graph.read_only();
+
+	// Check if graph has any nodes we can probe. If none, return.
+        if read_only_graph.nodes().is_empty() { 
+            return; 
+        }
+        // Select random node from the graph.
+        let mut it = read_only_graph.nodes().unordered_iter().skip(::rand::random::<usize>() % read_only_graph.nodes().len());
+        it.next().unwrap().0.clone()
+    };
+    
+    // Generate a random amount for the probe - up to 500,000,000 milli-satoshis.
+    let amt = ::rand::random::<u64>() % 500_000_000;
+
+    // If we can convert the node ID to a public key, send probe.
+    if let Ok(pk) = bitcoin::secp256k1::PublicKey::from_slice(recipient.as_slice()) {
+        send_probe(channel_manager, pk, graph, logger, amt, scorer);
+
+    // Else, return nothing and do not probe.
+    } else {
+    }
+}
+```
+
+#### Sending Probes
+Now that we've identified the recipient and amount for our probe, let's write a function to find the route for our payment. The ```ProbabilisticScorer``` that is used to score various routes will be passed as an input to this function. Recall that earlier, we discussed the concept of using multiple scorers. One scorer that we actually save results to and another un-updated scorer that can be used to identify routes with a "beginner's mind" - so to speak. If we'd like to leverage this approach, we can pass an un-updated scorer here and then update a different scorer with the results of the probe.
+
+Also, note that this function is referencing a ```ScorerAccountingForInFlightHtlcs```. This structure wraps around an existing scorer and incorporates information regarding in-flight (not yet settled) HTLC's, allowing our scorer to incorporate real-time payment flows as part of its routing optimization. We also define the scoring parameters, ```ProbabilisticScoringFeeParameters```, in this function. As discussed earlier, LDK provides default parameters, but you can customize these if you like.
+
+Finally, if we're able to find a route for our payment, we iterate over each path and send a probe.
+
+```rust
+fn send_probe(
+    channel_manager: &ChannelManager, recipient: PublicKey, graph: &NetworkGraph,
+    logger: &disk::FilesystemLogger, amt_msat: u64,
+    scorer: &RwLock<ProbabilisticScorer<Arc<NetworkGraph>, Arc<disk::FilesystemLogger>>>
+) {
+    // Get usable channels from the channel manager.
+    let chans = channel_manager.list_usable_channels();
+    let chan_refs = chans.iter().map(|a| a).collect::<Vec<_>>();
+
+    // Get payment parameters for the probe (payee features, route hints, max CLTV expiry delta, max hops, etc.)
+    let mut payment_params = PaymentParameters::from_node_id(recipient, 144);
+    payment_params.max_path_count = 1; // Limit to a single path for the probe
+
+    // Get in-flight HTLCs so we can account for in-use channel liquidity.
+    let in_flight_htlcs = channel_manager.compute_inflight_htlcs();
+
+    // Acquire a read lock on the scorer.
+    let scorer = scorer.read().unwrap();
+
+    // Create a scorer that accounts for in-flight HTLCs.
+    let inflight_scorer = ScorerAccountingForInFlightHtlcs::new(&scorer, &in_flight_htlcs);
+
+    // Use default scoring fee parameters.
+    let score_params: ProbabilisticScoringFeeParameters = Default::default();
+
+    // Attempt to find a route for the probe (routes can contain multiple paths)
+    let route_res = lightning::routing::router::find_route(
+        &channel_manager.get_our_node_id(),
+        &RouteParameters::from_payment_params_and_value(payment_params, amt_msat),
+        &graph, Some(&chan_refs), logger, &inflight_scorer, &score_params, &[32; 32]
+    );
+
+    match route_res {
+	Ok(route) => {
+		// Iterate over each path.
+		for path in route.paths {
+			let _ = channel_manager.send_probe(path);
+		}
+	},
+	Err(e) => {
+		println!("Failed to find a route: {:?}", e);
+	}
+    }
+}
+```
+
+#### Updating Our Scorer 
+
+LDK leverages an event-driven architecture, allowing for asynchronous result notification. Therefore, to update our scorer over time, we'll want to inform our application that it should be on the lookout for payment or probing-related events, as these are what indicate to our node that a given route has succeeded or failed. The specific events that we should be watching for and handling are ```Event::PaymentPathFailed```, ```Event::PaymentPathSuccessful```, ```Event::ProbeSuccessful```, and ```Event::ProbeFailed```. There are many other event types. For extensive documentation of LDK events, please see the [documentation](https://docs.rs/lightning/latest/lightning/events/enum.Event.html).
+
+To handle the above events and other tasks that either can or should run in the background, LDK provides the [```process_events_async```](https://docs.rs/lightning-background-processor/latest/lightning_background_processor/fn.process_events_async.html) function within the ```lightning-background-processor``` crate. When instantiated, this starts an asynchronous process of handling lightning network node operations, such as maintaining our node's view of the network graph, updating the scorer, and more. 
+
+To instantiate the background processor, you need to pass in the required components, handlers, and configuration parameters. It's worth noting that one of the handlers that is passed into this function is our own application's event handler. When the background processor picks up a new event, it will first intercept the event and, if applicable, handle it itself (ex: update and persist the scorer) before passing it on to the user's event handler.
+
+```rust
+// Create a watch channel for signaling background processor exit.
+//
+// bp_exit: Sender to signal the background processor to exit.
+// bp_exit_check: Receiver to check for exit signals in the background processor.
+//
+// This channel allows for a graceful shutdown of the background processor
+// by sending a signal that can be checked at appropriate intervals.
+let (bp_exit, bp_exit_check) = tokio::sync::watch::channel(());
+let mut background_processor = tokio::spawn(process_events_async(
+    Arc::clone(&persister),  // Persister for writing/reading from file system.
+    event_handler,           // Handler for processing various LDK events.
+    chain_monitor.clone(),   // Monitors blocks for relevant activity.
+    channel_manager.clone(), // Responsible for managing tasks related to channel state.
+    GossipSync::p2p(gossip_sync.clone()), // Handles P2P network gossip.
+    peer_manager.clone(),    // Manages peer connections and associated data.
+    logger.clone(),          // Logger for recording events and errors.
+    Some(scorer.clone()),    // Scorer for updating and persisting scoring updates.
+    move |t| {
+        // Custom sleep function that can be interrupted.
+        let mut bp_exit_fut_check = bp_exit_check.clone();
+        Box::pin(async move {
+            tokio::select! {
+                _ = tokio::time::sleep(t) => false,  // Sleep completed.
+                _ = bp_exit_fut_check.changed() => true,  // Exit signal received
+            }
+        })
+    },
+    false,  // Flag to indicate whether to interrupt on shutdown.
+    || Some(SystemTime::now().duration_since(SystemTime::UNIX_EPOCH).unwrap()),  // Current time provider.
+));
+```
+
+Once the background processor is started, it will call ```update_scorer``` as it handles relevant events. For informational purposes, the code that is executed within the background processor to update the scorer is provided below, but you do not need to implement this yourself.
+
+As you can see, when payments or probes fail, we update our scorer, further refining its internal estimations of available liquidity on the Lightning Network so that we're better able to route "real" payments when the time comes.
+
+```rust
+/// Updates scorer based on event and returns whether an update occurred so we can decide whether
+/// to persist.
+fn update_scorer<'a, S: 'static + Deref<Target = SC> + Send + Sync, SC: 'a + WriteableScore<'a>>(
+	scorer: &'a S, event: &Event, duration_since_epoch: Duration,
+) -> bool {
+	match event {
+		Event::PaymentPathFailed { ref path, short_channel_id: Some(scid), .. } => {
+			let mut score = scorer.write_lock();
+			score.payment_path_failed(path, *scid, duration_since_epoch);
+		},
+		Event::PaymentPathFailed { ref path, payment_failed_permanently: true, .. } => {
+			// Reached if the destination explicitly failed it back. We treat this as a successful probe
+			// because the payment made it all the way to the destination with sufficient liquidity.
+			let mut score = scorer.write_lock();
+			score.probe_successful(path, duration_since_epoch);
+		},
+		Event::PaymentPathSuccessful { path, .. } => {
+			let mut score = scorer.write_lock();
+			score.payment_path_successful(path, duration_since_epoch);
+		},
+		Event::ProbeSuccessful { path, .. } => {
+			let mut score = scorer.write_lock();
+			score.probe_successful(path, duration_since_epoch);
+		},
+		Event::ailed { path, short_channel_id: Some(scid), .. } => {
+			let mut score = scorer.write_lock();
+			score.probe_failed(path, *scid, duration_since_epoch);
+		},
+		_ => return false,
+	}
+	true
+}
+```
+
+It's important that our scorer also observes the passage of time. This is because if our scorer has not received any recent updates for a channel, it will need to broaden its current estimates for available channel liquidity. You can read more about the ```time_passed``` parameter in the [docs](https://docs.rs/lightning/latest/lightning/routing/scoring/trait.ScoreUpdate.html#tymethod.time_passed).
+
+Similar to handling payment and probe-related events, the background processor that we created in the previous section will call ```time_passed``` on our scorer and persist the updated scorer every 5 minutes.
+
+#### Sending Probes
+
+We're almost done! Now that we have probing functionality built out and the ability to update our scorer with the results, we just need to tell our application to send a probe randomly, once per minute. 
+
+Within your application, you will likely have a main entry point where you initialize important LDK components such as the ```ChannelManager```, ```ChainMonitor```, and the ```ProbabilisticScorer``` itself. Since all of the required components will be available within this asynchronous entry point, we can configure our app to send a probe every 60 seconds by calling the functions we previously created and passing in the required components.
+
+```rust
+// Regularly probe.
+let probing_cm = Arc::clone(&channel_manager);
+let probing_graph = Arc::clone(&network_graph);
+let probing_logger = Arc::clone(&logger);
+// Create a fresh scorer for probing.
+let probing_scorer = Arc::new(RwLock::new(ProbabilisticScorer::new(
+	ProbabilisticScoringDecayParameters::default(),
+	probing_graph.clone(),
+	probing_logger.clone(),
+)));
+tokio::spawn(async move {
+	let mut probe_interval = tokio::time::interval(Duration::from_secs(60));
+	loop {
+		probe_interval.tick().await;
+		send_rand_probe(&*probing_cm, &*probing_graph, &*probing_logger, &*probing_scorer);
+	}
+});
+```