> I don't think we should have a followup deployment start so close to to
timeout of ST. I think it would be better to schedule the followup
around ST, especially since the details around that are fuzzier and
dependent on the results of ST itself.
Until Core pull request(s) are merged I don't
I don't think we should have a followup deployment start so close to to
timeout of ST. I think it would be better to schedule the followup
around ST, especially since the details around that are fuzzier and
dependent on the results of ST itself.
That being said, I'm not opposed to moving
The last period before timeoutheight here overlaps with the current BIP8(True)
deployment plan. So if this period specifically were to reach 90% signalling,
nodes would activate Taproot at height 697536, but ST-only nodes would still
wait until 709632 instead.
Probably the best solution is to
The assumption of malice on the part of those of us supporting a UASF is
tragic and frankly ridiculous. Many of us backed off of the effort the
second that this Speedy Trial solution was proposed in order to dislodge
the gridlock on the LOT value. I can't say for certain that 100% of those
working
On 3/6/21 14:56, Michael Folkson wrote:
Hi Matt
> 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
I don't think anyone is proposing anything to "prevent" other people from doing anything they wish. My understanding of
the goal of this proposal, itself, was to keep the community together by proposing a solution that was palatable to all.
My point was that I'm not sure that this proposal
On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoin-dev
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
Hi Matt
> 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
On Sat, Mar 06, 2021 at 01:11:01PM -0500, Matt Corallo 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.
I oppose designing activation mechanisms with the goal of preventing
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
Hi Andrew,
This is a slight misunderstanding of the proposal. Rather than an extended
lockin period (a term I've erroneously used in the past) it is really a
minimum activation height.
Thus using your figures it would instead be:
* start height = 681408 /* about May 1st */
* timeout height =
The most sensible approach I’ve seen yet.
e
> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev
> wrote:
>
> On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev
> wrote:
>> ## Example timeline
>> - T+0: release of one or more full nodes with activation code
>> -
On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev
wrote:
> ## Example timeline
> - 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
I like this idea.
In terms of actual parameters, I propose that we base this Speedy Trial
off of BIP 8 with the following parameters:
* start height = 681408
* timeout height = 695520
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)
For the extended lockin
Thank you for resurfacing and collating this concept.
At this time I don't see major issues with this course of action and think
it represents not only a reasonable compromise between all different
perspectives, but also gives us an opportunity to learn more about less
'slow' yet safe consensus
15 matches
Mail list logo
