📅 Original date posted:2018-07-29 📝 Original message: They are orthogonal, I ...

Christian Decker [ARCHIVE] /

npub1wtx…tuyn

2023-06-09 12:51:15

in reply to nevent1q…dnxa

📅 Original date posted:2018-07-29
📝 Original message:
They are orthogonal, I agree, but we should judge their merits
independently, and not batch the discussions out of convenience.
In the case of the htlc_maximum_msat I think it will not be
controversial, but it should get its own proposal and discussion.

Cheers,
Christian
On Sun, Jul 29, 2018 at 4:17 PM Robert Olsson <robban at robtex.com> wrote:
>
> Christian,
>
> Ok, it definitely makes sense to include the exact fixed capacity in channel_announcement for the reason you mentioned, and more.
>
> However, can we do both while we are at it? The ideas are not mutually exclusive, and for successful routing, i think the channel_update-approach is much more of a boost.
>
> Regards,
> Robert
>
>
> On Sun, Jul 29, 2018 at 4:59 PM, Christian Decker <decker.christian at gmail.com> wrote:
>>
>> Robert Olsson <robban at robtex.com> writes:
>> > I think however it would be much better and flexible to append a max to
>> > channel_update. We already have htlc_minimum_msat there and could add
>> > htlc_maximum_msat to show capacity (minus fees)
>> > Like this:
>> >
>> >
>> > 1. type: 258 (channel_update)
>> > 2. data:
>> > - [64:signature]
>> > - [32:chain_hash]
>> > - [8:short_channel_id]
>> > - [4:timestamp]
>> > - [2:flags]
>> > - [2:cltv_expiry_delta]
>> > - [8:htlc_minimum_msat]
>> > - [4:fee_base_msat]
>> > - [4:fee_proportional_millionths]
>> >
>> > - [8:htlc_maximum_msat]
>>
>> This isn't about maximum HTLC value, rather Артём is talking about
>> adding the total channel capacity to the channel_announcement. That is a
>> perfectly reasonable idea, as it allows us to safe an on-chain lookup
>> (incidentally that is the main reason we started tracking an internal
>> UTXO set so we can stop asking bitcoind for full blocks just to check a
>> channel's capacity).
>>
>> The channel's capacity is also fixed for the existence of that channel
>> (splice-in and splice-out will result in new short channel IDs), so the
>> announcement is exactly the right place to put this.
>>
>> Cheers,
>> Christian
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Author Public Key

npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn

Show more details

Published at

2023-06-09 12:51:15

Kind type

1 Short Text Note

Event JSON

{ "id": "7c52a01c5d359a0267b43f42d70b3cdc4154da2ffd876f6c9053a9f70e34fc4f", "pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057", "created_at": 1686315075, "kind": 1, "tags": [ [ "e", "1acc9f868261c1770975f63c7dfb24b359e428c6c6b46dc1dc11c9b0e81bb82d", "", "root" ], [ "e", "bdb2a992df5c9c84c1f5a8c278b93faafc0ab1eedd223b3d1881129e3dd066ed", "", "reply" ], [ "p", "5908e658402441804ddfaf4e2df139840e31e21fe3a7a0d570f451ec2b0b37b4" ] ], "content": "📅 Original date posted:2018-07-29\n📝 Original message:\nThey are orthogonal, I agree, but we should judge their merits\nindependently, and not batch the discussions out of convenience.\nIn the case of the htlc_maximum_msat I think it will not be\ncontroversial, but it should get its own proposal and discussion.\n\nCheers,\nChristian\nOn Sun, Jul 29, 2018 at 4:17 PM Robert Olsson \u003crobban at robtex.com\u003e wrote:\n\u003e\n\u003e Christian,\n\u003e\n\u003e Ok, it definitely makes sense to include the exact fixed capacity in channel_announcement for the reason you mentioned, and more.\n\u003e\n\u003e However, can we do both while we are at it? The ideas are not mutually exclusive, and for successful routing, i think the channel_update-approach is much more of a boost.\n\u003e\n\u003e Regards,\n\u003e Robert\n\u003e\n\u003e\n\u003e On Sun, Jul 29, 2018 at 4:59 PM, Christian Decker \u003cdecker.christian at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e Robert Olsson \u003crobban at robtex.com\u003e writes:\n\u003e\u003e \u003e I think however it would be much better and flexible to append a max to\n\u003e\u003e \u003e channel_update. We already have htlc_minimum_msat there and could add\n\u003e\u003e \u003e htlc_maximum_msat to show capacity (minus fees)\n\u003e\u003e \u003e Like this:\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e 1. type: 258 (channel_update)\n\u003e\u003e \u003e 2. data:\n\u003e\u003e \u003e - [64:signature]\n\u003e\u003e \u003e - [32:chain_hash]\n\u003e\u003e \u003e - [8:short_channel_id]\n\u003e\u003e \u003e - [4:timestamp]\n\u003e\u003e \u003e - [2:flags]\n\u003e\u003e \u003e - [2:cltv_expiry_delta]\n\u003e\u003e \u003e - [8:htlc_minimum_msat]\n\u003e\u003e \u003e - [4:fee_base_msat]\n\u003e\u003e \u003e - [4:fee_proportional_millionths]\n\u003e\u003e \u003e\n\u003e\u003e \u003e - [8:htlc_maximum_msat]\n\u003e\u003e\n\u003e\u003e This isn't about maximum HTLC value, rather Артём is talking about\n\u003e\u003e adding the total channel capacity to the channel_announcement. That is a\n\u003e\u003e perfectly reasonable idea, as it allows us to safe an on-chain lookup\n\u003e\u003e (incidentally that is the main reason we started tracking an internal\n\u003e\u003e UTXO set so we can stop asking bitcoind for full blocks just to check a\n\u003e\u003e channel's capacity).\n\u003e\u003e\n\u003e\u003e The channel's capacity is also fixed for the existence of that channel\n\u003e\u003e (splice-in and splice-out will result in new short channel IDs), so the\n\u003e\u003e announcement is exactly the right place to put this.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Christian\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev", "sig": "59f8d87f4d79f9201a98a73469cca7281d52fbaa82a8e333e9491df8933cb19537acb1b68d992168aab0e9dc45cea1515459e8add1ffa9ca489b57fdde215ccf" }