<unnamed>

Public Key

npub13fccestrh5xf26m53n73xn5yly9z040a4n9vq30mernkj0cqszuq9tgaqs

Profile Code

nprofile1qqsg5uvvc93m6ry4dd6gelgnf6z0jz386h76ejkqghau3emf8uqgpwqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvdykgql

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-09 13:05:31 UTC

- reply

📅 Original date posted:2022-03-14
📝 Original message:
Hi Rene,
On Mon, Mar 14, 2022 at 12:56:24PM +0100, René Pickhardt via Lightning-dev wrote:
> > 1) What's the reasoning behind combining parallel channels?
> I think that should work and especially when including fees to the
> cost function and considering how nodes handle routing requests on
> parallel channels we might have to do so anyway.
I think lnd accepts the minimum fee of all parallel channels, even if
a higher fee rate is configured for the channel that is actually used.
I'm not too sure about this, though. Having parallel channels with
different fee settings seems weird to me, anyway.
> 1.1) A payment of size 2 needs to be split into 1+1 to fit through
> However I believe in practice one cannot just send a 2 satoshi onion and
> expect the routing node to split the amount correctly / accordingly
> between the two parallel channels. (I might be wrong here).
Exactly. This kind of split could be possible in theory, but at least
lnd doesn't do it. I guess there are lots of interesting questions to
answer before this becomes reality (channel jamming?).
> So in that case
> modelling and computing probabilities for parallel channels might be
> necessary anyway though the math indicates that splitting liquidity in
> parallel channels will get you selected less frequently for routing.
Which is OK, as in reality it IS less likely to succeed.
> 1.2) The Mission Control information provided by lnd [...]
> I think you talk a about a maximum available balance of a channel (and not
> min available balance)?
Yes, although MC also has information about "known" amounts (due to
failures that only happened further down the road).
> In the case of parallel channels I am not even sure if such information is
> accurate as it is my understanding that the routing node may decide to use
> the parallel channel to forward the amount even though the other channel
> was specified in the onion.
The routing node is free to pick any of the parallel channels, yes. The
MC data only reasons about pairs of nodes, though, not individual
channels.
> Assuming that routing nodes indeed do so we would have learnt that neither
> channel has an effective capacity of N. So the combined virtual channel
> could be seen as 2N-1.
You mean 2(N-1) = 2N-2?
> However if routing nodes don't locally split a
> forwarding request across both channels we would know that calaculating
> with 2N-1 is bad as a request of N could not be fulfilled.
Exactly, also for 2N-2. Only N-1 would be a reasonable assumption.
Based on your responses I'll treat parallel channels individually, and
see how it works out.
> > 3) Size of Piecewise Linearization
> The main difference here is that a channel of 1 BTC is highly preferable
> from a probabilistic payment delivery perspective over a channel of 0.01
> BTC. Even approximating the 1 BTC channel with 1000 intervalls of 0.001 BTC
> should still have a lower unit cost in all pieces of the first 0.01 BTC of
> the liquidity than the first piece of the 0.01 BTC channel. So I think
> splitting all channels in the equal number of pieces is pretty well
> motivated but let me elaborate on this:
OK great, got it.
> > 4) Leftovers after Piecewise Linearization
> I am not sure if I understand your question / issue here. The splitting
> works by selecting N points on the domain of the function and splitting the
> domain into segments at those points. This should never leave sats over.
With quantization of 10,000 a channel of size 123,456 ends up as an arc
with a capacity of 12 units. Cutting this into 5 pieces gives us
5*2 with 2 units not ending up in any of those pieces. Or am I missing
something here, and we should split into 5 pieces of size 2.4 = 12/5?
> If the quantization however makes a channel so small that we cannot
> even create 5 (or N) disjoint segments then I guess the likelihood for
> being included into the final result is too small anyway.
It may not be very likely, but flat-out ignoring 20k sat (in my
contrived example above) or up to 4*quantization sats (which is the case
you described) doesn't feel right.
> Again this yield interesting pruning opportunities to reduce the seize of
> the network before doing the expensive min cost flow computation. For
> example I could prune channels with high unit costs on the first segment.
> Especially if they are further away from the source and destination node.
> This would overall reduce the size of the graph and improve runtime.
Let's talk about optimizations later :)
> 5) Fees (and other properties?)
> arcs.append((src,dest,int(cap/(N*QUANTIZATION)),(i+1)*unit_cost +
> mu*fee_rate_ppm))
Great, that helps! Thanks alot!
> Note two things:
> 1. the only requirement for the solver to work is that \mu*fee_rate_ppm
> needs to be an integer. So in case \mu was smaller than 1 we could also
> scale the term from the linearized log probabilities by putting a larger mu
> to the feature arising from the cost of the uncertainty.
Good to know!
Bye,
Carsten
--
Dr. Carsten Otto
carsten at c-otto.de
https://c-otto.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220314/2418fb43/attachment.sig>

2023-06-09 13:05:30 UTC

- reply

