Ariel Luaces [ARCHIVE] / is on Nostr

Last Notes

2023-06-09 13:02:57

- reply

📅 Original date posted:2021-07-02
📝 Original message:
> bLIPs have a slightly different process than BIPs, as well as a different set
> of editors/maintainers (more widely distributed). As we saw with the Speedy
> Trial saga (fingers crossed), the sole (?) maintainer of the BIP process was
> able to effectively steelman the progression of an author document, with no
> sound technical objection (they had a competing proposal that could've been
> a distinct document). bLIPs sidestep shenanigans like this by having the
> primary maintainer/editors be more widely distributed and closer to the
> target domain (LN).
That's fair. The BIP repository as a whole lost credibility when the
sole maintainer at the time steelmanned progress for no good reason.
It was done in bad faith and no steps were taken to remove even the
*perception* of impropriety.
I hope the maintainers of the bLIP repository can be more impartial.
The automatic assignment of proposal numbers is an excellent
improvement. It's an idea that the BIP repo should adopt since it
removes responsibility and power from the maintainers.
>
> The other thing bLIPs do is do away with the whole "human picks the number
> of documents", and "don't assign your own number, you must wait". Borrowing
> from EIPs, the number of a document is simply the number of the PR that
> proposes the document. This reduces friction, and eliminates a possible
> bikeshedding vector.
>
> -- Laolu
>
>
> On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces <arielluaces at gmail.com> wrote:
>>
>> BIPs are already the Bazaar style of evolution that simultaneously
>> allows flexibility and coordination/interoperability (since anyone can
>> create a BIP and they create an environment of discussion).
>>
>> BOLTs are essentially one big BIP in the sense that they started as a
>> place for discussion but are now more rigid. BOLTs must be followed
>> strictly to ensure a node is interoperable with the network. And BOLTs
>> should be rigid, as rigid as any widely used BIP like 32 for example.
>> Even though BOLTs were flexible when being drafted their purpose has
>> changed from descriptive to prescriptive.
>> Any alternatives, or optional features should be extracted out of
>> BOLTs, written as BIPs. The BIP should then reference the BOLT and the
>> required flags set, messages sent, or alterations made to signal that
>> the BIP's feature is enabled.
>>
>> A BOLT may at some point organically change to reference a BIP. For
>> example if a BIP was drafted as an optional feature but then becomes
>> more widespread and then turns out to be crucial for the proper
>> operation of the network then a BOLT can be changed to just reference
>> the BIP as mandatory. There isn't anything wrong with this.
>>
>> All of the above would work exactly the same if there was a bLIP
>> repository instead. I don't see the value in having both bLIPs and
>> BIPs since AFAICT they seem to be functionally equivalent and BIPs are
>> not restricted to exclude lightning, and never have been.
>>
>> I believe the reason this move to BIPs hasn't happened organically is
>> because many still perceive the BOLTs available for editing, so
>> changes continue to be made. If instead BOLTs were perceived as more
>> "consensus critical", not subject to change, and more people were
>> strongly encouraged to write specs for new lightning features
>> elsewhere (like the BIP repo) then you would see this issue of growing
>> BOLTs resolved.
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>>
>> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>> >
>> > > That being said I think all the points that are addressed in Ryan's mail
>> > > could very well be formalized into BOLTs but maybe we just need to rethink
>> > > the current process of the BOLTs to make it more accessible for new ideas
>> > > to find their way into the BOLTs?
>> >
>> > I think part of what bLIPs are trying to solve here is promoting more loosely
>> > coupled evolution of the network. I think the BOLTs do a good job currently of
>> > specifying what _base_ functionality is required for a routing node in a
>> > prescriptive manner (you must forward an HTLC like this, etc). However there's
>> > a rather large gap in describing functionality that has emerged over time due
>> > to progressive evolution, and aren't absolutely necessary, but enhance
>> > node/wallet operation.
>> >
>> > Examples of include things like: path finding heuristics (BOLTs just say you
>> > should get from Alice to Bob, but provides no recommendations w.r.t _how_ to do
>> > so), fee bumping heuristics, breach retribution handling, channel management,
>> > rebalancing, custom records usage (like the podcast index meta-data, messaging,
>> > etc), JIT channel opening, hosted channels, randomized channel IDs, fee
>> > optimization, initial channel boostrapping, etc.
>> >
>> > All these examples are effectively optional as they aren't required for base
>> > node operation, but they've organically evolved over time as node
>> > implementations and wallet seek to solve UX and operational problems for
>> > their users. bLIPs can be a _descriptive_ (this is how things can be done)
>> > home for these types of standards, while BOLTs can be reserved for
>> > _prescriptive_ measures (an HTLC looks like this, etc).
>> >
>> > The protocol as implemented today has a number of extensions (TLVs, message
>> > types, feature bits, etc) that allow implementations to spin out their own
>> > sub-protocols, many of which won't be considered absolutely necessary for node
>> > operation. IMO we should embrace more of a "bazaar" style of evolution, and
>> > acknowledge that loosely coupled evolution allows participants to more broadly
>> > explore the design space, without the constraints of "it isn't a thing until N
>> > of us start to do it".
>> >
>> > Historically, BOLTs have also had a rather monolithic structure. We've used
>> > the same 11 or so documents for the past few years with the size of the
>> > documents swelling over time with new exceptions, features, requirements,
>> > etc. If you were hired to work on a new codebase and saw that everything is
>> > defined in 11 "functions" that have been growing linearly over time, you'd
>> > probably declare the codebase as being unmaintainable. By having distinct
>> > documents for proposals/standards, bLIPs (author documents really), each new
>> > standard/proposal is able to be more effectively explained, motivated, versionsed,
>> > etc.
>> >
>> > -- Laolu
>> >
>> >
>> > On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> Hey everyone,
>> >>
>> >> just for reference when I was new here (and did not understand the processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
>> >>
>> >> I wonder what exactly has changed in the reasoning by roasbeef which I will repeat here:
>> >>
>> >> > We already have the equiv of improvement proposals: BOLTs. Historically
>> >>
>> >> > new standardization documents are proposed initially as issues or PR's when
>> >>
>> >> > ultimately accepted. Why do we need another repo?
>> >>
>> >>
>> >> As far as I can tell there was always some form of (invisible?) barrier to participate in the BOLTs but there are also new BOLTs being offered:
>> >> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
>> >> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
>> >> and topics to be included like:
>> >> * dual funding
>> >> * splicing
>> >> * the examples given by Ryan
>> >>
>> >> I don't see how a new repo would reduce that barrier - Actually I think it would even create more confusion as I for example would not know where something belongs. That being said I think all the points that are addressed in Ryan's mail could very well be formalized into BOLTs but maybe we just need to rethink the current process of the BOLTs to make it more accessible for new ideas to find their way into the BOLTs? One thing that I can say from answering lightning-network questions on stackexchange is that it would certainly help if the BOLTs where referenced on lightning.network web page and in the whitepaper as the place to be if one wants to learn about the Lightning Network
>> >>
>> >> with kind regards Rene
>> >>
>> >> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>>
>> >>> The recent thread around zero-conf channels [1] provides an opportunity to discuss how the BOLT process handles features and best practices that arise in the wild vs. originating within the process itself. Zero-conf channels are one of many LN innovations on the app layer that have struggled to make their way into the spec. John Carvalho and Bitrefill launched Turbo channels in April 2019 [2], Breez posted their solution to the mailing list for feedback in August 2020 [3], and we know at least ACINQ and Muun (amongst others) have their own implementations. In an ideal world there would be a descriptive design document that the app layer implementers had collaborated on over the years that the spec group could then pick up and merge into the BOLTs now that the feature is deemed spec-worthy.
>> >>>
>> >>>
>> >>> Over the last couple of months, we have discussed the idea of adding a BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various members of the community, and have received positive feedback from both app layer and protocol devs. This would not affect the existing BOLT process at all, but simply add a place for app layer best practices to be succinctly described and organized, especially those that require coordination. These features are being built outside of the BOLT process today anyways, so ideally a bLIP process would bring them into the fold instead of leaving them buried in old ML posts or not documented at all.
>> >>>
>> >>>
>> >>> Some potential bLIP ideas that people have mentioned include: each lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment metadata, p2p messaging formats, new pathfinding heuristics, remote node connection standards, etc.
>> >>>
>> >>>
>> >>> If the community is interested in moving forward, we've started a branch [5] describing such a process. It's based on BIP-0002, so not trying to reinvent any wheels. It would be great to have developers from various implementations and from the broader app layer ecosystem volunteer to be listed as editors (basically the same role as in the BIPs).
>> >>>
>> >>>
>> >>> Looking forward to hearing your thoughts!
>> >>>
>> >>>
>> >>> Best,
>> >>> Ryan
>> >>>
>> >>>
>> >>> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>> >>>
>> >>> [2] https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>> >>>
>> >>> [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>> >>>
>> >>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>> >>>
>> >>> [5] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
>> >>>
>> >>> _______________________________________________
>> >>> Lightning-dev mailing list
>> >>> Lightning-dev at lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >>
>> >>
>> >>
>> >> --
>> >> https://www.rene-pickhardt.de
>> >> _______________________________________________
>> >> Lightning-dev mailing list
>> >> Lightning-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:02:51

- reply

📅 Original date posted:2021-06-30
📝 Original message:
BIPs are already the Bazaar style of evolution that simultaneously
allows flexibility and coordination/interoperability (since anyone can
create a BIP and they create an environment of discussion).
BOLTs are essentially one big BIP in the sense that they started as a
place for discussion but are now more rigid. BOLTs must be followed
strictly to ensure a node is interoperable with the network. And BOLTs
should be rigid, as rigid as any widely used BIP like 32 for example.
Even though BOLTs were flexible when being drafted their purpose has
changed from descriptive to prescriptive.
Any alternatives, or optional features should be extracted out of
BOLTs, written as BIPs. The BIP should then reference the BOLT and the
required flags set, messages sent, or alterations made to signal that
the BIP's feature is enabled.
A BOLT may at some point organically change to reference a BIP. For
example if a BIP was drafted as an optional feature but then becomes
more widespread and then turns out to be crucial for the proper
operation of the network then a BOLT can be changed to just reference
the BIP as mandatory. There isn't anything wrong with this.
All of the above would work exactly the same if there was a bLIP
repository instead. I don't see the value in having both bLIPs and
BIPs since AFAICT they seem to be functionally equivalent and BIPs are
not restricted to exclude lightning, and never have been.
I believe the reason this move to BIPs hasn't happened organically is
because many still perceive the BOLTs available for editing, so
changes continue to be made. If instead BOLTs were perceived as more
"consensus critical", not subject to change, and more people were
strongly encouraged to write specs for new lightning features
elsewhere (like the BIP repo) then you would see this issue of growing
BOLTs resolved.
Cheers
Ariel Lorenzo-Luaces
On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> > That being said I think all the points that are addressed in Ryan's mail
> > could very well be formalized into BOLTs but maybe we just need to rethink
> > the current process of the BOLTs to make it more accessible for new ideas
> > to find their way into the BOLTs?
>
> I think part of what bLIPs are trying to solve here is promoting more loosely
> coupled evolution of the network. I think the BOLTs do a good job currently of
> specifying what _base_ functionality is required for a routing node in a
> prescriptive manner (you must forward an HTLC like this, etc). However there's
> a rather large gap in describing functionality that has emerged over time due
> to progressive evolution, and aren't absolutely necessary, but enhance
> node/wallet operation.
>
> Examples of include things like: path finding heuristics (BOLTs just say you
> should get from Alice to Bob, but provides no recommendations w.r.t _how_ to do
> so), fee bumping heuristics, breach retribution handling, channel management,
> rebalancing, custom records usage (like the podcast index meta-data, messaging,
> etc), JIT channel opening, hosted channels, randomized channel IDs, fee
> optimization, initial channel boostrapping, etc.
>
> All these examples are effectively optional as they aren't required for base
> node operation, but they've organically evolved over time as node
> implementations and wallet seek to solve UX and operational problems for
> their users. bLIPs can be a _descriptive_ (this is how things can be done)
> home for these types of standards, while BOLTs can be reserved for
> _prescriptive_ measures (an HTLC looks like this, etc).
>
> The protocol as implemented today has a number of extensions (TLVs, message
> types, feature bits, etc) that allow implementations to spin out their own
> sub-protocols, many of which won't be considered absolutely necessary for node
> operation. IMO we should embrace more of a "bazaar" style of evolution, and
> acknowledge that loosely coupled evolution allows participants to more broadly
> explore the design space, without the constraints of "it isn't a thing until N
> of us start to do it".
>
> Historically, BOLTs have also had a rather monolithic structure. We've used
> the same 11 or so documents for the past few years with the size of the
> documents swelling over time with new exceptions, features, requirements,
> etc. If you were hired to work on a new codebase and saw that everything is
> defined in 11 "functions" that have been growing linearly over time, you'd
> probably declare the codebase as being unmaintainable. By having distinct
> documents for proposals/standards, bLIPs (author documents really), each new
> standard/proposal is able to be more effectively explained, motivated, versionsed,
> etc.
>
> -- Laolu
>
>
> On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> Hey everyone,
>>
>> just for reference when I was new here (and did not understand the processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
>>
>> I wonder what exactly has changed in the reasoning by roasbeef which I will repeat here:
>>
>> > We already have the equiv of improvement proposals: BOLTs. Historically
>>
>> > new standardization documents are proposed initially as issues or PR's when
>>
>> > ultimately accepted. Why do we need another repo?
>>
>>
>> As far as I can tell there was always some form of (invisible?) barrier to participate in the BOLTs but there are also new BOLTs being offered:
>> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
>> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
>> and topics to be included like:
>> * dual funding
>> * splicing
>> * the examples given by Ryan
>>
>> I don't see how a new repo would reduce that barrier - Actually I think it would even create more confusion as I for example would not know where something belongs. That being said I think all the points that are addressed in Ryan's mail could very well be formalized into BOLTs but maybe we just need to rethink the current process of the BOLTs to make it more accessible for new ideas to find their way into the BOLTs? One thing that I can say from answering lightning-network questions on stackexchange is that it would certainly help if the BOLTs where referenced on lightning.network web page and in the whitepaper as the place to be if one wants to learn about the Lightning Network
>>
>> with kind regards Rene
>>
>> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Hi all,
>>>
>>>
>>> The recent thread around zero-conf channels [1] provides an opportunity to discuss how the BOLT process handles features and best practices that arise in the wild vs. originating within the process itself. Zero-conf channels are one of many LN innovations on the app layer that have struggled to make their way into the spec. John Carvalho and Bitrefill launched Turbo channels in April 2019 [2], Breez posted their solution to the mailing list for feedback in August 2020 [3], and we know at least ACINQ and Muun (amongst others) have their own implementations. In an ideal world there would be a descriptive design document that the app layer implementers had collaborated on over the years that the spec group could then pick up and merge into the BOLTs now that the feature is deemed spec-worthy.
>>>
>>>
>>> Over the last couple of months, we have discussed the idea of adding a BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various members of the community, and have received positive feedback from both app layer and protocol devs. This would not affect the existing BOLT process at all, but simply add a place for app layer best practices to be succinctly described and organized, especially those that require coordination. These features are being built outside of the BOLT process today anyways, so ideally a bLIP process would bring them into the fold instead of leaving them buried in old ML posts or not documented at all.
>>>
>>>
>>> Some potential bLIP ideas that people have mentioned include: each lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment metadata, p2p messaging formats, new pathfinding heuristics, remote node connection standards, etc.
>>>
>>>
>>> If the community is interested in moving forward, we've started a branch [5] describing such a process. It's based on BIP-0002, so not trying to reinvent any wheels. It would be great to have developers from various implementations and from the broader app layer ecosystem volunteer to be listed as editors (basically the same role as in the BIPs).
>>>
>>>
>>> Looking forward to hearing your thoughts!
>>>
>>>
>>> Best,
>>> Ryan
>>>
>>>
>>> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>>>
>>> [2] https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>>>
>>> [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>>>
>>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>>>
>>> [5] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>
>> --
>> https://www.rene-pickhardt.de
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:54:40

- reply

📅 Original date posted:2019-03-30
📝 Original message:
> I am forking this thread as my reply is not at all related to the JIT-Routing.
Sorry I think my last reply was also getting off subject as well.
Thank you for forking the thread
> Nonexistent channels (i.e. channels that do not have some backing UTXO in the Bitcoin blockchain) are not safe to propagate on the network since they are trivially spammable (i.e. can generate a large number of fake channels to waste network bandwidth).
I hadn't considered the effect this gossip would have on the network.
Definitely nodes should not trust one another to tell the truth about
nonexistent channels.
The source node could blindly allow intermediate nodes to create
sub-routes to the next hop.
But I wouldn't favor this blind routing idea because fee calculations
would be a complete guess.
> A good pruning heuristic is "channel capacity", which can be checked onchain (the value of the UTXO backing the channel is the channel capacity).
> It is good to keep channels with large capacity in the routemap, because such large channels are more likely to successfully route a payment than smaller channels.
> So it is reasonable to delete channels with low capacity when the routemap memory is becoming close to full.
I'm generally concerned about these heuristics because any time nodes
can game a heuristic they will be expected to do so.
Gaming a heuristic can be good or bad depending on the side-effects.
One side effect of the "channel capacity" heuristic is more reliable
payments but another side effect is that low capacity (but possibly
reliable) channels are neglected
> It seems to me that s/aggregate-channel/high-capacity-channel/g in your idea would still work.
> In effect, the high-capacity channel is very likely to successfully route in either direction.
> But if by chance it falls into a state where it is unable to route in one direction or other, the intermediate node has other, lower-capacity channels that it can use JIT-Routing with to improve the directionality of the high-capacity channel.
> Nothing in the JIT-Routing idea requires that the rebalancing loop is small, only that a loop exists.
>
> Nodes still need to track their direct channels (so they are implicitly always in the routemap).
> But payee nodes making BOLT1 invoices could also provide `r` routes in the invoice, with the given routes being from nodes with high-capacity channels, so that even if the intermediate channels are pruned due to low capacity, it is possible to get paid.
Without low capacity channels spontaneous payments would not work. Or
they would depend on asking for an invoice under the hood.
It feels to me that at some point, someone with complete knowledge of
the network needs to eb employed.
Cheers
Ariel Lorenzo-Luaces

2023-06-09 12:54:40

- reply

📅 Original date posted:2019-03-29
📝 Original message:
> I am forking this thread as my reply is not at all related to the JIT-Routing.
Sorry I think my last reply was also getting off subject as well.
Thank you for forking the thread
> Nonexistent channels (i.e. channels that do not have some backing UTXO in the Bitcoin blockchain) are not safe to propagate on the network since they are trivially spammable (i.e. can generate a large number of fake channels to waste network bandwidth).
I hadn't considered the effect this gossip would have on the network.
Definitely nodes should not trust one another to tell the truth about
nonexistent channels.
The source node could blindly allow intermediate nodes to create
sub-routes to the next hop.
But I wouldn't favor this blind routing idea because fee calculations
would be a complete guesses.
> A good pruning heuristic is "channel capacity", which can be checked onchain (the value of the UTXO backing the channel is the channel capacity).
> It is good to keep channels with large capacity in the routemap, because such large channels are more likely to successfully route a payment than smaller channels.
> So it is reasonable to delete channels with low capacity when the routemap memory is becoming close to full.
I'm generally concerned about these heuristics because any time nodes
can game a heuristic they will be expected to do so.
Gaming a heuristic can be good or bad depending on the side-effects.
One side effect of the "channel capacity" heuristic is more reliable
payments but another side effect is that low capacity (but possibly
reliable) channels are neglected.
> It seems to me that s/aggregate-channel/high-capacity-channel/g in your idea would still work.
> In effect, the high-capacity channel is very likely to successfully route in either direction.
> But if by chance it falls into a state where it is unable to route in one direction or other, the intermediate node has other, lower-capacity channels that it can use JIT-Routing with to improve the directionality of the high-capacity channel.
> Nothing in the JIT-Routing idea requires that the rebalancing loop is small, only that a loop exists.
>
> Nodes still need to track their direct channels (so they are implicitly always in the routemap).
> But payee nodes making BOLT1 invoices could also provide `r` routes in the invoice, with the given routes being from nodes with high-capacity channels, so that even if the intermediate channels are pruned due to low capacity, it is possible to get paid.
Without low capacity channels spontaneous payments would not work. Or
they would depend on asking for an invoice under the hood.
It feels to me that at some point, someone with complete knowledge of
the network needs to be employed.
Cheers
Ariel Lorenzo-Luaces

2023-06-09 12:40:31

- reply

2023-06-09 12:40:25

- reply

2023-06-07 18:30:35

- reply

📅 Original date posted:2021-03-06
📝 Original message:On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm really unsure that three months is a short enough time window that there wouldn't be a material effort to split the
> network with divergent consensus rules. Instead, a three month window is certainly long enough to organize and make a
> lot of noise around such an effort, given BIP 148 was organized and reached its peak within a similar such window.
>
> Worse, because the obvious alternative after a three month activation failure is a significant delay prior to
> activation, the vocal UASF minority may be encouraged to pursue such a route to avoid such a delay.
>
I agree with your concern, a three month window motivates a small
group to constantly tell people to upgrade as soon as possible. Which
is mostly fine, but if this group gets near 51% mining support in the
three months it will embolden them to switch the messaging from
"upgrade the client" to "run this new client that has the LOT flag
switched to true" (UASF)
This marketing group will attempt a UASF regardless of the timelines
because there is no cost if they fail a UASF and there is great reward
if they succeed by activating in 3 months. They can run an alt-node,
scare everyone else of being reorged, pretend they have a majority,
and say their chain is the safe one. I say there is no cost because
the leaders of that movement are likely savvy enough to give up the
effort and move back to running core even after the chain split. The
ones who get hurt are the followers of the UASF movement that don't
fully understand the discussion and drink the kool aid.
A short time window doesn't preclude this group from attempting a UASF.
> One alternative may be to reduce the signaling windows involved and start slightly later. Instead of the likelihood of
> failure growing on the horizon, simply have two signaling windows (maybe two weeks, maybe a moth each?). In order to
> ensure success remains likely, begin them somewhat later after software release to give pools and miners a chance to
> configure their mining software in advance.
>
> Matt
The shorter the signaling windows the more unlikely they are to reach
a mining power supermajority.
With a short signaling window the supermajority threshold will
probably be configured to low levels (80% 70% 60%). Which makes the
activation period dangerous because it forces the other miners (20%
30% 40%) to upgrade really suddenly once the threshold is reached.
Unless the LOCKED_IN period is made really long (1 year) but then we
have to wait a really long time.
As long as the mining power running the soft fork is above 50% the
chain will stay together. Anything above that is just a safety margin
to prevent orphan blocks.
So why not encode this 50%+ dynamic into the activation logic.
Spread the deployment window out to a year, make the activation
threshold 95%, and at the end of the window the feature can activate
if there is above 51% signaling.
By definition, the activation will happen if either 95% is reached
early or if at the end of the deployment window mining support is
between 51% and 95%. With this setup the chain is guaranteed to stay
together and no need to rush miners and users.
Cheers
Ariel Lorenzo-Luaces
>
> On 3/5/21 22:43, David A. Harding via bitcoin-dev wrote:
> > On the ##taproot-activation IRC channel, Russell O'Connor recently
> > proposed a modification of the "Let's see what happens" activation
> > proposal.[1] The idea received significant discussion and seemed
> > acceptable to several people who could not previously agree on a
> > proposal (although this doesn't necessarily make it their first
> > choice). The following is my attempt at a description.
> >
> > 1. Start soon: shortly after the release of software containing this
> > proposed activation logic, nodes will begin counting blocks towards
> > the 90% threshold required to lock in taproot.[2]
> >
> > 2. Stop soon: if the lockin threshold isn't reached within approximately
> > three months, the activation attempt fails. There is no mandatory
> > activation and everyone is encouraged to try again using different
> > activation parameters.
> >
> > 2. Delayed activation: in the happy occasion where the lockin threshold
> > is reached, taproot is guaranteed to eventually activate---but not
> > until approximately six months after signal tracking started.
> >
> > ## Example timeline
> >
> > (All dates approximate; see the section below about BIP9 vs BIP8.)
> >
> > - T+0: release of one or more full nodes with activation code
> > - T+14: signal tracking begins
> > - T+28: earliest possible lock in
> > - T+104: locked in by this date or need to try a different activation process
> > - T+194: activation (if lockin occurred)
> >
> > ## Analysis
> >
> > The goal of Speedy Trial is to allow a taproot activation attempt to
> > either quickly succeed or quickly fail---without compromising safety in
> > either case. Details below:
> >
> > ### Mitigating the problems of early success
> >
> > New rules added in a soft fork need to be enforced by a large part of
> > the economy or there's a risk that a long chain of blocks breaking the
> > rules will be accepted by some users and rejected by others, causing a
> > chain split that can result in large direct losses to transaction
> > receivers and potentially even larger indirect losses to holders due to
> > reduced confidence in the safety of the Bitcoin system.
> >
> > One step developers have taken in the past to ensure widespread adoption
> > of new consensus rules is programming in a delay between the time software
> > with those rules is expected to be released and when the software starts
> > tracking which blocks signal for activation. For example:
> >
> > Soft fork | Release | Start | Delta
> > -----------------+------------+------------+----------
> > BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
> > BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
> >
> > Sources: BitcoinCore.org, https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
> >
> > Speedy Trial replaces most of that upfront delay with a backend delay.
> > No matter how fast taproot's activation threshold is reached by miners,
> > there will be six months between the time signal tracking starts and when
> > nodes will begin enforcing taproot's rules. This gives the userbase even
> > more time to upgrade than if we had used the most recently proposed start
> > date for a BIP8 activation (~July 23rd).[2]
> >
> > ### Succeed, or fail fast
> >
> > The earlier version of this proposal was documented over 200 days ago[3]
> > and taproot's underlying code was merged into Bitcoin Core over 140 days
> > ago.[4] If we had started Speedy Trial at the time taproot
> > was merged (which is a bit unrealistic), we would've either be less than
> > two months away from having taproot or we would have moved on to the
> > next activation attempt over a month ago.
> >
> > Instead, we've debated at length and don't appear to be any closer to
> > what I think is a widely acceptable solution than when the mailing list
> > began discussing post-segwit activation schemes over a year ago.[5] I
> > think Speedy Trial is a way to generate fast progress that will either
> > end the debate (for now, if activation is successful) or give us some
> > actual data upon which to base future taproot activation proposals.
> >
> > Of course, for those who enjoy the debate, discussion can continue while
> > waiting for the results of Speedy Trial.
> >
> > ### Base activation protocol
> >
> > The idea can be implemented on top of either Bitcoin Core's existing
> > BIP9 code or its proposed BIP8 patchset.[6]
> >
> > - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
> > these values plus a time-based parameter for the minimum activation
> > delay would give three months for miners to activate taproot, but some
> > of that time near the start or the end might not be usable due to
> > signals only being measured in full retarget periods. However, the
> > six month time for users to upgrade their node would be not be
> > affected by either slow or fast block production.
> >
> > BIP9 is already part of Bitcoin Core and I think the changes being
> > proposed would be relatively small, resulting in a small patch that
> > could be easy to review.
> >
> > - BIP8 uses two height-based parameters, startheight and timeoutheight.
> > Using height values would ensure miners had a certain number of
> > retarget periods (6) to lock in taproot and that there'd be a certain
> > number of blocks (about 24,000) until activation, although latest lock
> > in and expected activation could occur moderately earlier or later
> > than the estimated three and six months.
> >
> > BIP8 would likely be used if Speedy Trial fails, so it could be
> > advantageous to base this proposal on BIP8 so that we gain
> > experience running that code in production.
> >
> > For additional discussion about using times versus heights, see today's
> > log for ##taproot-activation.[11]
> >
> > ### Additional concerns
> >
> > - Encourages false signaling: false signaling is when miners signal
> > readiness to enforce rules that their nodes don't actually support.
> > This was partially responsible for a six-block reorg shortly after the
> > final BIP66 activation[8] and was found to still be a problem during
> > the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
> >
> > Because Speedy Trial only gives miners a maximum of three months to
> > signal support for taproot, it may encourage such false signaling. If
> > taproot locks in as a result of their signaling but most of them fail
> > to upgrade by the activation date several months later, unprepared
> > miners could lose large amounts of money and users could see long
> > reorgs (with unupgraded nodes and SPV lite clients potentially losing
> > money).
> >
> > Compared to other activation proposals, I think the only difference is
> > Speedy Trial's short timeline. False signaling is possible with any
> > other proposal and the same problems can occur if miners fail to
> > upgrade for any mandatory activation.
> >
> > ### Additional advantages
> >
> > - No mandatory signaling: at no time are miners required to signal by
> > Speedy Trial. This includes no mandatory signaling during the
> > locked_in period(s), although such signaling will be encouraged (as it
> > was with BIP9[10]).
> >
> > - Party time: to a lesser degree, a benefit mentioned for flag day
> > activation may also apply here: we could get up to six months
> > advanced notice of taproot activation, allowing users, developers, and
> > organizations to prepare software, announcements, and celebrations for
> > that event.
> >
> > ## Implementation details and next steps
> >
> > Initial discussion about implementation may be found in today's
> > ##taproot-activation log.[11] If it appears Speedy Trial may have
> > traction, Russell O'Connor has offered to work on a patch against BIP8
> > implementing it.
> >
> > ## Acknowledgments
> >
> > The original idea for a short-duration attempt was discussed in the
> > ##taproot-activation IRC channel last July and the revised idea saw
> > additional evaluation there this week. Despite growing frustration,
> > discussion has been overwhelmingly constructive, for which all the
> > contributors should be commended. Although this should not in any way
> > imply endorsement, I'm grateful for the review and comments on a draft
> > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> > Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> > O'Connor, and IRC users maybehuman and proofofkeags
> >
> > ## Footnotes
> >
> > [1] https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
> >
> > [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
> > seemed to have near-universal support during the 2021-02-16 IRC
> > meeting. See: https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> >
> > [3] https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
> >
> > [4] https://github.com/bitcoin/bitcoin/pull/19953
> >
> > [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
> >
> > [6] https://github.com/bitcoin/bitcoin/pull/19573
> >
> > [7] BIP9's times are based on the median of the past 11 blocks, which
> > usually trails UTC by about 90 minutes but which can trail behind
> > realtime significantly if miners are doing weird things.
> >
> > [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
> >
> > [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
> >
> > [10] https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
> >
> > [11] http://gnusha.org/taproot-activation/2021-03-05.log
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:30:28

- reply

📅 Original date posted:2021-03-05
📝 Original message:I found a hint of common ground in reddit that I absolutely loves and
just had to share here on the ML to discuss
Luke's suggestion: To minimise the signal from 90% to 50%+1 during the
MUST_SIGNAL phase.
https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkbdcg/
I think this proposal is a natural evolution:
>From the creation of BIP9 to enable soft fork activations with low
risk under widespread miner support
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
To miner aggression against segwit, resulting in shaolinfry's
releasing the BIP148 and BIP91 proposals and a UASF client, resulting
in the Bitcoin civil war, resulting in settlement through economic
pressure.
To shaolinfry's creation of BIP8 to force a soft fork when
encountering minority miner apathy/malice and a desire for the majoity
of users to deploy
https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki
To Greg Maxwell's suggestion of two round activation with BIP9
followed by a flag-day activation (couldn't find the link, it's
mention in Matt's Modern Soft Fork Activation proposal)
To Matt Corallo's suggestion to do a BIP9 deployment followed by a
BIP8 deployment with a six month waiting period in between (Modern
Soft Fork Activation)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
To Luke Dashjr's addition of lockinontimeout to BIP8 to consolidate
the functionality of BIP8 and BIP9
https://github.com/bitcoin/bips/pull/550
To AJ Towns' suggestion of a gradually decreasing activation threshold
and a user configurable option between conditional activation and
guaranteed activation at the end
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018043.html
To Gregorio Guidi's suggestion of decreasing the threshold to 1.2% as
the locked in date approaches, allowing for activation failure and
removing of the LOT flag
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018476.html
To Ariel Lorenzo-Luaces' (me) suggestion of switching the final
threshold to 50% to pose a reorg threat to non-upgraded miners instead
of risking a minority fork
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018529.html
To Luke Dashjr's suggestion of switching thresholds to 51% during the
MUST_SIGNAL phase instead of a gradualy decreasing threshold
https://old.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkejqt/
(I hope I'm not missing anything)
To Matt Corallo seemingly liking the idea? It's hard to tell.
I think Luke's proposal fixes a lot of concerns on both sides of the
LOT discussion.
I went through all the Taproot activation discussion I could find, as
well as some old segwit activation discussions, and here I summarize
points that will hopefully convince all supporters from all sides of
the Taproot activation discussion.
Some points are repeated but framed differently based on the reader's
predisposition (LOT=true or LOT=false or flag day).
Something to note is that this is not a compromise, I mention it at the bottom.
The case for this new proposal for supporters of LOT=true first:
1. no veto bug) Miners wouldn't have veto power. If 51% of miners are
signaling during MUST_SIGNAL phase Taproot activates. This proposal
follows the will of the community. (point 5 on Matt's Modern Soft Fork
Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
2. signaling used for coordination instead of voting) The requirement
for a 95% supermajority vote disappears since those, what would have
previously been seen as, votes are irrelevant during the MUST_SIGNAL
phase. The 51% threshold is also seen as a coordination mechanism for
users to gauge miner support to automatically split from an unupgraded
miner minority.
4. low threshold UASF) It's much much easier to do a UASF marketing
blitz since only 51% of mining power needs to enforce the new rules
and the supermajority is not required. Mining power (51% of it needed)
will probably be convinced if exchanges, wallet software, and a
moderate number of users are on the Taproot activation side
(significant economic activity). This was a major problem in 2017
because it was uncertain whether signaling miners were running BIP9 or
UASF.
5. no UASF minority chain) If LOT=true is released and it never
achieves 50% signaling then there would be a fork and the UASF chain
will be exposed to attacks or destabilization due to miners switching
between chains. This proposal avoids that situation because it
guarantees that a majority of mining power is supporting Taproot so
the chain can't be attacked. You never really wanted to fork off from
your friends right?
3. nodes stay in consensus) If Taproot does not achieve a
supermajority but does achieve a simple majority (>51% PoW) at the end
of activation then upgraded users, upgraded miners, and non-upgraded
will all follow the taproot-active ruleset, leaving a minority of
miners to be exposed to reorgs if they don't enforce the new Taproot
rules. At this point the economic majority will very clearly be in the
taproot-activated chain so this creates strong pressure for the
minority of miners to capitulate or hard/soft fork off. (I imagine
they will capitulate... unless they want to have fun being poor)
6. no double spends) No need to stress about writing code to prevent
double spends the chain will stay together.
7. no PoW change) No need to stress about changing the PoW unless the
miner majority doesn't signal. In that case a flag day is needed with
a PoW change so the forked chain is safe. It's too risky to have to
re-upgrade, in the middle of Taproot deployment, to a new client to
deploy a PoW change in the event that the majority mining power is not
on board.
7. minority miners forced to comply or fork off) Zealous miners
against the proposed feature are forced to hard fork with an
anti-Taproot fork if signaling is greater than 51%. The hard fork will
have 49% in the worst case, probably much less if we assume humans are
greedy. The miner minority may attack if they are confident they will
succeed. But their success is unlikely due Nakamoto consensus.
8. no early adopter dilema) There is no reluctance of upgrading
because it's more likely the new version will be on the chain with the
most PoW. This fixes the early adopter dilemma.
9. no late adopter stress) Since the result of activation keeps all
users together and minority miners are forced off, late adopters don't
need to worry about upgrading their client to not risk being reorged.
They will be on the taproot activated chain.
10. majority attracts the undecided) At 51% of mining power and an
economic majority I would say Greg Maxwell's "opposed unless there is
clear consensus on LOT=true" is very well satisfied. (paraphrase
provided by michaelfolkson
http://gnusha.org/taproot-activation/2021-02-16.log)
11. discovered bugs can back out deployment) With forced activation
there is no way to back out activation unless all users revert to
using a previous version or upgrade to using a new fixed version. But
it's not guaranteed that all users will revert or upgrade. This
proposal allows a cancelation if we force the majority of miners to
not signal.
12. no alt-nodes) A UASF media blitz can achieve activation with 51%
miner support and can be executed with a client released by core
instead of an alt-node.
13. no dev+miner forced changes) Users maintain sovereignty in future
soft forks by maintaining the option of creating anti-feature hard
fork or soft fork movements as long as they have enough mining power
to maintain a safe chain. Miners and devs don't have ultimate power.
(unless a supermajority of both groups agree to an anti-user feature
but I find that unthinkable right now since the economic majority
wouldn't comply easily, may happen in the future, who knows)
14. no dev forced changes) Avoid a power grab from core developers and
a minority of users. They can't force a feature change because miners
and an economic majority together can veto. At minimum the forced
feature requires 51% mining power and zero user support, even in that
case majority users still have options. (point 10)
15. less miner polling pre-deployment) One of the rationales to lower
the activation threshold from 95% to 90% is due to 89% verbal miner
support https://taprootactivation.com/ . I saw some people wanted to
go as low as 85% or 80%, hell someone on the ##uasf channel wanted to
drop threshold to 65% to incentivize non-upgraded nodes to join the
UASF alt-node http://gnusha.org/uasf/2021-03-04.log . With this
proposal it doesn't matter if miners don't overwhelmingly support the
feature so their verbal input is less significant. Deployment can
happen as soon as 51% of mining power express verbal support, unlike
what's happening right now where miner apathy is delaying deployment
because no one is sure whether a supermajority is achievable.
16. new status quo) I'm not sure I understand when Luke says LOT=true
is status quo but this proposal probably fixes that too? This proposal
kind of acts like a flag day with the protection of a majority PoW.
The case for this new proposal for supporters of LOT=false first:
1. discovered bugs can back out deployment) The activation can be
canceled and the chain will remain united if any problem is found.
(point 1 on Matt's Modern Soft Fork Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
2. miner minority can't cancel) Only 51% of mining power can cancel if
a bug is found so a minority of miners can't abuse the threat of
canceling for political reasons.
3. no need for miner promises) In the back of the minds of LOT=false
supporters there is always the doubt of "what if we really can't trust
miners?". We can ask them and make them promise that they will support
the upgrade but we can never really know. With this proposal we don't
need to worry about a miner minority promising to signal and then
breaking the promise.
4. no UASF aggression at the start) Miners aren't antagonized because
they are still part of the signaling process and they keep their right
to run any client they want without the threat of a UASF. Though they
will eventually mine orphan blocks if they don't upgrade, which is
probably true for a handful of miners even today.
5. UASF is optional) If miners seem to be stalling or not signaling
users have the option of running a media blitz without having to
coordinate the release of a new UASF client. This removes the
complications of multiple client releases interacting to activate the
same feature.
6. UASF is reactive) Forcing miners to upgrade with a media blitz and
a threat to create a hard fork later will be after miners are shown to
be apathetic or malicious. Users have time to gather information while
the MUST_SIGNAL period approaches.
7. no user forced changes) Removes the precedent of users forcing
changes on miners because they must attain 51% miner support. If users
have less than 51% miner support they must hard fork instead.
8. safe supermajority activation) The threshold will remain in
supermajority territory 95% before the MUST_SIGNAL phase. When a
supermajority is achieved there will be minimal disruption and minimal
detriment to Bitcoin's security. (point 3 on Matt's Modern Soft Fork
Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
9. users have time to upgrade) Users will have an appropriate amount
of time to upgrade. (whatever time it takes to achieve supermajority)
(point 2 on Matt's Modern Soft Fork Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
10. no long deployments) In case of miners not reaching a
supermajority due to apathy we won't have to wait six months and then
another release and another long deployment.
11. no UASF minority chain) Users won't be reorged because if at the
end of activation support is below 51% taproot wont activate and users
will stay together.
12. no big reorgs) If more than 51% of miners support Taproot then
upgraded users, non-upgraded users, and minority miners will stay on
the same chain. Some non-upgraded users and miners will be at risk of
creating and following orphan blocks. But the likelihood is that the
miner minority will upgrade if we assume that they are self-interested
and don't want to mine orphan blocks. This results in a small risk of
chain split and small risk of big reorgs. (point 4 on Matt's Modern
Soft Fork Activation proposal
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html)
13. no late adopter stress) If mining power majority is not achieved
during activation then all miners stay on the same chain and late
adopters don't need to worry about the risk of some UASF chain
overtaking theirs.
14. no divergent consensus rules) The chain can stay together and our
friends won't fork off because we will all be running the same client
and the client will be backwards compatible.
15. no need for redeployment) If activation fails it's clear that it
happened due to a lack of a majority of clients supporting the change
and a lack of a strong enough economic group to force miners to
upgrade. So if activation fails we can be sure that we won't be
releasing the feature again or the feature must be released as a hard
fork if a group of users really really want it.
16. no co-optable deployment) No more LOT flag so code can't be easily
modified to create divergent consensus from a core release.
17. no incentive to force signaling) A big reason for users to force
signaling is for reorg protection in case they are in a minority
chain. With this proposal the UASF chain is protected from reorgs by a
miner majority so no need to force signaling.
18. no configurable consensus) No more LOT flag so no need for a
parameter/config value to force users to pick a side on upgrade.
Forcing the choice on users guarantees there will be users running a
UASF but at the same time reduces the likelihood of a successful UASF
due to other users running LOT=false.
19. no alt-nodes) If this proposal gains consensus and it can be
released in core then we will avoid the issue of fracturing groups of
core forks jockeying for user support.
20. miners can test features before deployment) If changes can be
written to core without contention or risk of divergent consensus.
Core can release RCs for miners and users to test the feature. I think
it would have helped to know the segwit-ASIC boost conflict before
segwit signaling even though there is no guarantee that it would have
been disclosed. But maybe having this ability will be useful for other
features.
21. no false flagging interference) No need for two activation periods
so no need to worry about buggy miner signaling software (false
flagging) that may continue to signal for the prior deployment. This
is a potential issue for modern soft fork activation. (this issue is
mentioned by AJ Towns in the decreasing threshold proposal
https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki)
22. no dev vilification) Core developers can't be portrayed as having
ultimate power because they at least require 51% miner support.
23. safe supermajority threshold) Since the threshold will drop to 51%
during MUST_SIGNAL we could take the luxury of raising the
supermajority threshold back to 95% instead of 90%. This increases the
risk of miner stalling but that's the worst that could happen, which
is pretty good IMO.
24. no flag day) Avoids the pressure of devs pulling the trigger on a
flag day because this proposal removes (reduces?) the likelihood that
there will be a future chain split. This takes a lot of pressure off
of devs releasing this deployment.
25. no Taproot death) If we go with LOT=false first and it fails,
there is no getting around the fact that one group will want LOT=true
and the other group will want to drop Taproot altogether. I think devs
will still have a hard time deploying LOT=true after LOT=false.
26. no procrastinating) Since the deployment period doesn't need to be
too long for a safe LOT=true (after a failed LOT=false signaling
period) then there isn't a risk of users and miners procrastinating
upgrades until the last 3 or so months before the flag day.
27. another activation failure does not kill the MASF method) If
LOT=false fails again it was likely we would have never used it again.
That would be the death of quick MASF. But with this proposal the only
way to fail is if a majority of miners are against the feature and
have been unconvinced by an economic minority media blitz. In which
case the feature is contentious but the activation method remains
intact.
The case for this proposal for supporters of a straight flag-day:
1. no divergent consensus rules) all nodes will be compatible and
backwards compatible so they will all stay with the same consensus
rules.
2. discovered bugs can back out deployment) A flag day can't be
canceled. With this proposal if we find a bug it's easy for miners to
revert to an old version to get signaling below 51%.
3. signaling is available) With signaling we can all see the progress
of the activation. We will know if it's near a supermajority, we will
know if it's near the 51% milestone. Without signaling we might fail
to gather adoption and not even know which miners were actually
running the new version.
4. majority hash power will stay together) All users and the majority
mining power will stay on the same chain. It's possible that a
minority of mining power will fall out of consensus if they don't
enforce Taproot rules but if we assume they will act in their best
interest then they will upgrade once the simple majority of mining
power is signaling. Minority miners that are staunchly against
upgrading or are just really really really lazy and maybe take mining
as a hobby will fork off. But It's not possible to force those
minority miners anyway. For example there could be a minority of
miners running pre-segwit software today.
5. no redeploy to move the date) With a 95% threshold and a 51% at the
end we can be certain that the change will or won't activate. So no
need to scramble to move dates or potentially release a LOT=false
client earler than the flag day. Any of that scrambing is gone because
we just wait. The worst that could happen is a 6% miner minority can
delay the change until the MUST_SIGNAL period.
6. it's clear who wins under contention) Flag day activations need as
much economic adoption as any other method. With a flag day, any
contention in the feature will lead to entrenched groups and a split
is inevitable. With this proposal the economic majority decides by
forcing miners to signal one way or another by threatening a hard
fork. But with this proposal it's clear that who wins the debate is
who wins 51% miner support so the economic majority (if it's very
small will likely reconsider not forking off). With a flag day, who
wins the debate is only clear years after the flag day based on market
capitalization.
7. can start building early) Developers will have high assurance that
the change will activate after the 51% threshold is reached so they
can start building after 51% and don't need to wait until the
supermajority.
8. MASF is available) Activation can happen very early with a
supermajority since Taproot is not contentious. (still the most likely
outcome, by far!)
9. no dev forced changes) Avoid a power grab from core developers to
rush a flag day that doesn't have enough economic majority. Once the
client is released the chain split is nearly guaranteed. With this
proposal devs would need a miner majority and a supporting economic
majority or an apathetic economy supermajority.
The case for this new proposal for supporters of gradual decreasing
activation threshold:
1. no gaming thresholds) Miners can't suddenly signal at 55% threshold
to force 45% of non-signaling miners to scramble an update.
The case for this new proposal for supporters on all sides:
1. conservative enough for core) If we can fix all the kinks and
achieve some consensus I think this proposal will be safe enough to be
supported by core devs.
2. remove activation contention) If things go well we might get a few
more rounds of soft fork activation without contention.
3. no ambiguity on which chain is bitcoin) If there is a minority
group that forks off then the chain called Bitcoin will be the one
with the most economic support and miner support. With this come the
benefits that 21 million stays 21 million and $1 trillion stays $1
trillion. Unless a majority of mining power is trying to force a soft
fork that antagonizes the economic majority. Tthis miner oppression
would then be considered a 51% attack and maybe a PoW change is in
order.
4. *this is a real solution not a compromise*) I think this solution
fixes so many issues on both sides of the LOT debate that I see it as
better than either solution independently. This is a real solution and
the added benefit is that it's a solution that coincidentally brings
both sides of the debate together.
5. only contentious changes make contentious activation) Contentious
activations will be ones that have near 50/50 miner support. Features
like that will probably never even get to the activation stage and
Taproot is not one of them.
6. no LOT drama) The LOT flag is removed so no more default to argue
over. No more drama. And no cover for social attacks on bitcoin.
7. no mid-deployment changes) Deployment is on complete autopilot so
users don't need to change any configuration in the middle of
deployment period.
Leave it to bitcoiners to turn bitcoin's biggest flaw (51% attacks)
into a feature (51% upgrade pressure). The Bitcoin space is so
fascinating.
I hope there isn't some giant obvious flaw I'm missing. Please tell me
if I am. Or add to the arguments if you'd like.
Cheers
Ariel Lorenzo-Luaces

