* [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
@ 2021-02-28 16:45 Matt Corallo
2021-02-28 17:20 ` Luke Dashjr
2021-03-03 14:59 ` Anthony Towns
0 siblings, 2 replies; 15+ messages in thread
From: Matt Corallo @ 2021-02-28 16:45 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
As anyone reading this list is aware, there is significant debate around the activation method for the proposed Taproot
soft fork. So much so, and with so much conviction, that many individuals are committing themselves to running
incompatible consensus rules. Obviously, such commitments, were they to come to pass, and were a fork to occur as a
result, would do more harm than any soft-fork does good. Further, such commitments and debate have likely delayed any
possible release of a future Taproot activation while issues around locked-in activation are debated, instead of
avoiding it as was the original intent of the "just ship BIP 8 LOT=false and we'll debate the rest if we need to" approach.
Given this, it seems one way to keep the network in consensus would be to simply activate taproot through a traditional,
no-frills, flag-day (or -height) activation with a flag day of roughly August, 2022. Going back to my criteria laid out
in [1],
1) I don't believe we have or will see significant, reasonable, and directed objection. This has largely always been the
case, but it is also critical that the lack of such objection is demonstrable to outside observers. Ironically, the
ongoing debate (and clear lack of consensus) around activation methods can be said to have had that effect, at least as
far as the active Bitcoin Reddit/Twitter userbase is concerned. In addition, the public support for Taproot activation
made by mining pool operators further shows public review and acceptance. Ideally, large Bitcoin business operators who
previously took part in Bitcoin Optech's Taproot workshop [2] would publicly state something similar prior to release of
Taproot activation parameters. Because this expectation is social, no technical solution exists, only public statements
made in broad venues - something which I'd previously argued comes through soft fork activation parameter deployment,
but which can also come from elsewhere.
2) The high node-level-adoption bar is one of the most critical goals, and the one most currently in jeopardy in a BIP 8
approach. Users demanding alternative consensus rules (or, worse, configuration flags to change consensus rules on
individual nodes with an expectation of use) makes this very complicated in the context of BIP 8. Instead of debating
activation parameters and entrenching individuals into running their own consensus rules, a flag day activation changes
the problem to one of simply encouraging upgrades, avoiding a lot of possibility for games. Of course in order to meet
this goal we still need significant time to pass between activation parameter release and activation. Given the delays
likely to result from debates around BIP 8 parameters, I don't think this is a huge loss. Capitalizing on current
interest and demand for Taproot further implies a shortened timeline (eg a year and a half instead of two) may be merited.
3) The potential loss of hashpower is likely the biggest risk of this approach. It is derisked somewhat by the public
commitment of pool operators to Taproot activation, and can be de-risked further by seeking more immediate commitment
prior to release. Still, given the desire to push for a forced-signaling approach by many, there is more significant
risk of loss of hashpower in today's approach. In an ideal world, we could do something more akin to BIP 9/BIP 8(false)
to reduce risk of this further, but its increasingly likely that this is not possible. A flag-day which takes advantage
of the nonstandardness of Taproot transactions in current Bitcoin Core releases may suffice.
4) Similar arguments apply as the above around the public commitment from pool operators to enforce the Taproot
consensus rules.
5) Similar arguments apply as the discussion in (1).
Ultimately, the risk which is present in doing flag day activations (and the reason I've argued against them as a
"default" in the past) are present as well in BIP 8(true), forced-signaling activations where community debate splits
the consensus rules across nodes. While such a deployment could delay Taproot somewhat, it sidesteps a sufficient amount
of debate and resulting delay that I wouldn't be surprised if it did not. Further, Taproot has been worked on for many
years now with no apparent urgency from the many who are suddenly expressing activation urgency, making it more likely
such urgency is artificial. Those who seek Taproot activation for Bitcoin market reasons should also rejoice - not only
can the market celebrate the final release of Taproot, but it gets a second celebratory event in 2022 when the
activation occurs.
Matt
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
[2] https://bitcoinops.org/en/schorr-taproot-workshop/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 16:45 [bitcoin-dev] Straight Flag Day (Height) Taproot Activation Matt Corallo
@ 2021-02-28 17:20 ` Luke Dashjr
2021-02-28 17:29 ` Matt Corallo
2021-03-03 14:59 ` Anthony Towns
1 sibling, 1 reply; 15+ messages in thread
From: Luke Dashjr @ 2021-02-28 17:20 UTC (permalink / raw)
To: bitcoin-dev, Matt Corallo
On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> many individuals are committing themselves to running
> incompatible consensus rules.
Yet that is exactly what you propose herein...
> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022.
Concept NACK. This still has the same problems BIP149 would have had, as I
just reminded in my last email to this ML:
1) Such a chain does not indicate activation at all, leaving it unresolved and
debatable whether activation has occurred or not.
2) As a result, it is also impractical to intentionally reject the softfork
should anyone decide to do so.
Signalling is important to activation.
> 2) The high node-level-adoption bar is one of the most critical goals, and
> the one most currently in jeopardy in a BIP 8 approach.
It is only jeopardized if people continue to push for a LOT=False deployment
(or this new proposal of yours).
BIP 8 itself, with LOT=True, does not create such a risk at all.
> Users demanding alternative consensus rules (or, worse, configuration flags
> to change consensus rules on individual nodes with an expectation of use)
> makes this very complicated in the context of BIP 8.
Alternative consensus rules is exactly what you are proposing here.
More alternative rules to choose from just increase the risks. Two options is
annoying, but adding a third for no reason is just absurd.
Luke
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 17:20 ` Luke Dashjr
@ 2021-02-28 17:29 ` Matt Corallo
2021-02-28 19:43 ` Jeremy
0 siblings, 1 reply; 15+ messages in thread
From: Matt Corallo @ 2021-02-28 17:29 UTC (permalink / raw)
To: Luke Dashjr, bitcoin-dev
I think you may have misunderstood my proposal. I'm not suggesting some people run BIP 8(true), some run BIP8(false),
and some run a client which has a flag day, I'm suggesting a flag day activation instead of any BIP8-based activation.
Replies to your further points inline.
Matt
On 2/28/21 12:20, Luke Dashjr wrote:
> On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> Concept NACK. This still has the same problems BIP149 would have had, as I
> just reminded in my last email to this ML:
>
> 1) Such a chain does not indicate activation at all, leaving it unresolved and
> debatable whether activation has occurred or not.
> 2) As a result, it is also impractical to intentionally reject the softfork
> should anyone decide to do so.
>
> Signalling is important to activation.
Several people responded disagreeing, including myself. I'll paste my response here in case you missed it:
Forced-signaling, or any form of signaling, does not materially change whether a soft fork can be seen to be safe to
use. Pieter wrote a great post[1] some time ago that goes into depth about the security of soft forks, but, while miners
can help to avoid the risk of forks, they aren't the determining factor in whether use of a fork should be considered
safe (ie the fork "has activated").
Not only that, but the signaling methods used in BIP 8/9 (ie the version field in the block header) do not imply
anything about whether mining pools are running full nodes which enforce the soft fork at all, only whether the pool has
configured their stratum software to signal or not.
Ultimately, forced-signaling, or signaling period, are not a substitute for having a broad set of upgraded nodes across
the network, including an overwhelming majority of economically-active nodes, enforcing the rules of a new fork. As this
can be difficult to measure, waiting some time after a fork and examining upgrade patterns across the network is important.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 17:29 ` Matt Corallo
@ 2021-02-28 19:43 ` Jeremy
2021-02-28 19:51 ` Matt Corallo
0 siblings, 1 reply; 15+ messages in thread
From: Jeremy @ 2021-02-28 19:43 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4083 bytes --]
I agree with much of the logic presented by Matt here.
BIP8 was intended to be simpler to agree on to maintain consensus, yet we
find ourselves in a situation where a "tiny" parameter has the potential to
cause great network disruption and confusion (rationality is not too useful
a concept here given differing levels of sophistication and information).
It is therefore much simpler and more likely to be universally understood
by all network participants to just have a flag day. It is easier to
communicate what users should do and when.
This is ultimately not coercive to users because the upgrade for Taproot
itself is provable and analyzable on its own, but activation parameters
based on what % of economically relevant nodes are running an upgrade by a
certain date are not. Selecting these sorts of complicated consensus
parameters may ultimately present more opportunity for a cooptable
consensus process than something more straightforward.
That said, a few points strike me as worth delving into.
1) Con: Mandatory signalling is no different than a flag day. Mandatory
signaling is effectively 2 flag days -- one for the signaling rule, 1 for
the taproot type. The reason for the 2 week gap between flag day for
signaling and flag day for taproot rules is, more or less, so that nodes
who aren't taproot ready at the 1st flag day do not end up SPV mining
(using standardness rules in mempool prevents them from mining an invalid
block on top of a valid tip, but does not ensure the tip is valid).
2) Con: Releasing a flag day without releasing the LOT=true code leading up
to that flag day means that clients would not be fully compatible with an
early activation that could be proposed before the flag day is reached.
E.g., LOT=true is a flag day that retains the possibility of being
compatible with other BIP8 releases without changing software.
3) Pro: BIP-8 is partially in service of "early activation" and . I'm
personally skeptical that early activation is/was ever a good idea. A fixed
activation date may be largely superior for business purposes, software
engineering schedules, etc. I think even with signaling BIP8, it would be
possibly superior to activate rules at a fixed date (or a quantized set of
fixed dates, e.g. guaranteeing at least 3 months but maybe more).
4) Pro: part of the argument for BIP-8=false is that it is possible that
the rule could not activate, if signaling does not occur, providing
additional stopgap against dev collusion and bugs. But BIP-8 can activate
immediately (with start times being proposed 1 month after release?) so we
don't have certainty around how much time there is for that secondary
review process (read -- I think it isn't that valuable) and if there *is* a
deadly bug discovered, we might want to hard-fork to fix it even if it
isn't yet signaled for (e.g., if the rule activates it enables more mining
reward). So I think that it's a healthier mindset to release a with
definite deadline and not rule out having to do a hard fork if there is a
grave issue (we shouldn't ever release a SF if we think this is at all
likely, mind you).
5) Con: It's already taken so long for taproot, the schedule around taproot
was based on the idea it could early activate, 2022 is now too far away. I
don't know how to defray this other than, if your preferred idea is 1 year
flag day, to do that via LOT=true so that taproot can still have early
activation if desired.
Overall I agree with the point that all the contention around LOT, makes a
flag day look not so bad. And something closer to a flag day might not be
so bad either for future forks as well.
However, I think given the appetite for early activation, if a flag day is
desired I think LOT=true is the best option at this time as it allows our
flag day to remain compatible with such an early activation.
I think we can also clearly communicate that LOT=true for Taproot is not a
precedent setting occurence for any future forks (hold me accountable to
not using this as precedent this should I ever advocate for a SF with
similar release parameters).
[-- Attachment #2: Type: text/html, Size: 6700 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 19:43 ` Jeremy
@ 2021-02-28 19:51 ` Matt Corallo
2021-02-28 20:02 ` Jeremy
0 siblings, 1 reply; 15+ messages in thread
From: Matt Corallo @ 2021-02-28 19:51 UTC (permalink / raw)
To: Jeremy, Bitcoin Protocol Discussion
Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin
Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from
my original post - it results in any miner who has not taken active action (and ensured every part of their often-large
infrastructure has been correctly reconfigured) generating invalid blocks.
As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
Matt
On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> I agree with much of the logic presented by Matt here.
>
> BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a "tiny"
> parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept
> here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
> universally understood by all network participants to just have a flag day. It is easier to communicate what users
> should do and when.
>
> This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on its own,
> but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain date are
> not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a cooptable
> consensus process than something more straightforward.
>
>
> That said, a few points strike me as worth delving into.
>
>
> 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days -- one for
> the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and flag day
> for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV mining
> (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
> ensure the tip is valid).
> 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients would
> not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g., LOT=true
> is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
> 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation is/was
> ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering schedules,
> etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a quantized
> set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
> 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if signaling does
> not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with start
> times being proposed 1 month after release?) so we don't have certainty around how much time there is for that secondary
> review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
> hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining reward). So I
> think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard fork if
> there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
> 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
> activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year flag
> day, to do that via LOT=true so that taproot can still have early activation if desired.
>
> Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
> closer to a flag day might not be so bad either for future forks as well.
>
> However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best option
> at this time as it allows our flag day to remain compatible with such an early activation.
>
> I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any future
> forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
> parameters).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 19:51 ` Matt Corallo
@ 2021-02-28 20:02 ` Jeremy
2021-02-28 20:19 ` Eric Voskuil
2021-02-28 20:20 ` Matt Corallo
0 siblings, 2 replies; 15+ messages in thread
From: Jeremy @ 2021-02-28 20:02 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6349 bytes --]
Miners still can generate invalid blocks as a result of SPV mining, and it
could be profitable to do "bad block enhanced selfish mining" to take
advantage of it.
Hard to analyze exactly what that looks like, but...
E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate
to mine bad blocks would mean 1/4th of the time you could make 20% of the
hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One
could analyze out that the lost hash rate for bad blocks only matters for
the first difficulty adjustment period you're doing this for too, as the
hashrate drop will be accounted for -- but then a miner can switch back to
mining valid chain, giving themselves a larger % of hashrate.
So it is still possible that an un-upgraded miner will fail part 3, and
attempting to accommodate un-upgraded miners leads to some nasty
oscillating hashrate being optimal.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo•com>
wrote:
> Note further that mandatory signaling isn't "just" a flag day - unlike a
> Taproot flag day (where miners running Bitcoin
> Core unmodified today will not generate invalid blocks), a mandatory
> signaling flag day blatantly ignores goal (3) from
> my original post - it results in any miner who has not taken active action
> (and ensured every part of their often-large
> infrastructure has been correctly reconfigured) generating invalid blocks.
>
> As for "Taproot" took too long, hey, at least if its locked in people can
> just build things assuming it exists. Some
> already are, but once its clearly locked in, there's no reason to not
> continue other work at the same time.
>
> Matt
>
> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> > I agree with much of the logic presented by Matt here.
> >
> > BIP8 was intended to be simpler to agree on to maintain consensus, yet
> we find ourselves in a situation where a "tiny"
> > parameter has the potential to cause great network disruption and
> confusion (rationality is not too useful a concept
> > here given differing levels of sophistication and information). It is
> therefore much simpler and more likely to be
> > universally understood by all network participants to just have a flag
> day. It is easier to communicate what users
> > should do and when.
> >
> > This is ultimately not coercive to users because the upgrade for Taproot
> itself is provable and analyzable on its own,
> > but activation parameters based on what % of economically relevant nodes
> are running an upgrade by a certain date are
> > not. Selecting these sorts of complicated consensus parameters may
> ultimately present more opportunity for a cooptable
> > consensus process than something more straightforward.
> >
> >
> > That said, a few points strike me as worth delving into.
> >
> >
> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory
> signaling is effectively 2 flag days -- one for
> > the signaling rule, 1 for the taproot type. The reason for the 2 week
> gap between flag day for signaling and flag day
> > for taproot rules is, more or less, so that nodes who aren't taproot
> ready at the 1st flag day do not end up SPV mining
> > (using standardness rules in mempool prevents them from mining an
> invalid block on top of a valid tip, but does not
> > ensure the tip is valid).
> > 2) Con: Releasing a flag day without releasing the LOT=true code leading
> up to that flag day means that clients would
> > not be fully compatible with an early activation that could be proposed
> before the flag day is reached. E.g., LOT=true
> > is a flag day that retains the possibility of being compatible with
> other BIP8 releases without changing software.
> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm
> personally skeptical that early activation is/was
> > ever a good idea. A fixed activation date may be largely superior for
> business purposes, software engineering schedules,
> > etc. I think even with signaling BIP8, it would be possibly superior to
> activate rules at a fixed date (or a quantized
> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
> > 4) Pro: part of the argument for BIP-8=false is that it is possible that
> the rule could not activate, if signaling does
> > not occur, providing additional stopgap against dev collusion and bugs.
> But BIP-8 can activate immediately (with start
> > times being proposed 1 month after release?) so we don't have certainty
> around how much time there is for that secondary
> > review process (read -- I think it isn't that valuable) and if there
> *is* a deadly bug discovered, we might want to
> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule
> activates it enables more mining reward). So I
> > think that it's a healthier mindset to release a with definite deadline
> and not rule out having to do a hard fork if
> > there is a grave issue (we shouldn't ever release a SF if we think this
> is at all likely, mind you).
> > 5) Con: It's already taken so long for taproot, the schedule around
> taproot was based on the idea it could early
> > activate, 2022 is now too far away. I don't know how to defray this
> other than, if your preferred idea is 1 year flag
> > day, to do that via LOT=true so that taproot can still have early
> activation if desired.
> >
> > Overall I agree with the point that all the contention around LOT, makes
> a flag day look not so bad. And something
> > closer to a flag day might not be so bad either for future forks as well.
> >
> > However, I think given the appetite for early activation, if a flag day
> is desired I think LOT=true is the best option
> > at this time as it allows our flag day to remain compatible with such an
> early activation.
> >
> > I think we can also clearly communicate that LOT=true for Taproot is not
> a precedent setting occurence for any future
> > forks (hold me accountable to not using this as precedent this should I
> ever advocate for a SF with similar release
> > parameters).
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
[-- Attachment #2: Type: text/html, Size: 8561 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 20:02 ` Jeremy
@ 2021-02-28 20:19 ` Eric Voskuil
2021-02-28 20:25 ` Matt Corallo
2021-02-28 20:20 ` Matt Corallo
1 sibling, 1 reply; 15+ messages in thread
From: Eric Voskuil @ 2021-02-28 20:19 UTC (permalink / raw)
To: Jeremy, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8270 bytes --]
In the attempt to change consensus rules there is a simple set of choices:
1) hard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split
The presumption being that one can never assume 100% explicit adoption of any rule change.
A 51% attack can of course fail. It is also possible that signaling can be untruthful. But miner signaling provides some level of assurance that it will be successful. This level of assurance is increased by adoption of a higher than majority threshold, as has been done in the past.
Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nobody is in charge.
The majority of those who mine can choose to enforce censorship any time they want. They don’t need anyone’s permission. No power is given to them by developers or anyone else. They have that power based on their own capital invested.
Similarly, the economy (those who accept bitcoin) can enforce any rule change it wants to. And it can do so at any level of participation that wants to go along. Anyone can do this, it requires nobody’s permission. Furthermore, it is possible for the economy to signal its level of agreement in every transaction, as miners have done in blocks previously.
But if the objective is to produce a rule change while avoiding a chain split, 50% is a much lower bar than 100%. If there is some other objective, it’s not clear to me what it is.
e
> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced selfish mining" to take advantage of it.
>
>
> Hard to analyze exactly what that looks like, but...
>
> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this for too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving themselves a larger % of hashrate.
>
> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners leads to some nasty oscillating hashrate being optimal.
>
>
> --
> @JeremyRubin
>
>
>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo•com> wrote:
>> Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin
>> Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from
>> my original post - it results in any miner who has not taken active action (and ensured every part of their often-large
>> infrastructure has been correctly reconfigured) generating invalid blocks.
>>
>> As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
>> already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>>
>> Matt
>>
>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>> > I agree with much of the logic presented by Matt here.
>> >
>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a "tiny"
>> > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept
>> > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
>> > universally understood by all network participants to just have a flag day. It is easier to communicate what users
>> > should do and when.
>> >
>> > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on its own,
>> > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain date are
>> > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a cooptable
>> > consensus process than something more straightforward.
>> >
>> >
>> > That said, a few points strike me as worth delving into.
>> >
>> >
>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days -- one for
>> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and flag day
>> > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV mining
>> > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
>> > ensure the tip is valid).
>> > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients would
>> > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g., LOT=true
>> > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation is/was
>> > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering schedules,
>> > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a quantized
>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
>> > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if signaling does
>> > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with start
>> > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that secondary
>> > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining reward). So I
>> > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard fork if
>> > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
>> > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
>> > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year flag
>> > day, to do that via LOT=true so that taproot can still have early activation if desired.
>> >
>> > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
>> > closer to a flag day might not be so bad either for future forks as well.
>> >
>> > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best option
>> > at this time as it allows our flag day to remain compatible with such an early activation.
>> >
>> > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any future
>> > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
>> > parameters).
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 12857 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 20:02 ` Jeremy
2021-02-28 20:19 ` Eric Voskuil
@ 2021-02-28 20:20 ` Matt Corallo
1 sibling, 0 replies; 15+ messages in thread
From: Matt Corallo @ 2021-02-28 20:20 UTC (permalink / raw)
To: Jeremy; +Cc: Bitcoin Protocol Discussion
SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the
last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make
money by reducing the difficulty, but that is true as much today as during a fork. Still, I think you've made my point -
someone has to take an active, malicious action in order to mine a bad block, vs with forced signaling, someone only
needs to forget to reconfigure one out of one hundred pool servers they operate.
Matt
On 2/28/21 15:02, Jeremy wrote:
> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced
> selfish mining" to take advantage of it.
>
>
> Hard to analyze exactly what that looks like, but...
>
> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the
> time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze
> out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this for
> too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving
> themselves a larger % of hashrate.
>
> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners
> leads to some nasty oscillating hashrate being optimal.
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>
>
> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote:
>
> Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin
> Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from
> my original post - it results in any miner who has not taken active action (and ensured every part of their often-large
> infrastructure has been correctly reconfigured) generating invalid blocks.
>
> As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
> already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>
> Matt
>
> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> > I agree with much of the logic presented by Matt here.
> >
> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a
> "tiny"
> > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept
> > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
> > universally understood by all network participants to just have a flag day. It is easier to communicate what users
> > should do and when.
> >
> > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on its
> own,
> > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain date
> are
> > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a
> cooptable
> > consensus process than something more straightforward.
> >
> >
> > That said, a few points strike me as worth delving into.
> >
> >
> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days --
> one for
> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and flag
> day
> > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV
> mining
> > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
> > ensure the tip is valid).
> > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients
> would
> > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g.,
> LOT=true
> > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation
> is/was
> > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering
> schedules,
> > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a
> quantized
> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
> > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if
> signaling does
> > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with
> start
> > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that
> secondary
> > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining
> reward). So I
> > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard fork if
> > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
> > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
> > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year
> flag
> > day, to do that via LOT=true so that taproot can still have early activation if desired.
> >
> > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
> > closer to a flag day might not be so bad either for future forks as well.
> >
> > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best
> option
> > at this time as it allows our flag day to remain compatible with such an early activation.
> >
> > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any
> future
> > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
> > parameters).
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 20:19 ` Eric Voskuil
@ 2021-02-28 20:25 ` Matt Corallo
2021-02-28 20:38 ` Eric Voskuil
0 siblings, 1 reply; 15+ messages in thread
From: Matt Corallo @ 2021-02-28 20:25 UTC (permalink / raw)
To: Eric Voskuil, Jeremy, Bitcoin Protocol Discussion
Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at [1], which I referenced and specifically
addressed each of in the OP of this thread.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
On 2/28/21 15:19, Eric Voskuil wrote:
> In the attempt to change consensus rules there is a simple set of choices:
>
> 1) hard fork: creates a chain split
> 2) soft fork: creates a chain split
> 3) 51% attack: does not create a chain split
>
> The presumption being that one can never assume 100% explicit adoption of any rule change.
>
> A 51% attack can of course fail. It is also possible that signaling can be untruthful. But miner signaling provides some
> level of assurance that it will be successful. This level of assurance is increased by adoption of a higher than
> majority threshold, as has been done in the past.
>
> Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin requires no identity; anyone can mine
> and/or accept bitcoin - nobody is in charge.
>
> The majority of those who mine can choose to enforce censorship any time they want. They don’t need anyone’s permission.
> No power is given to them by developers or anyone else. They have that power based on their own capital invested.
>
> Similarly, the economy (those who accept bitcoin) can enforce any rule change it wants to. And it can do so at any level
> of participation that wants to go along. Anyone can do this, it requires nobody’s permission. Furthermore, it is
> possible for the economy to signal its level of agreement in every transaction, as miners have done in blocks previously.
>
> But if the objective is to produce a rule change while avoiding a chain split, 50% is a much lower bar than 100%. If
> there is some other objective, it’s not clear to me what it is.
>
> e
>
>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>
>> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block
>> enhanced selfish mining" to take advantage of it.
>>
>>
>> Hard to analyze exactly what that looks like, but...
>>
>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the
>> time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze
>> out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this
>> for too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving
>> themselves a larger % of hashrate.
>>
>> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners
>> leads to some nasty oscillating hashrate being optimal.
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>>
>>
>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote:
>>
>> Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running
>> Bitcoin
>> Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3)
>> from
>> my original post - it results in any miner who has not taken active action (and ensured every part of their
>> often-large
>> infrastructure has been correctly reconfigured) generating invalid blocks.
>>
>> As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
>> already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>>
>> Matt
>>
>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>> > I agree with much of the logic presented by Matt here.
>> >
>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a
>> "tiny"
>> > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a
>> concept
>> > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
>> > universally understood by all network participants to just have a flag day. It is easier to communicate what users
>> > should do and when.
>> >
>> > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on
>> its own,
>> > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain
>> date are
>> > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a
>> cooptable
>> > consensus process than something more straightforward.
>> >
>> >
>> > That said, a few points strike me as worth delving into.
>> >
>> >
>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days --
>> one for
>> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and
>> flag day
>> > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV
>> mining
>> > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
>> > ensure the tip is valid).
>> > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients
>> would
>> > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g.,
>> LOT=true
>> > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation
>> is/was
>> > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering
>> schedules,
>> > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a
>> quantized
>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
>> > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if
>> signaling does
>> > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with
>> start
>> > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that
>> secondary
>> > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining
>> reward). So I
>> > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard
>> fork if
>> > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
>> > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
>> > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year
>> flag
>> > day, to do that via LOT=true so that taproot can still have early activation if desired.
>> >
>> > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
>> > closer to a flag day might not be so bad either for future forks as well.
>> >
>> > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best
>> option
>> > at this time as it allows our flag day to remain compatible with such an early activation.
>> >
>> > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any
>> future
>> > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
>> > parameters).
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 20:25 ` Matt Corallo
@ 2021-02-28 20:38 ` Eric Voskuil
0 siblings, 0 replies; 15+ messages in thread
From: Eric Voskuil @ 2021-02-28 20:38 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
I think it has been shown that an understanding of reasonableness is not universal, making any assertion about it as a collective goal kind of self-defeating. The question is what is achievable, not what is reasonable. I’m not making any value judgements here. Simply pointing out that anything other than a successful 51% attack will create a split.
e
> On Feb 28, 2021, at 12:25, Matt Corallo <lf-lists@mattcorallo•com> wrote:
>
> Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at [1], which I referenced and specifically addressed each of in the OP of this thread.
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
>
>> On 2/28/21 15:19, Eric Voskuil wrote:
>> In the attempt to change consensus rules there is a simple set of choices:
>> 1) hard fork: creates a chain split
>> 2) soft fork: creates a chain split
>> 3) 51% attack: does not create a chain split
>> The presumption being that one can never assume 100% explicit adoption of any rule change.
>> A 51% attack can of course fail. It is also possible that signaling can be untruthful. But miner signaling provides some level of assurance that it will be successful. This level of assurance is increased by adoption of a higher than majority threshold, as has been done in the past.
>> Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nobody is in charge.
>> The majority of those who mine can choose to enforce censorship any time they want. They don’t need anyone’s permission. No power is given to them by developers or anyone else. They have that power based on their own capital invested.
>> Similarly, the economy (those who accept bitcoin) can enforce any rule change it wants to. And it can do so at any level of participation that wants to go along. Anyone can do this, it requires nobody’s permission. Furthermore, it is possible for the economy to signal its level of agreement in every transaction, as miners have done in blocks previously.
>> But if the objective is to produce a rule change while avoiding a chain split, 50% is a much lower bar than 100%. If there is some other objective, it’s not clear to me what it is.
>> e
>>>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>>
>>> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced selfish mining" to take advantage of it.
>>>
>>>
>>> Hard to analyze exactly what that looks like, but...
>>>
>>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this for too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving themselves a larger % of hashrate.
>>>
>>> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners leads to some nasty oscillating hashrate being optimal.
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>>>
>>>
>>>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote:
>>>
>>> Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running
>>> Bitcoin
>>> Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3)
>>> from
>>> my original post - it results in any miner who has not taken active action (and ensured every part of their
>>> often-large
>>> infrastructure has been correctly reconfigured) generating invalid blocks.
>>>
>>> As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
>>> already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>>>
>>> Matt
>>>
>>>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>>> > I agree with much of the logic presented by Matt here.
>>> >
>>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a
>>> "tiny"
>>> > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a
>>> concept
>>> > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
>>> > universally understood by all network participants to just have a flag day. It is easier to communicate what users
>>> > should do and when.
>>> >
>>> > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on
>>> its own,
>>> > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain
>>> date are
>>> > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a
>>> cooptable
>>> > consensus process than something more straightforward.
>>> >
>>> >
>>> > That said, a few points strike me as worth delving into.
>>> >
>>> >
>>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days --
>>> one for
>>> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and
>>> flag day
>>> > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV
>>> mining
>>> > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
>>> > ensure the tip is valid).
>>> > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients
>>> would
>>> > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g.,
>>> LOT=true
>>> > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
>>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation
>>> is/was
>>> > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering
>>> schedules,
>>> > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a
>>> quantized
>>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
>>> > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if
>>> signaling does
>>> > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with
>>> start
>>> > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that
>>> secondary
>>> > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
>>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining
>>> reward). So I
>>> > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard
>>> fork if
>>> > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
>>> > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
>>> > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year
>>> flag
>>> > day, to do that via LOT=true so that taproot can still have early activation if desired.
>>> >
>>> > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
>>> > closer to a flag day might not be so bad either for future forks as well.
>>> >
>>> > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best
>>> option
>>> > at this time as it allows our flag day to remain compatible with such an early activation.
>>> >
>>> > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any
>>> future
>>> > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
>>> > parameters).
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-02-28 16:45 [bitcoin-dev] Straight Flag Day (Height) Taproot Activation Matt Corallo
2021-02-28 17:20 ` Luke Dashjr
@ 2021-03-03 14:59 ` Anthony Towns
2021-03-03 16:49 ` Matt Corallo
1 sibling, 1 reply; 15+ messages in thread
From: Anthony Towns @ 2021-03-03 14:59 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
On Sun, Feb 28, 2021 at 11:45:22AM -0500, Matt Corallo via bitcoin-dev wrote:
> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022. Going back to
> my criteria laid out in [1],
The timeout height proposed in:
https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
is block 745920, so bip8/lockinontimeout=true with that param would ensure
activation by block 747936. That's 74,940 blocks away at present, which
would be ~6th August 2022 if the block interval averaged at 10 minutes.
So I think I'm going to treat this as reusing the same parameter, just
dropping the consensus-critical signalling and hence the possibilty
of early activation.
I believe this sort of unsignalled flag day could be implemented
fairly easily by merging PR #19438, adding "int TaprootHeight;" to
Conensus::Params, moving "DEPLOYMENT_TAPROOT" from DeploymentPos
to BuriedDeployment, adjusting DeploymentHeight(), and setting
TaprootHeight=747936 for MAINNET. Might need to add a config param like
"-segwitheight" for regtest in order to keep the tests working.
I think it would be worthwhile to also update getblocktemplate so that
miners signal uptake for something like three or four retarget periods
prior to activation, without that signalling having any consensus-level
effect. That should allow miners and businesses to adjust their
expectations for how much hashpower might not be enforcing taproot rules
when generating blocks -- potentially allowing miners to switch pools
to one running an up to date node, pools to reduce the amount of time
they spend mining on top of unvalidated headers, businesses to increase
confirmation requirements or prepare for the possibility of an increase
in invalid-block entries in their logs, etc.
> 2) The high node-level-adoption bar is one of the most critical goals, and
> the one most currently in jeopardy in a BIP 8 approach.
A couple of days ago I would have disagreed with this; but with Luke
now strongly pushing against implementing lot=false, I can at least see
your point...
Cheers,
aj
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-03-03 14:59 ` Anthony Towns
@ 2021-03-03 16:49 ` Matt Corallo
2021-03-06 11:33 ` Anthony Towns
0 siblings, 1 reply; 15+ messages in thread
From: Matt Corallo @ 2021-03-03 16:49 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
On 3/3/21 09:59, Anthony Towns wrote:
> I think it would be worthwhile to also update getblocktemplate so that
> miners signal uptake for something like three or four retarget periods
> prior to activation, without that signalling having any consensus-level
> effect. That should allow miners and businesses to adjust their
> expectations for how much hashpower might not be enforcing taproot rules
> when generating blocks -- potentially allowing miners to switch pools
> to one running an up to date node, pools to reduce the amount of time
> they spend mining on top of unvalidated headers, businesses to increase
> confirmation requirements or prepare for the possibility of an increase
> in invalid-block entries in their logs, etc.
I strongly agree. Ideally such signaling could be placed in the witness nonce, however this may require pool updates to
ensure pool server software is not assuming the 32-byte-0-nonce in wide use today. It is a worthwhile change in any
case, as it avoids the need to change pool software for future forks which place commitments in the nonce.
>> 2) The high node-level-adoption bar is one of the most critical goals, and
>> the one most currently in jeopardy in a BIP 8 approach.
>
> A couple of days ago I would have disagreed with this; but with Luke
> now strongly pushing against implementing lot=false, I can at least see
> your point...
Right. It may be the case that the minority group threatening to fork off onto a lot=true chain is not large enough to
give a second thought to. However, I'm not certain that its worth the risk, and, as Chris noted in his post this
morning, that approach is likely to include more drama.
Matt
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-03-03 16:49 ` Matt Corallo
@ 2021-03-06 11:33 ` Anthony Towns
2021-03-08 12:51 ` Jorge Timón
0 siblings, 1 reply; 15+ messages in thread
From: Anthony Towns @ 2021-03-06 11:33 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote:
> On 3/3/21 09:59, Anthony Towns wrote:
> > A couple of days ago I would have disagreed with this; but with Luke
> > now strongly pushing against implementing lot=false, I can at least see
> > your point...
> Right. It may be the case that the minority group threatening to fork off
> onto a lot=true chain is not large enough to give a second thought to.
> However, I'm not certain that its worth the risk, and, as Chris noted in his
> post this morning, that approach is likely to include more drama.
I think there's two different interpretations of what a "user-activated
fork" means:
1) if people try to take bitcoin in a direction that risks destroying
it, it's possible to ignore both devs and hashpower entirely and force
a chain split to ensure it's possible to continue transacting with
"the real bitcoin".
2) removing miners' influence over consensus rules entirely -- so that
not only can users overcome miner objections by risking a chain split,
but so that miners don't have any greater ability to object than
anyone else in the ecosystem.
In my opinion, bip8's optional lockinontimeout setting and must-signal
approach is well-designed for case 1; if miners object for good reasons,
then there is no need to override them (if there's a good reason not to do
something, it shouldn't be done!), while still having the possibility to
override them if they object for bad reasons. Because hashpower disagrees,
there's always a risk of a chain split in that case, so the additional
risk introduced by a signalling requirement is pretty minimal. That the
lockinontimeout value is a setting means it can be switched only when
we're sure there aren't good reasons for the objection.
There is a lot of work to be done to make bitcoind have an acceptable
chance of gracefully *surviving* a network split introduced by this sort
of conflict; but provided no one started setting lockinontimeout=true
until we were six or so months into an activation attempt (and hence
had the opportunity to judge whether the reasons for not activating
were bad), that would likely be enough time to start implementing some
safety mechanisms.
But there seems to be much more signficant support for the case 2 than I
expected; as evidenced by the "let's do lockinontimeout=true immediately"
advocacy, eg:
I am not willing to go to war for Taproot. I'll be honest the reason
I'm interested at all is that devs I respect spent a lot of energy and
time on it and I was reluctant to let their marginally beneficial work
go to waste.
I am, however, willing to go to war against LOT=False.
-- https://twitter.com/francispouliot_/status/1363876292169465856
I don't think bip8 is well-designed for that approach: most importantly,
with early adoption of lockinontimeout=true, bip8 *encourages* a consensus
split in the event that good reasons for not activating are discovered
afterwards, because lockinontimeout=false nodes remain able to abandon
the activation attempt. Consensus splits are terrible; they should be
a last resort used only in the event that bitcoin's fundamental nature
is threatened, not a standard risk if bugs happened to be discovered
late. But additionally, if we are worried miners might not be acting
in the interests of all bitcoin users, there are other games they could
play, such as "if you want X activated quickly, also give us Y; otherwise
we'll delay it as long as possible".
Losing the opportunity to abandon an activation attempt, by whatever
mechanism, also puts a lot more pressure on being absolutely sure of the
desirability of the change at the point when it's merged; because miners,
third-party devs, businesses, and users don't even have the option of
attempting to influence miners, all objections needs to be raised when
the activation parameters are merged, which raises the stakes for that
event substantially.
I think my conclusions from that are:
* as it stands, people are expecting to run bip8/lot=true nodes on the
network immediately; so deploying bip8/lot=false with compatible
parameters risks causing consensus splits, and should not be done
* David Harding's "speedy trial" approach probably doesn't suffer from
the problems -- running a lot=true variant would require enforcing
signalling prior to the end of July, which is an unreasonable timeframe
to expect the majority of economic nodes to upgrade in; if bip9 is
used, then the risk of enforcement occuring with minority hashrate
(and thus having fewer retarget periods before the timeout is
reached) would also make a bip148/lot=true variant difficulty
* if people want a "taproot is guaranteed to activate no later than X"
PR merged, someone needs to do a *lot* more outreach to be sure that
that's the right outcome, and it's not just devs/maintainers making
the call
* IMO, Matt's proposed approach is both a better and simpler approach
to avoid giving miners undue influence on consensus; as such I've
drafted up a sample implementation:
https://github.com/bitcoin/bitcoin/pull/21378
(Backporting it to 0.21 just requires backporting #19438, which is
straightforward)
So I think that means my preference is to do the "speedy trial" with
signalling first, and if that fails, then either we've established there
are real problems with taproot and will go back to the drawing board to
fix them, or if we have not found problems by that time we should simply
switch to a straight flag day activation as Matt proposes. Presumably
we'll have established broard community consensus for activation if no
objections are discovered during the speedy trial.
Cheers,
aj
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-03-06 11:33 ` Anthony Towns
@ 2021-03-08 12:51 ` Jorge Timón
2021-03-08 14:13 ` eric
0 siblings, 1 reply; 15+ messages in thread
From: Jorge Timón @ 2021-03-08 12:51 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6813 bytes --]
Concept nack.
This has no advantage over bip8(true).
Bip9(false) is just bip9.
Thr only reasonable argument against bip8(true) is "some people may do
bip8(false) instead", which is a stypid argument applyable to any
activation method.
People against taproot should want code to forbid its activation rather
than limiting themselves to suport bip9/bip8(false) and hope it doesn't get
activated it.
Some other arguments seem to be based on the wrong assumption that miners
should decide the rules.
Thisproposal solves nothing, just adds to the noise and thus is really
disappointing.
On Sat, Mar 6, 2021, 12:33 Anthony Towns via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote:
> > On 3/3/21 09:59, Anthony Towns wrote:
> > > A couple of days ago I would have disagreed with this; but with Luke
> > > now strongly pushing against implementing lot=false, I can at least see
> > > your point...
> > Right. It may be the case that the minority group threatening to fork off
> > onto a lot=true chain is not large enough to give a second thought to.
> > However, I'm not certain that its worth the risk, and, as Chris noted in
> his
> > post this morning, that approach is likely to include more drama.
>
> I think there's two different interpretations of what a "user-activated
> fork" means:
>
> 1) if people try to take bitcoin in a direction that risks destroying
> it, it's possible to ignore both devs and hashpower entirely and force
> a chain split to ensure it's possible to continue transacting with
> "the real bitcoin".
>
> 2) removing miners' influence over consensus rules entirely -- so that
> not only can users overcome miner objections by risking a chain split,
> but so that miners don't have any greater ability to object than
> anyone else in the ecosystem.
>
> In my opinion, bip8's optional lockinontimeout setting and must-signal
> approach is well-designed for case 1; if miners object for good reasons,
> then there is no need to override them (if there's a good reason not to do
> something, it shouldn't be done!), while still having the possibility to
> override them if they object for bad reasons. Because hashpower disagrees,
> there's always a risk of a chain split in that case, so the additional
> risk introduced by a signalling requirement is pretty minimal. That the
> lockinontimeout value is a setting means it can be switched only when
> we're sure there aren't good reasons for the objection.
>
> There is a lot of work to be done to make bitcoind have an acceptable
> chance of gracefully *surviving* a network split introduced by this sort
> of conflict; but provided no one started setting lockinontimeout=true
> until we were six or so months into an activation attempt (and hence
> had the opportunity to judge whether the reasons for not activating
> were bad), that would likely be enough time to start implementing some
> safety mechanisms.
>
> But there seems to be much more signficant support for the case 2 than I
> expected; as evidenced by the "let's do lockinontimeout=true immediately"
> advocacy, eg:
>
> I am not willing to go to war for Taproot. I'll be honest the reason
> I'm interested at all is that devs I respect spent a lot of energy and
> time on it and I was reluctant to let their marginally beneficial work
> go to waste.
>
> I am, however, willing to go to war against LOT=False.
>
> -- https://twitter.com/francispouliot_/status/1363876292169465856
>
> I don't think bip8 is well-designed for that approach: most importantly,
> with early adoption of lockinontimeout=true, bip8 *encourages* a consensus
> split in the event that good reasons for not activating are discovered
> afterwards, because lockinontimeout=false nodes remain able to abandon
> the activation attempt. Consensus splits are terrible; they should be
> a last resort used only in the event that bitcoin's fundamental nature
> is threatened, not a standard risk if bugs happened to be discovered
> late. But additionally, if we are worried miners might not be acting
> in the interests of all bitcoin users, there are other games they could
> play, such as "if you want X activated quickly, also give us Y; otherwise
> we'll delay it as long as possible".
>
> Losing the opportunity to abandon an activation attempt, by whatever
> mechanism, also puts a lot more pressure on being absolutely sure of the
> desirability of the change at the point when it's merged; because miners,
> third-party devs, businesses, and users don't even have the option of
> attempting to influence miners, all objections needs to be raised when
> the activation parameters are merged, which raises the stakes for that
> event substantially.
>
> I think my conclusions from that are:
>
> * as it stands, people are expecting to run bip8/lot=true nodes on the
> network immediately; so deploying bip8/lot=false with compatible
> parameters risks causing consensus splits, and should not be done
>
> * David Harding's "speedy trial" approach probably doesn't suffer from
> the problems -- running a lot=true variant would require enforcing
> signalling prior to the end of July, which is an unreasonable timeframe
> to expect the majority of economic nodes to upgrade in; if bip9 is
> used, then the risk of enforcement occuring with minority hashrate
> (and thus having fewer retarget periods before the timeout is
> reached) would also make a bip148/lot=true variant difficulty
>
> * if people want a "taproot is guaranteed to activate no later than X"
> PR merged, someone needs to do a *lot* more outreach to be sure that
> that's the right outcome, and it's not just devs/maintainers making
> the call
>
> * IMO, Matt's proposed approach is both a better and simpler approach
> to avoid giving miners undue influence on consensus; as such I've
> drafted up a sample implementation:
>
> https://github.com/bitcoin/bitcoin/pull/21378
>
> (Backporting it to 0.21 just requires backporting #19438, which is
> straightforward)
>
> So I think that means my preference is to do the "speedy trial" with
> signalling first, and if that fails, then either we've established there
> are real problems with taproot and will go back to the drawing board to
> fix them, or if we have not found problems by that time we should simply
> switch to a straight flag day activation as Matt proposes. Presumably
> we'll have established broard community consensus for activation if no
> objections are discovered during the speedy trial.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 8410 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
2021-03-08 12:51 ` Jorge Timón
@ 2021-03-08 14:13 ` eric
0 siblings, 0 replies; 15+ messages in thread
From: eric @ 2021-03-08 14:13 UTC (permalink / raw)
To: 'Jorge Timón', 'Bitcoin Protocol Discussion',
'Anthony Towns'
[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]
One should not assume that those trying to avoid a chain split are against Taproot.
There is a concerning widespread misperception in the community at large that soft forks are inherently “backward compatible”. To many people this seems to mean that, even without hash power enforcement, activation will not create a chain split. This is no doubt reinforced by loose wording in past proposals, such as the unqualified, “As a soft fork, older software will continue to operate without modification.” (BIP141). If operating means not crashing, then hard forks also qualify. Many people do not understand that hash power enforcement is also required for a soft fork to avoid a chain split.
This misperception has also been fed by devs who should know better claiming that BIP16 was not signaled by supermajority hash power before it was activated. The only distinction being that an *automated* activation method had not yet been developed. Starting with BIP16 *all active soft forks* have been activated by supermajority hash power signaling. I was told publicly by someone who should certainly know better that SegWit missed its BIP9 activation window and that BIP9 failed. Yet SegWit activated under BIP9 2.5 months before its activation window closed. It never entered its FAILED state and remains in its ACTIVE state (BIP90 being presumed to be merely a code optimization). This type of misinformation is a root cause of much of the conflict.
Yes, some people threatened to split themselves off with BIP148, and yes miners used BIP91 to accelerate SegWit enforcement, preventing that split well before the SegWit the activation window was set to expire. So those people claim BIP9 failed. It’s a false narrative. BIP9 could have failed, but did not. Soft fork activation could be unsupported by miners, but to date no such activation attempt has failed. No doubt it will someday. But why are people picking a fight where there isn’t one.
This should not about who gets to “decide the rules”, but that is exactly what it has become. It’s the only explanation for the conflict. Otherwise there does not appear to be any whatsoever. Miner activation is used if at all possible because it avoids a chain split. It’s as simple as that. Anyone can of course decide what rules they run. But telling them that they can do so without splitting is flatly irresponsible. If it comes to that, inform people properly and let them decide.
The reason for BIP8 is clearly to codify activation without hash power support. You are right that BIP8(LOT=false) is just BIP9. The other differences are immaterial. Given that there are other differences, it seems advisable to use what has already been coded, tested, deployed, and successful in the past. It’s also understandable that many devs no not want to be responsible for shipping code to large numbers of people who are misinformed about its behavior, potentially causing a chain split and loss of both money and faith in the system.
If one needs to consider this a question of who gets to decide, it’s not clear to me why one would side with exchanges over miners given that the latter are able to prevent a chain split. HODLer nodes are non-economic, to the extent they even exist. This isn’t a David vs. Goliath scenario, and even if it was, the supposed giant appears to overwhelmingly support Taproot.
e
From: bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> On Behalf Of Jorge Timón via bitcoin-dev
Sent: Monday, March 8, 2021 4:52 AM
To: Anthony Towns <aj@erisian•com.au>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Concept nack.
This has no advantage over bip8(true).
Bip9(false) is just bip9.
Thr only reasonable argument against bip8(true) is "some people may do bip8(false) instead", which is a stypid argument applyable to any activation method.
People against taproot should want code to forbid its activation rather than limiting themselves to suport bip9/bip8(false) and hope it doesn't get activated it.
Some other arguments seem to be based on the wrong assumption that miners should decide the rules.
Thisproposal solves nothing, just adds to the noise and thus is really disappointing.
[-- Attachment #2: Type: text/html, Size: 6986 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-03-08 14:13 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-28 16:45 [bitcoin-dev] Straight Flag Day (Height) Taproot Activation Matt Corallo
2021-02-28 17:20 ` Luke Dashjr
2021-02-28 17:29 ` Matt Corallo
2021-02-28 19:43 ` Jeremy
2021-02-28 19:51 ` Matt Corallo
2021-02-28 20:02 ` Jeremy
2021-02-28 20:19 ` Eric Voskuil
2021-02-28 20:25 ` Matt Corallo
2021-02-28 20:38 ` Eric Voskuil
2021-02-28 20:20 ` Matt Corallo
2021-03-03 14:59 ` Anthony Towns
2021-03-03 16:49 ` Matt Corallo
2021-03-06 11:33 ` Anthony Towns
2021-03-08 12:51 ` Jorge Timón
2021-03-08 14:13 ` eric
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox