Lightning Specification Meeting 2024/01/29

[t-bast]

Lightning Specification Meeting 2024/01/29

[Roasbeef]

dual funding:

• forces you to provide the whole prev transaction for the input
  • issue in practice as means restricted to 65 KB
  • if trying to bring funds into a channel or mining pay out, etc
  • proposal: get rid of this
  • alternative: paper around the 65 KB limit w/ application level chunking or transport level chunking
  • why do we need this at all?
    • case where there's a mixed input in a unconfirmed transaction, it can modify the tx?
    • unclear how it can be exploited in the first place
    • all the inputs of unconfirmed transaction as input to funding tx need to be pure segwit

rbf-coop close:

• in bitcoind 25, OP_RETURN must now have a zero value output
• interaction with the older version?
  • single funder, all funds on the side of Bob,
• altruistic version:
  • you can't pay for fees, but you send closing_complete, then send no_closer_closee
• lnd close to do interop with eclair, CLN has next release, then working to make concrete

trampoline:

• chat last time about modifying the onion construct: prefix, or onion within the onion
• have implemented relaying to a blinded path
• arik fine with keeping as is, working thru impl

channel jamming

• do we have a feature bit?
  • can only start setting as the sender once more of the network has been updated
  • can use a high feature bit for now
  • yes: should make a PR to the BOLTs to specify a feature bit
• experiment:
  • learning circuit breaker along side, able to drop the rep down to zero based on w/e azlgo
  • collect the signals the be able to dry run the rep on mainnet

[carlaKC]

Bumping from last meeting: lightning/blips#27

[t-bast]

why do we need this at all?

• case where there's a mixed input in a unconfirmed transaction, it can modify the tx?
• unclear how it can be exploited in the first place
• all the inputs of unconfirmed transaction as input to funding tx need to be pure segwit

I've figured out the details, and explained them here: https://delvingbitcoin.org/t/malleability-issues-when-creating-shared-transactions-with-segwit-v0/497

That means we cannot simply drop the prevtx field from tx_add_input messages that claim to use taproot, because that could be a lie. We can only allow the other participant to omit the prevtx field from their tx_add_input messages if we know we will include a taproot input on our side, which will commit to the scriptPubKeys our peer claims to use.

[ariard]

channel jamming

have the credentials in its own embedded rust lib, working poc: https://github.com/ariard/staking-credentials
works well for 1-to-1 coverage of liquidity usage (1sat of liquidity covered by 1sat of pre-paid token).