2023-06-07 18:29:52

- reply

📅 Original date posted:2021-03-04
📝 Original message:On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> At this point in time it also appears the greatest risk to Taproot
> dying a slow death is a small group of developers who think talking in
> conservative tones and talking about endless philosophy makes Bitcoin
> a conservative system. (It doesn’t, it just makes it a dying, decaying
> one).
The current risk to taproot and all future activations is a loud
minority of users who are threatening to co-opt a LOT=false activation
by switching the parameter and organizing a marketing blitz that could
end in a fork if things don't go well.
As long as that threat persists consensus won't be reached. Then an
activation client probably won't be released because I don't expect
many devs will have an appetite for writing code that either doesn't
have consensus or code that will be manipulated into creating
consensus conflicts.
I think Bitcoin is fine staying as is until that minority forks off
with their own alt-node. If the UASF minority is dead set on creating
the alt-node then I only hope it's released quickly so the deadlock
can break. A quick UASF fork allows for an early LOT=false activation.
Cheers
Ariel Lorenzo-Luaces
> --
> Michael Folkson
> Email: 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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:01

- reply

📅 Original date posted:2021-02-24
📝 Original message:On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset.
>
> Where am I wrong here?
>
> Keagan
>
> On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake).
>>
>> Cheers,
>>
>> Jeremy
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
To favor LOT=true because it seems like the inevitable result is like
playing the prisoner's dilemma and never cooperating instead of using
the most optimal strategy which is tit-for-tat (cooperating at first
and then cheating once for every time your counterparty cheats).
During segwit users started by cooperating (BIP9, or "LOT=false"),
then a minority of
miners didn't cooperate (small veto but remember the majority of
miners cooperated), then users stopped cooperating in response (UASF),
then miners
reverted to cooperating (MASF while intolerant miners forked off).
Today users should start cooperating again to continue using the
optimal strategy.
Cheers
Ariel Lorenzo-Luaces

