↳ 回复 kidwarp (npub1kyeml3tma4su8yw5aru48wgxclchp8zr3kguwhakmtmegjw40zws82sfjk)
Isn’t this nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5 zaplocker functiona...
It has some things in common but Zeus's zaplocker functionality is not as good. With zaplocker, if Alice sends a payment Alice -> Bob -> Carol -> Dave...
It has some things in common but Zeus's zaplocker functionality is not as good. With zaplocker, if Alice sends a payment Alice -> Bob -> Carol -> Dave, three people -- Alice, Bob and Carol -- all have to fund an htlc and keep it pending til Dave gets online.
With LDK's protocol, only Alice funds an htlc and keeps it pending. This is better because pending htlcs on the lightning network are a constrained resource, so creating fewer of them is good.
In case you want to know why pending htlcs are a constrained resource, it is because pending htlcs temporarily consume two other limited resources on nodes: htlc slots and outbound capacity.
Each channel has a limited amount of outbound capacity because that is money and no one has unlimited money. Each channel also has a limited number of htlcs that can be pending at once, for several reasons. One of them is that, when force closing a channel, all of your pending htlcs have to be represented on the blockchain as the outputs and sometimes the inputs of one or more transactions. Each additional one takes up more bytes, and transactions can only be a limited size, so there is a number X where you can't have more than X inputs+outputs in a transaction, and therefore can't have more than X pending htlcs in a channel.
Kind-1 (TextNote)