📅 Original date posted:2018-07-29
📝 Original message:
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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:51:15
in reply to nevent1q…kaxq
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:51:15Event JSON
{
"id": "dfb46c4d49a46c94c4a711c5fddd8ab45bc1e9620bc97f5b67d14ee13fd93392",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315075,
"kind": 1,
"tags": [
[
"e",
"1acc9f868261c1770975f63c7dfb24b359e428c6c6b46dc1dc11c9b0e81bb82d",
"",
"root"
],
[
"e",
"6359d96bcf902df399d49372d5b8b2d24874ed6ee76d89149ed111ec9b4bca60",
"",
"reply"
],
[
"p",
"5908e658402441804ddfaf4e2df139840e31e21fe3a7a0d570f451ec2b0b37b4"
]
],
"content": "📅 Original date posted:2018-07-29\n📝 Original message:\nRobert Olsson \u003crobban at robtex.com\u003e writes:\n\u003e I think however it would be much better and flexible to append a max to\n\u003e channel_update. We already have htlc_minimum_msat there and could add\n\u003e htlc_maximum_msat to show capacity (minus fees)\n\u003e Like this:\n\u003e\n\u003e\n\u003e 1. type: 258 (channel_update)\n\u003e 2. data:\n\u003e - [64:signature]\n\u003e - [32:chain_hash]\n\u003e - [8:short_channel_id]\n\u003e - [4:timestamp]\n\u003e - [2:flags]\n\u003e - [2:cltv_expiry_delta]\n\u003e - [8:htlc_minimum_msat]\n\u003e - [4:fee_base_msat]\n\u003e - [4:fee_proportional_millionths]\n\u003e\n\u003e - [8:htlc_maximum_msat]\n\nThis isn't about maximum HTLC value, rather Артём is talking about\nadding the total channel capacity to the channel_announcement. That is a\nperfectly reasonable idea, as it allows us to safe an on-chain lookup\n(incidentally that is the main reason we started tracking an internal\nUTXO set so we can stop asking bitcoind for full blocks just to check a\nchannel's capacity).\n\nThe channel's capacity is also fixed for the existence of that channel\n(splice-in and splice-out will result in new short channel IDs), so the\nannouncement is exactly the right place to put this.\n\nCheers,\nChristian",
"sig": "b4588d2ddbad61120d96b028a94a80116bb23f68e3a020d077e608ef732a1b28361b8401198333306ed5420c81478b63e14fa2a54a2c7e45b095571687351431"
}