2023-06-07 18:28:53

- reply

📅 Original date posted:2021-02-19
📝 Original message:Hi Michael
I think you're right, sorry for getting a little apocalyptic at the
end there lol.
> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>
> 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.
I'm mostly referring to the two IRC discussions. I normally try to
avoid singling people out that's why I didn't refer to anyone in
perticular.
Here I'll list a couple of quotes from these ephemeral people, while
reading them keep in mind what would happen if a majority users and
miners decide to just avoid the latest version.
- 11:06: "LOT=true does not split the chain. It strictly reduces the
liklihood of that."
- 11:06: "LOT=false has chainsplit risks, not LOT=true"
- 08:59 "I guess it would be helpful to hear miners' answers to that question."
Response: 09:01 "not sure why; miners don't decide anything in this
regard it's more of `Taproot is activating. Please accelerate it if
you can`"
Reading the logs again I see some voices that do consider the right
that users and miners have to run whatever version they want
Response: 09:03 "I ask because you said something that's equivalent to
`miners don't get to decide which version of core their run`."
- T1, T2, T3, and T6 have language that assumes mass support for a
UASF and then proceed to make conclusions on what is safer and easier
to coordinate
A voice in the discussion expressed the same point I'm making:
10:53 "I disagree with T1: i don't think there is any logical
consequence in hardcoding LOT=true ensuring Taproot activation and
even less ensuring no political shenanigans. We obviously need
economic majority to run it and that would open way more political
arguments that they bluntly take part in an UASF without any bad
behaviour from miners."
- 11:14 "we know people will run LOT=true regardless of the default,
so it will be safer if LOT=true is made the default"
- 11:18 "With LOT=true, attempted UASFs are not necessary"
- 11:18 "why give them the ability to act maliciously in the first place?"
Response:11:18"LOT=false does not; people choosing to run software
that will enforce taproot under some reasonable circumstances provides
the information. LOT=false just reduces the risk of unexpected
results from resulting in danger."
Response: 11:18 "LOT=false strictly increases the risks though.."
Response: 11:18 "please stop saying that, there are tradeoffs both ways."
- 11:11 "LOT=false gives miners the ability to decide [in response to
someone saying that LOT=false gives everyone else in the community the
ability to decide]"
This quote is a bit more nuanced because the implication is that
LOT=true doesn't give the ability to decide. But in reality they have
the ability to decide to not upgrade. Users can also not upgrade to
be in solidarity with miners to protect them from unfair distrust and
aggression.
All the arguments above for LOT=true are rooted in the assumption that
everyone must upgrade to the latest version because of course they
will...? But that's not a given.
There are examples of people being aware that miners and users can run
any version they want. I misjudged the number of people who know that
LOT=true doesn't guarantee anything.
- 11:17 "The LOT=True crowd seems to have an underlying assumption
that a UASF will occur instead of something more orderly like Modern
Softfork Activation suggested, why? I don't think chances of that
happening are very high unless things play out similarly to Segwit but
it doesn't look like that."
- 11:17 "UASFs can be made much more difficult with a counter-UASF....
UASFs like this one and segwit relied on intolerant-minority effects"
(I'm assuming counter-UASF means not upgrading as opposed to upgrading
to a new client that rejects the activation flag)
> 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.
If you look at https://taprootactivation.com/ no miners seem to be
expressing any support at all for lot=true. To pre-empt the counter
argument, I know that miners don't decide, I'm just using that poll as
a proxy to estimate whether they would be antagonized by the promotion
of LOT=true.
I'm not a miner and I think the "fork will happen regardless of the
consequences" attitude is antagonistic towards everyone in general,
not just miners.
The LOT=true activation mechanism may be tolerated today because
Taproot has wide support. But in order to prevent future antagonistic
behavior around future network changes (possibly more controversial
ones) we should continue the norm of including miners in the
activation process, as the friends they are.
This idea that LOT=true provides clarity is another is another example
of an argument rooted in the assumption that users will upgrade
because of course they will. No activation mechanism provides ANY
guarantees and neither does LOT=true so it's infair to frame it as if
it does.
This is your argument Michael, please don't take anything I say
personally I'm just arguing the points.
> 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) 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.
If a LOT=true client is released I think the likely outcome is that
people won't upgrade at all and I would say that miners failing to
activate will become more likely than you think, strictly due to a
loud group promoting LOT=true.
It's true that some will stubbornly run LOT=true regardless. But if
they have not been provoked to do so then I would hope the community
promotes unity and shuns needlessly conflictive attitudes to avoid
the, admittedly inevitable, network split from gathering momentum (a
counter-UASF).
I hope individuals opt for unity and become intolerant (counter-UASF)
of intolerance (unprovoked-UASF).
> TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my email :)
Yes I do agree with the recommendation of LOT=false. Thank you for
organizing the discussion.
On Thu, Feb 18, 2021 at 3:12 AM Samson Mow <samson.mow at gmail.com> wrote:
>
> "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?
By "we" I meant everyone involved in the discussion of the activation
mechanism. The discussion is slowly growing and eventually has to
reach social media.
>
> Release both and let the network decide.
If two clients are released with matching activation parameters except
for opposing LOT then LOT=true kind of spoils the LOT=false choice
(only if LOT=true manages to gather support) because running LOT=false
is being complicit/tolerant of the aggressive attitude of LOT=true.
In the case of both being released I would opt for running neither and
I hope most users and miners do too. Again, with the caveat that only
if there is visible significant support for LOT=true. And yes, the
"significant" is a subjective word and, based on risk appetite, is
different for everyone. That's part of the issue.
A funny metaphor is that if someone is visibly pissing in a pool I'm
not going to swim on the other side of the pool, I just won't swim at
all and go do whatever I was doing before.
Cheers
Ariel Lorenzo-Luaces
On Thu, Feb 18, 2021 at 7:18 AM Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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>
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev