#dev #CLN
One of the fun things after a release is that I sweep the code and remove things which are now past the end of their deprecation cycle, and then update to the latest BOLT specs. The former is usually trivial (this time there were only two things to remove, and nobody will care). The latter can be more interesting, and was.
Our code contains quotes from the BOLT they are implementing, so when we update the version it reports what has changed. Sometimes it's merely a typo fix, but since last release we actually made a pile of old features ASSUMED. This includes "option_static_remotekey" which we supported in CLN since January 2019 release, meaning you will only see channels without this if they were opened more than 5 years ago. We still support these existing channels, but all support was removed for opening new ones.
The other option is "option_anchor_outputs": we were the only ones to ever deploy this, and then only in experimental mode, because zero-fee anchors quickly replaced it.
Unfortunate to I don't know how many (if any!) such channels there are!
So what do we do about existing channels? I can enable the currently-experimental code to migrate such channels, which works if both ends are CLN. But it's not clear how much further I should go: my spec proposal for upgrade has been in limbo for years, and at some point it's far cheaper to pay a handful of people to reopen their channels than it is to do the engineering required for migration.
It's a few versions away yet, but at some point we will have to refuse to upgrade if the user has such a channel, in the hope they will contact us if it happens.
Rusty Russell
npub179e…lz4s
2024-06-16 01:12:46
Author Public Key
npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4sPublished at
2024-06-16 01:12:46Event JSON
{
"id": "3683f9741f27770551e1a89bf420c79c2d24de7666017ccacf30dce8badadb20",
"pubkey": "f1725586a402c06aec818d1478a45aaa0dc16c7a9c4869d97c350336d16f8e43",
"created_at": 1718493166,
"kind": 1,
"tags": [
[
"t",
"dev"
],
[
"t",
"CLN"
],
[
"t",
"cln"
]
],
"content": "#dev #CLN\n\nOne of the fun things after a release is that I sweep the code and remove things which are now past the end of their deprecation cycle, and then update to the latest BOLT specs. The former is usually trivial (this time there were only two things to remove, and nobody will care). The latter can be more interesting, and was. \n\nOur code contains quotes from the BOLT they are implementing, so when we update the version it reports what has changed. Sometimes it's merely a typo fix, but since last release we actually made a pile of old features ASSUMED. This includes \"option_static_remotekey\" which we supported in CLN since January 2019 release, meaning you will only see channels without this if they were opened more than 5 years ago. We still support these existing channels, but all support was removed for opening new ones.\n\nThe other option is \"option_anchor_outputs\": we were the only ones to ever deploy this, and then only in experimental mode, because zero-fee anchors quickly replaced it.\n\nUnfortunate to I don't know how many (if any!) such channels there are! \n\nSo what do we do about existing channels? I can enable the currently-experimental code to migrate such channels, which works if both ends are CLN. But it's not clear how much further I should go: my spec proposal for upgrade has been in limbo for years, and at some point it's far cheaper to pay a handful of people to reopen their channels than it is to do the engineering required for migration.\n\nIt's a few versions away yet, but at some point we will have to refuse to upgrade if the user has such a channel, in the hope they will contact us if it happens. ",
"sig": "f587674d305bdf7ea798de08166b3f955e731457bd2ee237618e6da4c2be62082458a1193ce6e1723cad999263aef083473d1d8b41d5332925d919e916734e90"
}