niftynei [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2023-03-30 to 2023-04-24
💬 Posted a total of 4 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:13:06

- reply

📅 Original date posted:2023-04-24
🗒️ Summary of this message: The Lightning community emphasizes the importance of public communication in technical discussions to document options and encourage new participants to contribute.
📝 Original message:
Hi all,
When I joined the lightning community a few years ago, I was relatively new
to open source software and specification work. Rusty really impressed on
me on the importance of holding conversations, as much as possible in
public.
Practically speaking, this encompasses IRC, this mailing list, and github
issues/PRs.
The reason for this is twofold. It helps document the range of options
considered for technical decisions and it provides an interface point for
new participants to contribute to the discussion.
Given some recent mails that were posted to this list, now seems like a
good time to reiterate the importance and preference of public
communication whenever possible, especially for specification or technical
discussions.
~ nifty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230424/d37aa552/attachment-0001.html>

2023-06-09 13:13:04

- reply

📅 Original date posted:2023-04-24
🗒️ Summary of this message: The CLN project is decoupled from the block source, allowing node runners to choose a block backend that fits their self-sovereignty goals. Breaking out the validation and peering functions of Bitcoin Core into more composable parts could open up more opportunities for building block sources for a wide variety of projects. There may be an opportunity to "comingle" the peering of LN gossip and block data networks.
📝 Original message:
Hi Michael,
CLN as implemented is currently nicely decoupled from the block source; as
a project we assume that the node runner will choose a block backend that
fits their self-sovereignty goals.
This provides us with a nice separation of concerns. The block source is
responsible for ensuring that only consensus valid data is delivered to the
node, which in turn allows us to focus on processing and reacting to that
data, as necessary.
Bitcoin core as a project implements a broad swath of functionality
(wallet, consensus, peering, rpc server, coin selection, key management,
etc); breaking out the validation and peering functions into more
composable parts would def open up more opportunities for building block
sources for a wide variety of projects, not just CLN.
There’s probably a real opportunity to “comingle” the peering of LN gossip
+ block data networks, this has been suggested a few times but never
seriously pursued from the LN side. Having the peering functions of
bitcoin-core broken out into a more composable/reusable piece may be a good
first step here, and as a project would largely be on the bitcoin core
side. Maybe this work is already in progress? I havent been keeping up with
developments there.
Thanks for the email, it’s definitely a good question.
Lisa
On Mon, Apr 24, 2023 at 02:09 Michael Folkson via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Any thoughts on this from the Core Lightning contributors? The way I see
> it with upcoming proposed changes to default policy (primarily though not
> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
> (primarily though not exclusively for Lightning) that a tighter coupling
> between the full node and the Lightning node could eventually make sense.
> In a world where transaction fees were much higher you'd think almost every
> full node would also want to be a Lightning node and so the separation of
> concerns would make less sense. Having two separate P2P networks and two
> separate P2P protocols also wouldn't make much sense in this scenario. You
> could obviously still opt out of Lightning P2P messages if you weren't
> interested in Lightning.
>
> The alternative would be just to focus on Knots style consensus compatible
> forks of Core with limited additional functionality. But I think we've
> reached the point of no return on Core dominance and not having widely used
> "distros". As the ecosystem scales systems and processes should be
> constantly evolving and improving and to me if anything Core's seem to be
> going backwards.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
>
> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <
> michaelfolkson at protonmail.com> wrote:
>
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in
> Core increasingly thinking @BitcoinKnots and consensus compatible forks of
> Core are the future. Gonna chalk that one up to another thing @LukeDashjr
> was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
> with Core Lightning was a long term idea I had (and presumably many others
> have had) but the dysfunction on the Bitcoin Core project this week (if
> anything it has been getting worse over time, not better) has made me start
> to take the idea more seriously. It is clear to me that the current way the
> Bitcoin Core project is being managed is not how I would like an open
> source project to be managed. Very little discussion is public anymore and
> decisions seem to be increasingly made behind closed doors or in private
> IRC channels (to the extent that decisions are made at all). Core Lightning
> seems to have the opposite problem. It is managed effectively in the open
> (admittedly with fewer contributors) but doesn't have the eyeballs or the
> usage that Bitcoin Core does. Regardless, selfishly I at some point would
> like a bare bones Bitcoin and Lightning implementation integrated in one
> codebase. The Bitcoin Core codebase has collected a lot of cruft over time
> and the ultra conservatism that is needed when treating (potential)
> consensus code seems to permeate into parts of the codebase that no one is
> using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus
> engine out of Core but it seems like it won't achieve that as consensus is
> just too slippery a concept and Knots style consensus compatible codebase
> forks of Bitcoin Core seem to still the model. To what extent you can
> safely chop off this cruft and effectively maintain this less crufty fork
> of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code
> that people have different views on. C++ is obviously a superset of C but
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal
> final destination it surely would have been better if Core Lightning was
> written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much
> more familiar with the entirety of the Bitcoin Core and Core Lightning
> codebases. It would be an ambitious long term project but it would be nice
> to focus on some ambitious project(s) (even if just conceptually) for a
> while given (thankfully) there seems to be a lull in soft fork activation
> chaos.
>
> Thanks
> Michael
>
> [0]:
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230424/911bc9d0/attachment-0001.html>

2023-06-09 13:12:56

- reply

📅 Original date posted:2023-03-30
🗒️ Summary of this message: The author questions whether all commitment-sigs should be re-sent after a new splice is negotiated, suggesting only the new one should be sent.
📝 Original message:
This feels sort of dumb but I wrote it up and thought maybe others would
find it enlightening.
There's been a question of whether or not we should re-send all of the
commitment-sigs after a new splice has been negotiated. The current CLN
draft of splicing sends all of them, should we only send the one?
After writing this out, it seems fairly obvious to me that the correct way
forward is to only send a commitment sig for the newly negotiated splice;
all of the commitment sigs should be re-sent only when the underlying
commitment tx changes (eg. htlc added/removed).
Longer analysis below.
As an interesting 'historical aside', in the original splicing draft
proposal, all commitment sigs were sent in a single message; we've since
split them out into more messages, which now nicely allows for only sending
the new commitment_signed message when appropriate.
~nifty
h/t to @ddustin and @t-bast for surfacing this.
# Should we re-send commit_sigs + revoke_and_ack for newly negotiated
splices?
## Background
When a splice tx is successfully negotiated, we need to send a
commitment-sig to the peer to be able to send the new funding tx.
After `tx_complete`, we need to exchange the `commitment_sig` for the newly
created splice tx.
## Purpose of `commitment_signed`
The purpose of the `commitment_signed` message is to send the peer your
commitment sig for the currently proposed commitment.
## Purpose of `revoke_and_ack`
The purpose of `revoke_and_ack` is two-fold:
- Send a revocation point for the previous commitment transaction, REVOKING
the previous commitment
- ACK that the commitment sig has been received for the next commitment
## Current Protocol
Currently we send the following:
- a `commitment_sig` message for the just negotiated splice tx
- resends all prior negotiated splice `commit_sigs` (if RBF) and the
non-splice commit-sig.
After receiving all the `commit_sig` messages, we do the 'normal' thing
where we then exchange a single `revoke_and_ack`.
Notably, the Current Protocol is identical for both new commitment signed
workflows and a new splice negotiation.
Which is to say, we re-use the same protocol for any new commitment
signatures that are required.
### Benefits to this Approach
- Single action to be taken after either a new commitment is negotiated or
a splice.
- Less complexity in implementation + less testing footprint
### Drawbracks to this Approach
- Redundant messages are sent (peer already has all prior commitment sigs
in the splice case)
- More signing required for successful splice
## Alternative Proposal
Instead of sending all of the commit-sigs and a revoke_and_ack, we'd send a
single `commitment_sig`.
### Benefits of this Approach
- Less data sent over the wire. Only new information is transmitted
- Less signatures need to be (re)-generated.
### Drawbacks to this Approach
- We need a way to communicate that the `commitment_sig` has been received.
(`tx_signatures` should fill this role.)
- It's a slightly different way of doing commitments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230330/e3b76db5/attachment-0001.html>

2023-06-09 13:08:35

- reply

📅 Original date posted:2023-04-24
📝 Original message:
Hi all,
When I joined the lightning community a few years ago, I was relatively new
to open source software and specification work. Rusty really impressed on
me on the importance of holding conversations, as much as possible in
public.
Practically speaking, this encompasses IRC, this mailing list, and github
issues/PRs.
The reason for this is twofold. It helps document the range of options
considered for technical decisions and it provides an interface point for
new participants to contribute to the discussion.
Given some recent mails that were posted to this list, now seems like a
good time to reiterate the importance and preference of public
communication whenever possible, especially for specification or technical
discussions.
~ nifty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230424/d37aa552/attachment-0001.html>

2023-06-09 13:08:33

- reply

📅 Original date posted:2023-04-24
📝 Original message:
Hi Michael,
CLN as implemented is currently nicely decoupled from the block source; as
a project we assume that the node runner will choose a block backend that
fits their self-sovereignty goals.
This provides us with a nice separation of concerns. The block source is
responsible for ensuring that only consensus valid data is delivered to the
node, which in turn allows us to focus on processing and reacting to that
data, as necessary.
Bitcoin core as a project implements a broad swath of functionality
(wallet, consensus, peering, rpc server, coin selection, key management,
etc); breaking out the validation and peering functions into more
composable parts would def open up more opportunities for building block
sources for a wide variety of projects, not just CLN.
There’s probably a real opportunity to “comingle” the peering of LN gossip
+ block data networks, this has been suggested a few times but never
seriously pursued from the LN side. Having the peering functions of
bitcoin-core broken out into a more composable/reusable piece may be a good
first step here, and as a project would largely be on the bitcoin core
side. Maybe this work is already in progress? I havent been keeping up with
developments there.
Thanks for the email, it’s definitely a good question.
Lisa
On Mon, Apr 24, 2023 at 02:09 Michael Folkson via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Any thoughts on this from the Core Lightning contributors? The way I see
> it with upcoming proposed changes to default policy (primarily though not
> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
> (primarily though not exclusively for Lightning) that a tighter coupling
> between the full node and the Lightning node could eventually make sense.
> In a world where transaction fees were much higher you'd think almost every
> full node would also want to be a Lightning node and so the separation of
> concerns would make less sense. Having two separate P2P networks and two
> separate P2P protocols also wouldn't make much sense in this scenario. You
> could obviously still opt out of Lightning P2P messages if you weren't
> interested in Lightning.
>
> The alternative would be just to focus on Knots style consensus compatible
> forks of Core with limited additional functionality. But I think we've
> reached the point of no return on Core dominance and not having widely used
> "distros". As the ecosystem scales systems and processes should be
> constantly evolving and improving and to me if anything Core's seem to be
> going backwards.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
>
> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <
> michaelfolkson at protonmail.com> wrote:
>
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in
> Core increasingly thinking @BitcoinKnots and consensus compatible forks of
> Core are the future. Gonna chalk that one up to another thing @LukeDashjr
> was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
> with Core Lightning was a long term idea I had (and presumably many others
> have had) but the dysfunction on the Bitcoin Core project this week (if
> anything it has been getting worse over time, not better) has made me start
> to take the idea more seriously. It is clear to me that the current way the
> Bitcoin Core project is being managed is not how I would like an open
> source project to be managed. Very little discussion is public anymore and
> decisions seem to be increasingly made behind closed doors or in private
> IRC channels (to the extent that decisions are made at all). Core Lightning
> seems to have the opposite problem. It is managed effectively in the open
> (admittedly with fewer contributors) but doesn't have the eyeballs or the
> usage that Bitcoin Core does. Regardless, selfishly I at some point would
> like a bare bones Bitcoin and Lightning implementation integrated in one
> codebase. The Bitcoin Core codebase has collected a lot of cruft over time
> and the ultra conservatism that is needed when treating (potential)
> consensus code seems to permeate into parts of the codebase that no one is
> using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus
> engine out of Core but it seems like it won't achieve that as consensus is
> just too slippery a concept and Knots style consensus compatible codebase
> forks of Bitcoin Core seem to still the model. To what extent you can
> safely chop off this cruft and effectively maintain this less crufty fork
> of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code
> that people have different views on. C++ is obviously a superset of C but
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal
> final destination it surely would have been better if Core Lightning was
> written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much
> more familiar with the entirety of the Bitcoin Core and Core Lightning
> codebases. It would be an ambitious long term project but it would be nice
> to focus on some ambitious project(s) (even if just conceptually) for a
> while given (thankfully) there seems to be a lull in soft fork activation
> chaos.
>
> Thanks
> Michael
>
> [0]:
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230424/911bc9d0/attachment-0001.html>

2023-06-09 13:08:24

- reply

📅 Original date posted:2023-03-30
📝 Original message:
This feels sort of dumb but I wrote it up and thought maybe others would
find it enlightening.
There's been a question of whether or not we should re-send all of the
commitment-sigs after a new splice has been negotiated. The current CLN
draft of splicing sends all of them, should we only send the one?
After writing this out, it seems fairly obvious to me that the correct way
forward is to only send a commitment sig for the newly negotiated splice;
all of the commitment sigs should be re-sent only when the underlying
commitment tx changes (eg. htlc added/removed).
Longer analysis below.
As an interesting 'historical aside', in the original splicing draft
proposal, all commitment sigs were sent in a single message; we've since
split them out into more messages, which now nicely allows for only sending
the new commitment_signed message when appropriate.
~nifty
h/t to @ddustin and @t-bast for surfacing this.
# Should we re-send commit_sigs + revoke_and_ack for newly negotiated
splices?
## Background
When a splice tx is successfully negotiated, we need to send a
commitment-sig to the peer to be able to send the new funding tx.
After `tx_complete`, we need to exchange the `commitment_sig` for the newly
created splice tx.
## Purpose of `commitment_signed`
The purpose of the `commitment_signed` message is to send the peer your
commitment sig for the currently proposed commitment.
## Purpose of `revoke_and_ack`
The purpose of `revoke_and_ack` is two-fold:
- Send a revocation point for the previous commitment transaction, REVOKING
the previous commitment
- ACK that the commitment sig has been received for the next commitment
## Current Protocol
Currently we send the following:
- a `commitment_sig` message for the just negotiated splice tx
- resends all prior negotiated splice `commit_sigs` (if RBF) and the
non-splice commit-sig.
After receiving all the `commit_sig` messages, we do the 'normal' thing
where we then exchange a single `revoke_and_ack`.
Notably, the Current Protocol is identical for both new commitment signed
workflows and a new splice negotiation.
Which is to say, we re-use the same protocol for any new commitment
signatures that are required.
### Benefits to this Approach
- Single action to be taken after either a new commitment is negotiated or
a splice.
- Less complexity in implementation + less testing footprint
### Drawbracks to this Approach
- Redundant messages are sent (peer already has all prior commitment sigs
in the splice case)
- More signing required for successful splice
## Alternative Proposal
Instead of sending all of the commit-sigs and a revoke_and_ack, we'd send a
single `commitment_sig`.
### Benefits of this Approach
- Less data sent over the wire. Only new information is transmitted
- Less signatures need to be (re)-generated.
### Drawbacks to this Approach
- We need a way to communicate that the `commitment_sig` has been received.
(`tx_signatures` should fill this role.)
- It's a slightly different way of doing commitments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230330/e3b76db5/attachment-0001.html>

2023-06-07 23:20:51

- reply

📅 Original date posted:2023-04-24
🗒️ Summary of this message: CLN is decoupled from the block source, allowing for self-sovereignty goals. Breaking out validation and peering functions could open opportunities for building block sources. There may be an opportunity to combine peering of LN gossip and block data networks. Tighter coupling between full node and Lightning node could eventually make sense. Core dominance and lack of widely used "distros" may hinder evolution and improvement.
📝 Original message:Hi Michael,
CLN as implemented is currently nicely decoupled from the block source; as
a project we assume that the node runner will choose a block backend that
fits their self-sovereignty goals.
This provides us with a nice separation of concerns. The block source is
responsible for ensuring that only consensus valid data is delivered to the
node, which in turn allows us to focus on processing and reacting to that
data, as necessary.
Bitcoin core as a project implements a broad swath of functionality
(wallet, consensus, peering, rpc server, coin selection, key management,
etc); breaking out the validation and peering functions into more
composable parts would def open up more opportunities for building block
sources for a wide variety of projects, not just CLN.
There’s probably a real opportunity to “comingle” the peering of LN gossip
+ block data networks, this has been suggested a few times but never
seriously pursued from the LN side. Having the peering functions of
bitcoin-core broken out into a more composable/reusable piece may be a good
first step here, and as a project would largely be on the bitcoin core
side. Maybe this work is already in progress? I havent been keeping up with
developments there.
Thanks for the email, it’s definitely a good question.
Lisa
On Mon, Apr 24, 2023 at 02:09 Michael Folkson via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Any thoughts on this from the Core Lightning contributors? The way I see
> it with upcoming proposed changes to default policy (primarily though not
> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
> (primarily though not exclusively for Lightning) that a tighter coupling
> between the full node and the Lightning node could eventually make sense.
> In a world where transaction fees were much higher you'd think almost every
> full node would also want to be a Lightning node and so the separation of
> concerns would make less sense. Having two separate P2P networks and two
> separate P2P protocols also wouldn't make much sense in this scenario. You
> could obviously still opt out of Lightning P2P messages if you weren't
> interested in Lightning.
>
> The alternative would be just to focus on Knots style consensus compatible
> forks of Core with limited additional functionality. But I think we've
> reached the point of no return on Core dominance and not having widely used
> "distros". As the ecosystem scales systems and processes should be
> constantly evolving and improving and to me if anything Core's seem to be
> going backwards.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
>
> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <
> michaelfolkson at protonmail.com> wrote:
>
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in
> Core increasingly thinking @BitcoinKnots and consensus compatible forks of
> Core are the future. Gonna chalk that one up to another thing @LukeDashjr
> was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
> with Core Lightning was a long term idea I had (and presumably many others
> have had) but the dysfunction on the Bitcoin Core project this week (if
> anything it has been getting worse over time, not better) has made me start
> to take the idea more seriously. It is clear to me that the current way the
> Bitcoin Core project is being managed is not how I would like an open
> source project to be managed. Very little discussion is public anymore and
> decisions seem to be increasingly made behind closed doors or in private
> IRC channels (to the extent that decisions are made at all). Core Lightning
> seems to have the opposite problem. It is managed effectively in the open
> (admittedly with fewer contributors) but doesn't have the eyeballs or the
> usage that Bitcoin Core does. Regardless, selfishly I at some point would
> like a bare bones Bitcoin and Lightning implementation integrated in one
> codebase. The Bitcoin Core codebase has collected a lot of cruft over time
> and the ultra conservatism that is needed when treating (potential)
> consensus code seems to permeate into parts of the codebase that no one is
> using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus
> engine out of Core but it seems like it won't achieve that as consensus is
> just too slippery a concept and Knots style consensus compatible codebase
> forks of Bitcoin Core seem to still the model. To what extent you can
> safely chop off this cruft and effectively maintain this less crufty fork
> of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code
> that people have different views on. C++ is obviously a superset of C but
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal
> final destination it surely would have been better if Core Lightning was
> written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much
> more familiar with the entirety of the Bitcoin Core and Core Lightning
> codebases. It would be an ambitious long term project but it would be nice
> to focus on some ambitious project(s) (even if just conceptually) for a
> while given (thankfully) there seems to be a lull in soft fork activation
> chaos.
>
> Thanks
> Michael
>
> [0]:
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230424/911bc9d0/attachment.html>