📅 Original date posted:2022-03-13
📝 Original message:
Hi Rene,
thanks a lot for your contribution! This is exactly what I needed to
start coding again :) I intend to release a somewhat usable version of
your approach in lnd-manageJ [1] soon. Preliminary results indicate that
results (i.e. MPPs to try) can be computed in less than a second, which
is great!
Important remark: my code can only be used for real MPPs once a usable
MPP gRPC call is made available, see lnd issue #5746 [2].
While working on my implementation, a few questions came to mind:
1) What's the reasoning behind combining parallel channels?
I agree that parallel channels make things a lot more complicated, but I
also see the benefit from a node operator's point of view. That being
said, wouldn't it suffice to treat parallel channels individually?
1.1) A payment of size 2 needs to be split into 1+1 to fit through
parallel channels of size 1+1. Combining the 1+1 channels into a virtual
channel of size 2 only complicates the code that has to do come up with
a MPP that doesn't over-saturate the actual channels. On the other hand,
I don't think the probability for the virtual channel of size 2 is more
realistic than reasoning about two individual channels and their
probabilities - but I didn't even try to see the math behind that.
Please prove me wrong? :)
1.2) The Mission Control information provided by lnd can be used to
place a minimum available balance on each of the parallel channels. If
we know that node A isn't able to forward N sats to node B, we can treat
all parallel channels between A and B (in that direction) to have a
capacity of at most N-1 sats. How would this look like if we combined
the parallel channels into a virtual one? Note that it may still be
possible to route two individual payments/onions of size N-1 sats from A
to B, given two parallel channels with that many sats on A's side.
2) Optimal Piecewise Linearization
See Twitter [3].
Is it worth it cutting a channel into pieces of different sizes, instead
of just having (as per your example) 5 pieces of the same size? If it
makes a noticeable difference, adding some complexity to the code might
be worth it.
3) Size of Piecewise Linearization
My gut feeling is that cutting a 1 BTC channel into 5 pieces is
different from cutting a 0.01 BTC channel into 5 pieces. Would it make
sense to use different values of N depending on the channel size?
4) Leftovers after Piecewise Linearization
If I cut some channel into N pieces, I might end up with up to N-1 sats
that don't end up in any of the N pieces, effectively making the channel
look smaller than it is. For smaller values of N that's obviously not an
issue (given the uncertainty we're dealing with), but it might be more
problematic if quantization is used with larger values. Any thoughts on
this?
5) Fees (and other properties?)
How can we integrate fees into the function? I must admit, I haven't
even thought about that, yet. A copy-paste answer would be great,
though! :) Maybe it's also a good idea to punish channels based on their
CLTV delta? Ratio of enabled channels? Age? Manual punishment score? ...
6) Non-Zero Base Fee
See Twitter [4].
According to Stefan [5] it should be possible to integrate ZmnSCPxj's ideas
to make this work with non-zero base fees. How?
Simpler approach: Twitter [6].
7) Private Channels
[very niche topic, not really that interesting nor urgent]
I'm a fan of adding private channels to provide more outbound liquidity,
mainly to reduce gossip and hide my intentions. If my total liquidity to
some peer is below the amount announced in public channels, I don't see
any meaningful complication. However, I might have a public channel of
size N and several private channels bringing my local liquidity to some
value >N. It's rather obvious that not announcing this fact is a bad
idea, as any #pickhardtpayments implementation would think I have 0-N on
my side of the channel(s). Assuming I'm willing to accept this tradeoff,
do you see other complications or issues with hidden liquidity?
My gut feeling is that this isn't an issue, at all, as channel balances
change all the time, which is something the algorithm already has to
deal with.
8) Quality of Approximation
There are some problems in computer science that are hard/impossible to
approximate, in the sense that any kind of deviation from the optimum
could cause the computed results to be extremely bad. Do you have some
idea (or proof) that your kind of approximation isn't causing a major
issue? I guess a piece-wise linearization with an infinite number of
pieces corresponds to the optimal result. Given a finite number of
pieces, how large is the difference to the optimum?
Bye,
Carsten
1: https://github.com/C-Otto/lnd-manageJ/issues/6
2: https://github.com/lightningnetwork/lnd/issues/5746
3: https://twitter.com/c_otto83/status/1502329970349248521
4: https://twitter.com/c_otto83/status/1502329271964033027
5: https://twitter.com/stefanwouldgo/status/1502681455918473217
6: https://twitter.com/c_otto83/status/1502330558793363464
--
Dr. Carsten Otto
carsten at c-otto.de
https://c-otto.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220313/1437e67a/attachment.sig>

2023-06-09 12:50:21 UTC

- reply

📅 Original date posted:2018-05-03
📝 Original message:
Hi ZmnSCPxj, Christian, list,
the paper is a bit confusing regarding the setup transaction, as it is
not described formally. There also seems to be a mixup of "setup
transaction" and "funding transaction", also named T_{u,0} without
showing it in the diagrams.
In 3.1 the funding transaction is described as funding "to a multisig
address". In the description of trigger transactions the change is
described as "The output from the setup transaction is changed into a
simple 2-of-2 multisig output" - which it already is?
As far as I understand the situation, the the trigger transaction is
needed because the broadcasted initial/funding/setup transaction
includes an OP_CLV (possibly enforcing premature settlement). Removing
OP_CLV, i.e. by changing it to a simple multisig output, seems to solve
this issue.
Could you (Christian?) explain how the "setup transaction" is supposed
to look like without the changes described in section 4.2?
I like the idea proposed by ZmnSCPxj, but I'm not able to weigh the
pro/cons of both approaches. For a direct unilateral close both peers
would need to know the first update transaction and an attached
settlement transaction, which is comparable to the approach presented in
the paper (trigger transaction and settlement transaction).
The main advantage of getting rid of the trigger transaction seems to be
that only two transactions (latest update and settlement) have to be
committed to the blockchain in the unilateral case, compared to three
(trigger, latest update, settlement) in the approach presented in the
paper.
Bye,
Carsten
--
andrena objects ag
Ganghoferstraße 70
80339 München
http://www.andrena.de
Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger
Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
Bitte beachten Sie auch unsere anstehenden Veranstaltungen:
http://www.andrena.de/events
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180503/571cf9bf/attachment.sig>