Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lnwire: add InboundFee struct in-line within ChannelUpdate #8604

Open
Roasbeef opened this issue Mar 30, 2024 · 2 comments
Open

lnwire: add InboundFee struct in-line within ChannelUpdate #8604

Roasbeef opened this issue Mar 30, 2024 · 2 comments
Labels
enhancement Improvements to existing features / behaviour fees Related to the fees paid for transactions (both LN and funding/commitment transactions) inbound fee Changes related to inbound routing fee intermediate Issues suitable for developers moderately familiar with the codebase and LN P2 should be fixed if one has time wire protocol Encoding of messages for the communication between nodes

Comments

@Roasbeef
Copy link
Member

In #6703 the new inbound fee field is added. However, it isn't added directly to the struct, instead the caller must always manually copy the field into the opaque data field, and also must always manually parse it out the other end. We should make this new field uniform with the other TLC fields by adding it directly within the struct. While we're at it, we can also morph it into tlv.OptionalRecord.

@Roasbeef Roasbeef added enhancement Improvements to existing features / behaviour wire protocol Encoding of messages for the communication between nodes intermediate Issues suitable for developers moderately familiar with the codebase and LN fees Related to the fees paid for transactions (both LN and funding/commitment transactions) inbound fee Changes related to inbound routing fee labels Mar 30, 2024
@saubyk saubyk added P1 MUST be fixed or reviewed P2 should be fixed if one has time and removed P1 MUST be fixed or reviewed labels Apr 2, 2024
@joostjager
Copy link
Contributor

Inbound fees are using a custom tlv id in the high range. I think this would require more flexibility in gen_tlv_types.go?

@Roasbeef
Copy link
Member Author

@joostjager good question, so we can just make entirely new definitions, if we don't want to add 40k extra lines to that file, like so:

type tlvType50000 {}

func (t tlvType50000) TypeVal() {
    50_000
}

func (t tlvType50000) tlv() {}


type TlvType50000 = *tlvType50000

The set up doesn't require that only the code generation be used, just that all new instnaces must be defined in the package.

Not explcitily related, but while we're at it, we can likely simplify from tlv.TlvType5 to tlv.Type5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements to existing features / behaviour fees Related to the fees paid for transactions (both LN and funding/commitment transactions) inbound fee Changes related to inbound routing fee intermediate Issues suitable for developers moderately familiar with the codebase and LN P2 should be fixed if one has time wire protocol Encoding of messages for the communication between nodes
Projects
None yet
Development

No branches or pull requests

3 participants