Pickhardt Payments in lnd-manageJ - AMA \ stacker news ~bitcoin

pull down to refresh

37 sats \ 4 comments \ @C_Otto 4 Apr 2022 bitcoin

There's some basic support for #pickhardtpayments in lnd-manageJ (https://github.com/C-Otto/lnd-manageJ). This is work in progress and, currently, you can't actually send payments. Instead, you can compute routes, i.e. split your large payment into different pieces that together form an MPP.

Introduction to the current state: https://twitter.com/c_otto83/status/1510051269255344128

I'm curious about your questions and I'd be happy to answer them!

view all related items

1 sat \ 3 replies \ @DarthCoin 4 Apr 2022

I would like to see in all LN implementations a protocol that will optimize the flow of routed txs. I really don't understand why this secrecy with not announcing the actual balance in a channel? You can easily know (more or less) the amount of balance from public data, operators are so predicted using specific fees policies and you can guess easily their balance. Anyway is a useless information, a bad actor what can do with that info? Nothing. We are just trying to hide behind the finger. Instead we can have in the LN protocol something like:

node announce his balance on each channel
payment arrive
check the local balance
if the payment is higher than x amount, split the payment into x parts and take multiple channels, to not drain just one channel
operator can use same fee for all channels in this case
no need crazy useless re-balancing (I think we have now more than 50% of LN traffic in re-balancing txs), this is totally useless and can congest the whole network with traffic that is NOT necessary, if we have a better protocol to optimize the balances and path finding.

0 sats \ 2 replies \ @C_Otto OP 4 Apr 2022 freebie

One issue is that you'd need to communicate your balance (if you wanted to). Constantly updating this information puts enormous pressure on the network. I think BOLT 14 (letting peers know your other peers' balances) is a step forward, and I agree that most of this information is not as private as it appears to be.

Splitting a payment locally is... tricky. I think the first step would be to join payments that come in via (at least) two different source channels.