npub1e4…jxmcu

📅 Original date posted:2022-11-01
📝 Original message:
Right, I kinda assume let's figure that out when we get PTLCs? There's also the channel-upgrade work
that has been around for a while. Once we do that we can probably define a new type for PTLCs in
"normal" channels.
Adding two types adds a bunch of complexity right now, and it would be effectively dead code that
we're not likely to get right unless we have an immediate use/test for it. It is a good point,
though, and something implementors should likely keep in mind when writing code.
Matt
On 10/28/22 12:35 AM, Johan Torås Halseth wrote:
> Hi, Matt.
>
> You're correct, I made the suggestion mainly because it would open up for PTLCs (or other future
> features) in today's channels.
>
> Having the existing network close and reopen new channels would really slow the adoption of new
> channel features I reckon.
>
> And I don't think it adds much complexity compared to the adapter approach.
>
> - Johan
>
> On Thu, Oct 27, 2022 at 4:54 PM Matt Corallo <lf-lists at mattcorallo.com
> <mailto:lf-lists at mattcorallo.com>> wrote:
>
> I’m not sure I understand this - is there much reason to want taproot commitment outputs? I mean
> they’re cool, and witnesses are a bit smaller, which is nice I guess, but they’re not providing
> materially new features, AFAIU. Taproot funding, on the other hand, provides a Bitcoin-wide
> privacy improvement as well the potential future ability of channel participants to use multisig
> for their own channel funds transparently.
>
> Sure, if we’re doing taproot funding outputs we should probably just do it for the commitment
> outputs as well, because why not (and it’s a prereq for PTLCs). But trying to split them up
> seems like added complexity “just because”? I suppose it tees us up for eventual PTLC support in
> todays channels, but we can also consider that separately when we get to that point, IMO.
>
> Am I missing some important utility of taproot commitment transaction outputs?
>
> Matt
>
>> On Oct 27, 2022, at 02:17, Johan Torås Halseth <johanth at gmail.com <mailto:johanth at gmail.com>>
>> wrote:
>>
>>
>> Hi, Laolu.
>>
>> I think it could be worth considering dividing the taprootyness of a channel into two:
>> 1) taproot funding output
>> 2) taproot commitment outputs
>>
>> That way we could upgrade existing channels only on the commitment level, not needing to close
>> or re-anchor the channels using an adapter in order to get many of the taproot benefits.
>>
>> New channels would use taproot multisig (musig2) for the funding output.
>>
>> This seems to be less disruptive to the existing network, and we could get features enabled by
>> taproot to larger parts of the network quicker. And to me this seems to carry less complexity
>> (and closing fees) than an adapter.
>>
>> One caveat is that this wouldn't work (I think) for Eltoo channels, as the funding output
>> would not be plain multisig anymore.
>>
>> - Johan
>>
>> On Sat, Mar 26, 2022 at 1:27 AM Antoine Riard <antoine.riard at gmail.com
>> <mailto:antoine.riard at gmail.com>> wrote:
>>
>> Hi Laolu,
>>
>> Thanks for the proposal, quick feedback.
>>
>> > It *is* still the case that _ultimately_ the two transactions to close the
>> > old segwit v0 funding output, and re-open the channel with a new segwit v1
>> > funding output are unavoidable. However this adapter commitment lets peers
>> > _defer_ these two transactions until closing time.
>>
>> I think there is one downside coming with adapter commitment, which is the uncertainty of
>> the fee overhead at the closing time. Instead of closing your segwit v0 channel _now_ with
>> known fees, when your commitment is empty of time-sensitive HTLCs, you're taking the risk
>> of closing during fees spikes, due a move triggered by your counterparty, when you might
>> have HTLCs at stake.
>>
>> It might be more economically rational for a LN node operator to pay the upgrade cost now
>> if they wish to benefit from the taproot upgrade early, especially if long-term we expect
>> block fees to increase, or wait when there is a "normal" cooperative closing.
>>
>> So it's unclear to me what the economic gain of adapter commitments ?
>>
>> > In the remainder of this mail, I'll describe an alternative
>> > approach that would allow upgrading nearly all channel/commitment related
>> > values (dust limit, max in flight, etc), which is inspired by the way the
>> > Raft consensus protocol handles configuration/member changes.
>>
>> Long-term, I think we'll likely need a consensus protocol anyway for multi-party
>> constructions (channel factories/payment pools). AFAIU this proposal doesn't aim to roll
>> out a full-fledged consensus protocol *now* though it could be wise to ensure what we're
>> building slowly moves in this direction. Less critical code to maintain across bitcoin
>> codebases/toolchains.
>>
>> > The role of the signature it to prevent "spoofing" by one of the parties
>> > (authenticate the param change), and also it serves to convince a party that
>> > they actually sent a prior commitment propose update during the
>> > retransmission phase.
>>
>> What's the purpose of data origin authentication if we assume only two-parties running
>> over Noise_XK ?
>>
>> I think it's already a security property we have. Though if we think we're going to reuse
>> these dynamic upgrades for N counterparties communicating through a coordinator, yes I
>> think it's useful.
>>
>> > In the past, when ideas like this were brought up, some were concerned that
>> > it wouldn't really be possible to do this type of updates while existing
>> > HTLCs were in flight (hence some of the ideas to clear out the commitment
>> > beforehand).
>>
>> The dynamic upgrade might serve in an emergency context where we don't have the leisury to
>> wait for the settlement of the pending HTLCs. The timing of those ones might be beyond the
>> coordination of link counterparties. Thus, we have to allow upgrade of non-empty
>> commitments (and if there are undesirable interferences between new commitment types and
>> HTLCs/PTLCs present, deal case-by-case).
>>
>> Antoine
>>
>> Le jeu. 24 mars 2022 à 18:53, Olaoluwa Osuntokun <laolu32 at gmail.com
>> <mailto:laolu32 at gmail.com>> a écrit :
>>
>> Hi y'all,
>>
>> ## Dynamic Commitments Retrospective
>>
>> Two years-ish ago I made a mailing list post on some ideas re dynamic
>> commitments [1], and how the concept can be used to allow us to upgrade
>> channel types on the fly, and also remove pesky hard coded limits like the
>> 483 HTLC in-flight limit that's present today. Back then my main target was
>> upgrading all the existing channels over to the anchor output commitment
>> variant, so the core internal routing network would be more resilient in a
>> persistent high fee environment (which hasn't really happened over the past
>> 2 years for various reasons tbh). Fast forward to today, and with taproot
>> now active on mainnet, and some initial design work/sketches for
>> taproot-native channels underway, I figure it would be good to bump this
>> concept as it gives us a way to upgrade all 80k+ public channels to taproot
>> without any on chain transactions.
>>
>> ## Updating Across Witness Versions w/ Adapter Commitments
>>
>> In my original mail, I incorrectly concluded that the dynamic commitments
>> concept would only really work within the confines of a "static" multi-sig
>> output, meaning that it couldn't be used to help channels upgrade to future
>> segwit witness versions. Thankfully this reply [2] by ZmnSCPxj, outlined a
>> way to achieve this in practice. At a high level he proposes an "adaptor
>> commitment" (similar to the kickoff transaction in eltoo/duplex), which is
>> basically an upgrade transaction that spends one witness version type, and
>> produces an output with the next (upgraded) type. In the context of
>> converting from segwit v0 to v1 (taproot), two peers would collaboratively
>> create a new adapter commitment that spends the old v0 multi-sig output, and
>> produces a _new_ v1 multi-sig output. The new commitment transaction would
>> then be anchored using this new output.
>>
>> Here's a rough sequence diagram of the before and after state to better
>> convey the concept:
>>
>> * Before: fundingOutputV0 -> commitmentTransaction
>>
>> * After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
>> commitmentTransaction
>>
>> It *is* still the case that _ultimately_ the two transactions to close the
>> old segwit v0 funding output, and re-open the channel with a new segwit v1
>> funding output are unavoidable. However this adapter commitment lets peers
>> _defer_ these two transactions until closing time. When force closing two
>> transactions need to be confirmed before the commitment outputs can be
>> resolved. However, for co-op close, you can just spend the v0 output, and
>> deliver to the relevant P2TR outputs. The adapter commitment can leverage
>> sighash anyonecanpay to let both parties (assuming it's symmetric) attach
>> additional inputs for fees (to avoid introducing the old update_fee related
>> static fee issues), or alternatively inherit the anchor output pattern at
>> this level.
>>
>> ## Existing Dynamic Commitments Proposals
>>
>> Assuming this concept holds up, then we need an actual concrete protocol to
>> allow for dynamic commitment updates. Last year, Rusty made a spec PR
>> outlining a way to upgrade the commitment type (leveraging the new
>> commitment type feature bits) upon channel re-establish [3]. The proposal
>> relies on another message that both sides send (`stfu`) to clear the
>> commitment (similar to the shutdown semantics) before the switch over
>> happens. However as this is tied to the channel re-establish flow, it
>> doesn't allow both sides to do things like only allow your peer to attach N
>> HTLCs to start with, slowing increasing their allotted slots and possibly
>> reducing them (TCP AIMD style).
>>
>> ## A Two-Phase Dynamic Commitment Update Protocol
>>
>> IMO if we're adding in a way to do commitment/channel upgrades, then it may
>> be worthwhile to go with a more generalized, but slightly more involved
>> route instead. In the remainder of this mail, I'll describe an alternative
>> approach that would allow upgrading nearly all channel/commitment related
>> values (dust limit, max in flight, etc), which is inspired by the way the
>> Raft consensus protocol handles configuration/member changes.
>>
>> For those that aren't aware, Raft is a consensus protocol analogous to Paxos
>> (but isn't byzantine fault tolerant out of the box) that was designed as a
>> more understandable alternative to Paxos for a pedagogical environment.
>> Typically the algorithm is run in the context of a fixed cluster with N
>> machines, but supports adding/removing machines from the cluster with a
>> configuration update protocol. At a high level the way this works is that a
>> new config is sent to the leader, with the leader synchronizing the config
>> change with the other members of the cluster. Once a majority threshold is
>> reached, the leader then commits the config change with the acknowledged
>> parties using the new config (basically a two phase commit). I'm skipping
>> over some edge cases here that can arise if the new nodes participate
>> consensus too early, which can cause a split majority leading to two leaders
>> being elected.
>>
>> Applying this to the LN context is a bit simpler than a generalized
>> protocol, as we typically just have two parties involved. The initiator is
>> already naturally a "leader" in our context, as they're the only ones that
>> can do things like trigger fee updates.
>>
>> ### Message Structure
>>
>> At a high level I propose we introduce two new messages, with the fields
>> looking something like this for `commitment_update_propose`:
>> * type: 0 (`channel_id`)
>> * value: [`32*byte`:`chan_id`]
>> * type: 1 (`propose_sig`)
>> * value: [`64*byte`:`sig`]
>> * type: 2 (`update_payload`)
>> * value: [`*byte`:`tlv_payload`]
>>
>> and this `commitment_update_apply`:
>> * type: 0 (`channel_id`)
>> * value: [`32*byte`:`chan_id`]
>> * type: 1 (`local_propose`)
>> * value: [`*byte`:`commitment_update_propose`]
>> * type: 2 (`remote_propose`)
>> * value: [`*byte`:`commitment_update_propose`]
>>
>> ### Protocol Flow
>>
>> The core idea here is that either party can propose a commitment/channel
>> param update, but only the initiator can actually apply it. The
>> `commitment_update_propose` encodes the new set of updates, with a signature
>> covering the TLV blob for the new params (more on why that's needed later).
>> The `commitment_update_apply` includes up to _two_
>> `commitment_update_propose` messages (one for the initiator and one for the
>> responder, as nested TLV messages). The `commitment_update_propose` message
>> would be treated like any other `update_*` message, in that it takes a new
>> commitment signature to properly commit/apply it.
>>
>> The normal flow takes the form of both sides sending a
>> `commitment_update_propose` message, with the initiator finally committing
>> both by sending a `commitment_update_apply` message. In the event that only
>> the responder wants to apply a param change/update, then the initiator can
>> reply immediately with a `commitment_update_apply` message that doesn't
>> include a param change for their commitment (or they just echo the
>> parameters if they're acceptable).
>>
>> ### Handling Retransmissions
>>
>> The role of the signature it to prevent "spoofing" by one of the parties
>> (authenticate the param change), and also it serves to convince a party that
>> they actually sent a prior commitment propose update during the
>> retransmission phase. As the `commitment_update_propose` message would be
>> retransmitted like any other message, if the initiator attempts to commit
>> the update but the connection dies, they'll retransmit it as normal along
>> with their latest signature.
>>
>> ### Nested TLV Param Generality
>>
>> The messages as sketched out here just have an opaque nested TLV field which
>> makes it extensible to add in other things like tweaking the total number of
>> max HTLCs, the current dust values, min/max HTLCs, etc (all things that are
>> currently hard coded for the lifetime of the channel). An initial target
>> would likely just be a `chan_type` field, with future feature bits governing
>> _what_ type of commitment updates both parties understand in the future.
>>
>> In the past, when ideas like this were brought up, some were concerned that
>> it wouldn't really be possible to do this type of updates while existing
>> HTLCs were in flight (hence some of the ideas to clear out the commitment
>> beforehand). I don't see a reason why this fundamentally _shouldn't_ be
>> allowed, as from the point of view of the channel update state machine, all
>> updates (adds/removes) get applied as normal, but with this _new_ commitment
>> type/params. The main edge case we'll need to consider is cases where the
>> new params make older HTLCs invalid for some reason.
>>
>> ## Conclusion
>>
>> Using the adapter commitment idea combined with a protocol for updating
>> commitments on the fly, would potentially allow us to update all 80k+ segwit
>> v0 channels to the base level of taprooty channels without any on chain
>> transactions. The two transactions (open+close) must happen eventually, but
>> by holding another layer of spends off-chain we can defer them (potentially
>> indefinitely, as we have channels today that have been opened for over a
>> year).
>>
>> Deploying a generalised on-the-fly dynamic commitment update protocol gives
>> us a tool to future proof the _existing_ anchored multi-sig outputs in the
>> chain, and also a way to remove many of the hard coded parameters we have
>> today in the protocol. One overly inflexible parameter we have today in the
>> network is the 483 HTLC limit. Allowing this value to float would allow
>> peers to apply similar congestion avoidance algorithm that are used in TCP
>> today, and also give us a way to protect the network against future
>> unforeseen widespread policy changes (like a raising of the dust limit).
>>
>> -- Laolu
>>
>> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
>> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html>
>> [2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
>> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html>
>> [3]: https://github.com/lightning/bolts/pull/868
>> <https://github.com/lightning/bolts/pull/868>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev>
>
>
> On Thu, Oct 27, 2022 at 4:54 PM Matt Corallo <lf-lists at mattcorallo.com
> <mailto:lf-lists at mattcorallo.com>> wrote:
>
> I’m not sure I understand this - is there much reason to want taproot commitment outputs? I mean
> they’re cool, and witnesses are a bit smaller, which is nice I guess, but they’re not providing
> materially new features, AFAIU. Taproot funding, on the other hand, provides a Bitcoin-wide
> privacy improvement as well the potential future ability of channel participants to use multisig
> for their own channel funds transparently.
>
> Sure, if we’re doing taproot funding outputs we should probably just do it for the commitment
> outputs as well, because why not (and it’s a prereq for PTLCs). But trying to split them up
> seems like added complexity “just because”? I suppose it tees us up for eventual PTLC support in
> todays channels, but we can also consider that separately when we get to that point, IMO.
>
> Am I missing some important utility of taproot commitment transaction outputs?
>
> Matt
>
>> On Oct 27, 2022, at 02:17, Johan Torås Halseth <johanth at gmail.com <mailto:johanth at gmail.com>>
>> wrote:
>>
>>
>> Hi, Laolu.
>>
>> I think it could be worth considering dividing the taprootyness of a channel into two:
>> 1) taproot funding output
>> 2) taproot commitment outputs
>>
>> That way we could upgrade existing channels only on the commitment level, not needing to close
>> or re-anchor the channels using an adapter in order to get many of the taproot benefits.
>>
>> New channels would use taproot multisig (musig2) for the funding output.
>>
>> This seems to be less disruptive to the existing network, and we could get features enabled by
>> taproot to larger parts of the network quicker. And to me this seems to carry less complexity
>> (and closing fees) than an adapter.
>>
>> One caveat is that this wouldn't work (I think) for Eltoo channels, as the funding output
>> would not be plain multisig anymore.
>>
>> - Johan
>>
>> On Sat, Mar 26, 2022 at 1:27 AM Antoine Riard <antoine.riard at gmail.com
>> <mailto:antoine.riard at gmail.com>> wrote:
>>
>> Hi Laolu,
>>
>> Thanks for the proposal, quick feedback.
>>
>> > It *is* still the case that _ultimately_ the two transactions to close the
>> > old segwit v0 funding output, and re-open the channel with a new segwit v1
>> > funding output are unavoidable. However this adapter commitment lets peers
>> > _defer_ these two transactions until closing time.
>>
>> I think there is one downside coming with adapter commitment, which is the uncertainty of
>> the fee overhead at the closing time. Instead of closing your segwit v0 channel _now_ with
>> known fees, when your commitment is empty of time-sensitive HTLCs, you're taking the risk
>> of closing during fees spikes, due a move triggered by your counterparty, when you might
>> have HTLCs at stake.
>>
>> It might be more economically rational for a LN node operator to pay the upgrade cost now
>> if they wish to benefit from the taproot upgrade early, especially if long-term we expect
>> block fees to increase, or wait when there is a "normal" cooperative closing.
>>
>> So it's unclear to me what the economic gain of adapter commitments ?
>>
>> > In the remainder of this mail, I'll describe an alternative
>> > approach that would allow upgrading nearly all channel/commitment related
>> > values (dust limit, max in flight, etc), which is inspired by the way the
>> > Raft consensus protocol handles configuration/member changes.
>>
>> Long-term, I think we'll likely need a consensus protocol anyway for multi-party
>> constructions (channel factories/payment pools). AFAIU this proposal doesn't aim to roll
>> out a full-fledged consensus protocol *now* though it could be wise to ensure what we're
>> building slowly moves in this direction. Less critical code to maintain across bitcoin
>> codebases/toolchains.
>>
>> > The role of the signature it to prevent "spoofing" by one of the parties
>> > (authenticate the param change), and also it serves to convince a party that
>> > they actually sent a prior commitment propose update during the
>> > retransmission phase.
>>
>> What's the purpose of data origin authentication if we assume only two-parties running
>> over Noise_XK ?
>>
>> I think it's already a security property we have. Though if we think we're going to reuse
>> these dynamic upgrades for N counterparties communicating through a coordinator, yes I
>> think it's useful.
>>
>> > In the past, when ideas like this were brought up, some were concerned that
>> > it wouldn't really be possible to do this type of updates while existing
>> > HTLCs were in flight (hence some of the ideas to clear out the commitment
>> > beforehand).
>>
>> The dynamic upgrade might serve in an emergency context where we don't have the leisury to
>> wait for the settlement of the pending HTLCs. The timing of those ones might be beyond the
>> coordination of link counterparties. Thus, we have to allow upgrade of non-empty
>> commitments (and if there are undesirable interferences between new commitment types and
>> HTLCs/PTLCs present, deal case-by-case).
>>
>> Antoine
>>
>> Le jeu. 24 mars 2022 à 18:53, Olaoluwa Osuntokun <laolu32 at gmail.com
>> <mailto:laolu32 at gmail.com>> a écrit :
>>
>> Hi y'all,
>>
>> ## Dynamic Commitments Retrospective
>>
>> Two years-ish ago I made a mailing list post on some ideas re dynamic
>> commitments [1], and how the concept can be used to allow us to upgrade
>> channel types on the fly, and also remove pesky hard coded limits like the
>> 483 HTLC in-flight limit that's present today. Back then my main target was
>> upgrading all the existing channels over to the anchor output commitment
>> variant, so the core internal routing network would be more resilient in a
>> persistent high fee environment (which hasn't really happened over the past
>> 2 years for various reasons tbh). Fast forward to today, and with taproot
>> now active on mainnet, and some initial design work/sketches for
>> taproot-native channels underway, I figure it would be good to bump this
>> concept as it gives us a way to upgrade all 80k+ public channels to taproot
>> without any on chain transactions.
>>
>> ## Updating Across Witness Versions w/ Adapter Commitments
>>
>> In my original mail, I incorrectly concluded that the dynamic commitments
>> concept would only really work within the confines of a "static" multi-sig
>> output, meaning that it couldn't be used to help channels upgrade to future
>> segwit witness versions. Thankfully this reply [2] by ZmnSCPxj, outlined a
>> way to achieve this in practice. At a high level he proposes an "adaptor
>> commitment" (similar to the kickoff transaction in eltoo/duplex), which is
>> basically an upgrade transaction that spends one witness version type, and
>> produces an output with the next (upgraded) type. In the context of
>> converting from segwit v0 to v1 (taproot), two peers would collaboratively
>> create a new adapter commitment that spends the old v0 multi-sig output, and
>> produces a _new_ v1 multi-sig output. The new commitment transaction would
>> then be anchored using this new output.
>>
>> Here's a rough sequence diagram of the before and after state to better
>> convey the concept:
>>
>> * Before: fundingOutputV0 -> commitmentTransaction
>>
>> * After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
>> commitmentTransaction
>>
>> It *is* still the case that _ultimately_ the two transactions to close the
>> old segwit v0 funding output, and re-open the channel with a new segwit v1
>> funding output are unavoidable. However this adapter commitment lets peers
>> _defer_ these two transactions until closing time. When force closing two
>> transactions need to be confirmed before the commitment outputs can be
>> resolved. However, for co-op close, you can just spend the v0 output, and
>> deliver to the relevant P2TR outputs. The adapter commitment can leverage
>> sighash anyonecanpay to let both parties (assuming it's symmetric) attach
>> additional inputs for fees (to avoid introducing the old update_fee related
>> static fee issues), or alternatively inherit the anchor output pattern at
>> this level.
>>
>> ## Existing Dynamic Commitments Proposals
>>
>> Assuming this concept holds up, then we need an actual concrete protocol to
>> allow for dynamic commitment updates. Last year, Rusty made a spec PR
>> outlining a way to upgrade the commitment type (leveraging the new
>> commitment type feature bits) upon channel re-establish [3]. The proposal
>> relies on another message that both sides send (`stfu`) to clear the
>> commitment (similar to the shutdown semantics) before the switch over
>> happens. However as this is tied to the channel re-establish flow, it
>> doesn't allow both sides to do things like only allow your peer to attach N
>> HTLCs to start with, slowing increasing their allotted slots and possibly
>> reducing them (TCP AIMD style).
>>
>> ## A Two-Phase Dynamic Commitment Update Protocol
>>
>> IMO if we're adding in a way to do commitment/channel upgrades, then it may
>> be worthwhile to go with a more generalized, but slightly more involved
>> route instead. In the remainder of this mail, I'll describe an alternative
>> approach that would allow upgrading nearly all channel/commitment related
>> values (dust limit, max in flight, etc), which is inspired by the way the
>> Raft consensus protocol handles configuration/member changes.
>>
>> For those that aren't aware, Raft is a consensus protocol analogous to Paxos
>> (but isn't byzantine fault tolerant out of the box) that was designed as a
>> more understandable alternative to Paxos for a pedagogical environment.
>> Typically the algorithm is run in the context of a fixed cluster with N
>> machines, but supports adding/removing machines from the cluster with a
>> configuration update protocol. At a high level the way this works is that a
>> new config is sent to the leader, with the leader synchronizing the config
>> change with the other members of the cluster. Once a majority threshold is
>> reached, the leader then commits the config change with the acknowledged
>> parties using the new config (basically a two phase commit). I'm skipping
>> over some edge cases here that can arise if the new nodes participate
>> consensus too early, which can cause a split majority leading to two leaders
>> being elected.
>>
>> Applying this to the LN context is a bit simpler than a generalized
>> protocol, as we typically just have two parties involved. The initiator is
>> already naturally a "leader" in our context, as they're the only ones that
>> can do things like trigger fee updates.
>>
>> ### Message Structure
>>
>> At a high level I propose we introduce two new messages, with the fields
>> looking something like this for `commitment_update_propose`:
>> * type: 0 (`channel_id`)
>> * value: [`32*byte`:`chan_id`]
>> * type: 1 (`propose_sig`)
>> * value: [`64*byte`:`sig`]
>> * type: 2 (`update_payload`)
>> * value: [`*byte`:`tlv_payload`]
>>
>> and this `commitment_update_apply`:
>> * type: 0 (`channel_id`)
>> * value: [`32*byte`:`chan_id`]
>> * type: 1 (`local_propose`)
>> * value: [`*byte`:`commitment_update_propose`]
>> * type: 2 (`remote_propose`)
>> * value: [`*byte`:`commitment_update_propose`]
>>
>> ### Protocol Flow
>>
>> The core idea here is that either party can propose a commitment/channel
>> param update, but only the initiator can actually apply it. The
>> `commitment_update_propose` encodes the new set of updates, with a signature
>> covering the TLV blob for the new params (more on why that's needed later).
>> The `commitment_update_apply` includes up to _two_
>> `commitment_update_propose` messages (one for the initiator and one for the
>> responder, as nested TLV messages). The `commitment_update_propose` message
>> would be treated like any other `update_*` message, in that it takes a new
>> commitment signature to properly commit/apply it.
>>
>> The normal flow takes the form of both sides sending a
>> `commitment_update_propose` message, with the initiator finally committing
>> both by sending a `commitment_update_apply` message. In the event that only
>> the responder wants to apply a param change/update, then the initiator can
>> reply immediately with a `commitment_update_apply` message that doesn't
>> include a param change for their commitment (or they just echo the
>> parameters if they're acceptable).
>>
>> ### Handling Retransmissions
>>
>> The role of the signature it to prevent "spoofing" by one of the parties
>> (authenticate the param change), and also it serves to convince a party that
>> they actually sent a prior commitment propose update during the
>> retransmission phase. As the `commitment_update_propose` message would be
>> retransmitted like any other message, if the initiator attempts to commit
>> the update but the connection dies, they'll retransmit it as normal along
>> with their latest signature.
>>
>> ### Nested TLV Param Generality
>>
>> The messages as sketched out here just have an opaque nested TLV field which
>> makes it extensible to add in other things like tweaking the total number of
>> max HTLCs, the current dust values, min/max HTLCs, etc (all things that are
>> currently hard coded for the lifetime of the channel). An initial target
>> would likely just be a `chan_type` field, with future feature bits governing
>> _what_ type of commitment updates both parties understand in the future.
>>
>> In the past, when ideas like this were brought up, some were concerned that
>> it wouldn't really be possible to do this type of updates while existing
>> HTLCs were in flight (hence some of the ideas to clear out the commitment
>> beforehand). I don't see a reason why this fundamentally _shouldn't_ be
>> allowed, as from the point of view of the channel update state machine, all
>> updates (adds/removes) get applied as normal, but with this _new_ commitment
>> type/params. The main edge case we'll need to consider is cases where the
>> new params make older HTLCs invalid for some reason.
>>
>> ## Conclusion
>>
>> Using the adapter commitment idea combined with a protocol for updating
>> commitments on the fly, would potentially allow us to update all 80k+ segwit
>> v0 channels to the base level of taprooty channels without any on chain
>> transactions. The two transactions (open+close) must happen eventually, but
>> by holding another layer of spends off-chain we can defer them (potentially
>> indefinitely, as we have channels today that have been opened for over a
>> year).
>>
>> Deploying a generalised on-the-fly dynamic commitment update protocol gives
>> us a tool to future proof the _existing_ anchored multi-sig outputs in the
>> chain, and also a way to remove many of the hard coded parameters we have
>> today in the protocol. One overly inflexible parameter we have today in the
>> network is the 483 HTLC limit. Allowing this value to float would allow
>> peers to apply similar congestion avoidance algorithm that are used in TCP
>> today, and also give us a way to protect the network against future
>> unforeseen widespread policy changes (like a raising of the dust limit).
>>
>> -- Laolu
>>
>> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
>> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html>
>> [2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
>> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html>
>> [3]: https://github.com/lightning/bolts/pull/868
>> <https://github.com/lightning/bolts/pull/868>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev>
>

📅 Original date posted:2021-02-18
📝 Original message:This is absolutely the case, however note that the activation method itself is consensus code which executes as a part
of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should
be designed, this doesn't imply anything about the consensus code which represents the activation thereof.
Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one
which almost certainly carries significantly more risk than Taproot.
Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have
various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are
OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority
of Bitcoin users and is only not activating due to lagging miner upgrades.
Matt
On 2/18/21 10:04, Keagan McClelland wrote:
> Hi all,
>
> I think it's important for us to consider what is actually being considered for activation here.
>
> The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this
> is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with
> actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for
> that script version today. This is something I think that we can easily check by digging through the UTXO set or
> history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we
> can't switch to a script version that no one is actually using.
>
> If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs
> because there is simply no block that contains a transaction that only some of the network will accept.
>
> Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior"
> (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run.
> This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting
> fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to
> meet. I can't imagine a less intrusive change.
>
> On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate
> to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners
> are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable
> outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
>
> I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will
> all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it
> for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
>
> I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm
> missing something please say so. But from my point of view, we can't treat all soft forks as equal.
>
> Keagan
>
> On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
> should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
> much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
> use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
> exchange losing millions would be worse than having Taproot is good.
>
> Matt
>
> On 2/18/21 09:26, Michael Folkson wrote:
> > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
> forks,
> > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
> >
> > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
> such as
> > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
> splits
> > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
> > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
> >
> > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
> though I'm
> > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
> (though
> > admittedly you have a much better understanding than me of what happened in 2017).
> >
> > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
> > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
> > wouldn't kill Bitcoin long term.
> >
> > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>
> <mailto:lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>>> wrote:
> >
> > If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
> > and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
> and not
> > activate Taproot. Seriously.
> >
> > Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
> >
> > Matt
> >
> >> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> >>
> >>
> >> Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
> >> heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
> users
> >> should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
> >>
> >> My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
> >> implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
> >>
> >>
> >>
> >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com>
> <mailto:ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com>>> wrote:
> >>
> >> Good morning all,
> >>
> >> > "An activation mechanism is a consensus change like any other change, can be contentious like any other
> >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
> >> >
> >> > Who's we here?
> >> >
> >> > Release both and let the network decide.
> >>
> >> A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
> >> requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
> >>
> >> This assures everyone that neither choice is being forced on users, and instead what is being forced on
> users,
> >> is for users to make that choice themselves.
> >>
> >> Regards,
> >> ZmnSCPxj
> >>
> >> >
> >> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> >> >
> >> > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
> in the
> >> mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
> >> to conversation on the IRC channel or on social media etc.
> >> > >
> >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
> into
> >> code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
> >> must or must not run.
> >> > >
> >> > > I personally have never made this assumption. Of course users aren't forced to run any particular
> software
> >> version, quite the opposite. Defaults set in software versions matter though as many users won't change
> them.
> >> > >
> >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
> only a
> >> handful of people that begin running it while everyone else delays their upgrade (with the very good
> reason of
> >> not getting involved in politics) and a year later those handful of people just become stuck at the
> moment of
> >> MUST_SIGNAL, unable to mine new blocks?
> >> > >
> >> > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
> >> relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
> activate
> >> and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
> false in a
> >> software release there is the possibility (T2 in
> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
> >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a
> >> proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
> >> appears to be no more safe than LOT=true.
> >> > >
> >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
> miners
> >> by default.
> >> > >
> >> > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
> >> to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
> think it
> >> offers them clarity on what will happen over a year time period and removes the need for coordinated or
> >> uncoordinated community UASF efforts on top of LOT=false.
> >> > >
> >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
> >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
> >> > >
> >> > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
> >> occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
> >> LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
> >> isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
> >> worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
> >> support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
> >> trust in any human actors. We can be grateful that people like Alejandro have worked hard on
> >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com
> <http://taprootactivation.com>> (and this effort has informed the discussion) without
> >> taking pledges of support as cast iron guarantees.
> >> > >
> >> > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
> >> email :)
> >> > >
> >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces at gmail.com
> <mailto:arielluaces at gmail.com>
> >> <mailto:arielluaces at gmail.com <mailto:arielluaces at gmail.com>>> wrote:
> >> > >
> >> > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
> >> > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
> inevitable, like
> >> we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
> >> > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
> >> even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
> support,
> >> or any support right up against a miner activation threshold.
> >> > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
> >> in people's minds.
> >> > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
> >> above %51).
> >> > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
> since a
> >> UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
> >> coordination and safety are sometimes sprinkled into the argument.
> >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
> into
> >> code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
> >> must or must not run.
> >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
> only a
> >> handful of people that begin running it while everyone else delays their upgrade (with the very good
> reason of
> >> not getting involved in politics) and a year later those handful of people just become stuck at the
> moment of
> >> MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
> into a
> >> minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
> >> option has ran its course.
> >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
> miners
> >> by default. The chains could be called BitcoinLenient and BitcoinStubborn.
> >> > > > How is that strictly safer or more coordinated?
> >> > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
> >> this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
> with
> >> miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
> calling
> >> bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
> >> feature is worth a network split down the middle.
> >> > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
> >> become envious enough to put aside our differences on how to behave towards miners and finally activate
> Taproot.
> >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
> >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
> >> > > > Cheers
> >> > > > Ariel Lorenzo-Luaces
> >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> >> > > >
> >> > > > > Yesterday (February 16th) we held a second meeting on Taproot
> >> > > > > activation on IRC which again was open to all. Despite what appeared
> >> > > > > to be majority support for LOT=false over LOT=true in the first
> >> > > > > meeting I (and others) thought the arguments had not been explored in
> >> > > > > depth and that we should have a follow up meeting almost entirely
> >> > > > > focused on whether LOT (lockinontimeout) should be set to true or
> >> > > > > false.
> >> > > > >
> >> > > > > The meeting was announced here:
> >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
> >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>
> >> > > > >
> >> > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
> >> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
> >> > > > > could. David Harding responded with an additional argument for
> >> > > > > LOT=false (F7) here:
> >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
> >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>
> >> > > > >
> >> > > > > These meetings are very challenging given they are open to all, you
> >> > > > > don’t know who will attend and you don’t know most people’s views in
> >> > > > > advance. I tried to give time for both the LOT=true arguments and the
> >> > > > > LOT=false arguments to be discussed as I knew there was support for
> >> > > > > both. We only tried evaluating which had more support and which had
> >> > > > > more strong opposition towards the end of the meeting.
> >> > > > >
> >> > > > > The conversation log is here:
> >> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
> <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log
> <http://gnusha.org/taproot-activation/2021-02-16.log>>
> >> > > > >
> >> > > > > (If you are so inclined you can watch a video of the meeting here.
> >> > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
> >> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>
> <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>)
> >> > > > >
> >> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
> >> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
> <https://bitcoinhackers.org/@lukedashjr/105742918779234566>
> >> <https://bitcoinhackers.org/@lukedashjr/105742918779234566
> <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>
> >> > > > >
> >> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
> >> > > > > did manage to come to consensus on everything but LockinOnTimeout.
> >> > > > >
> >> > > > > Activation height range: 693504-745920
> >> > > > >
> >> > > > > MASF threshold: 1815/2016 blocks (90%)
> >> > > > >
> >> > > > > Keep in mind only ~100 people showed for the meetings, hardly
> >> > > > > representative of the entire community.
> >> > > > >
> >> > > > > So, these details remain JUST a proposal for now.
> >> > > > >
> >> > > > > It seems inevitable that there won't be consensus on LOT.
> >> > > > >
> >> > > > > Everyone will have to choose for himself. :/
> >> > > > >
> >> > > > > Personally I agree with most of this. I agree that there wasn’t
> >> > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
> >> > > > > my perspective there was clearly more strong opposition (what would
> >> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
> >> > > > > Bitcoin Core contributors, Lightning developers and other community
> >> > > > > members against LOT=true than there was for LOT=false. Andrew Chow
> >> > > > > tried to summarize views from the meeting in this analysis:
> >> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
> >> <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>
> >> > > > >
> >> > > > > I am also aware of other current and previous Bitcoin Core
> >> > > > > contributors and Lightning developers who didn’t attend the meeting in
> >> > > > > person who are opposed to LOT=true. I don’t want to put them in the
> >> > > > > spotlight for no reason but if you go through the conversation logs of
> >> > > > > not only the meeting but the weeks of discussion prior to this meeting
> >> > > > > you will see their views evaluated on the ##taproot-activation
> >> > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>
> <http://taprootactivation.com <http://taprootactivation.com>> some mining pools
> >> > > > > expressed a preference for lot=false though I don’t know how strong
> >> > > > > that preference was.
> >> > > > >
> >> > > > > I am only one voice but it is my current assessment that if we are to
> >> > > > > attempt to finalize Taproot activation parameters and propose them to
> >> > > > > the community at this time our only option is to propose LOT=false.
> >> > > > > Any further delay appears to me counterproductive in our collective
> >> > > > > aim to get the Taproot soft fork activated as early as possible.
> >> > > > >
> >> > > > > Obviously others are free to disagree with that assessment and
> >> > > > > continue discussions but personally I will be attempting to avoid
> >> > > > > those discussions unless prominent new information comes to light or
> >> > > > > various specific individuals change their minds.
> >> > > > >
> >> > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
> >> > > > > which was initially delayed because of this LOT discussion. As I’ve
> >> > > > > said previously that will be loosely following the format of the
> >> > > > > Bitcoin Core PR review club and will be lower level and more
> >> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
> >> > > > > the IRC channel ##taproot-activation.
> >> > > > >
> >> > > > > Thanks to the meeting participants (and those who joined the
> >> > > > > discussion on the channel prior and post the meeting) for engaging
> >> > > > > productively and in good faith.
> >> > >
> >> > > --
> >> > > Michael Folkson
> >> > > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> >> > > Keybase: michaelfolkson
> >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> > > _______________________________________________
> >> > > bitcoin-dev mailing list
> >> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> >> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
> >>
> >>
> >>
> >>
> >> --
> >> Michael Folkson
> >> Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> >> Keybase: michaelfolkson
> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
> >
> >
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> <mailto:michaelfolkson at gmail.com>>
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>