From: Anthony Towns <aj@erisian•com.au>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Modern Soft Fork Activation
Date: Thu, 16 Jan 2020 13:46:17 +1000 [thread overview]
Message-ID: <20200116034617.zgkvtub55phdtxap@erisian.com.au> (raw)
In-Reply-To: <a7fc5d7f-9b11-ed8e-0513-fd863881290e@mattcorallo.com>
On Tue, Jan 14, 2020 at 07:42:07PM +0000, Matt Corallo wrote:
> Thus, part of the goal here is that we ensure we have that "out", and
> can observe the response of the ecosystem once the change is "staring
> them in the face", as it were.
> A BIP 9 process is here not only to offer
> a compelling activation path, but *also* to allow for observation and
> discussion time for any lingering minor objections prior to a BIP 8/flag
> day activation.
One thing that I wonder is if your proposal (and BIP9) has enough of
time for this sort of observation?
If something looks good to devs and miners, but still has some
underlying problem, it seems like it would be pretty easy to for it
to activate quickly just because miners happen to upgrade quickly and
don't see a need to tweak the default signalling parameters. I think
the BIP 68/112/113 bundle starttime was met at block 409643 (May 1,
2016), so it entered STARTED at 411264 (May 11), was LOCKED_IN at 417312
(June 21), and active at 481824 (July 5). If we're worried people will
only seriously look at things once activation is possible, having just
a month or two to find new problems isn't very long.
One approach to improve that might be to have the first point release that
includes the soft-fork activation parameters _not_ update getblocktemplate
to signal the version bit by default, but only do that in a second point
release later. That way miners could manually enable signalling if there's
some reason to rush things (which still means there's pressure to actually
look at the changes), but by default there's a bit of extra time.
(This might just be a reason why people should look at proposals before
they're ready to activate, though; or why users of bitcoin should also
be miners)
> On the other hand, in practice, we've seen that version bits are set on
> the pool side, and not on the node side, meaning the goal of ensuring
> miners have upgraded isn't really accomplished in practice, you just end
> up forking the chain for no gain.
ITYM version bits are set via mining software rather than the node
software the constructs blocks (when validation happens), so that
there's no strong link between signalling and having actually updated
your software to properly enforce the new rules? I think people have
suggested in the past moving signalling into the coinbase or similar
rather than the version field of the header to make that link a bit
tighter. Maybe this is worth doing at the same time? (For pools that
want to let their users choose whether to signal or not, that'd mean
offering two different templates for them to mine, I guess) That would
mean miners using the version field as extra nonce space wouldn't be
confused with upgrade signalling at least...
(I don't have an opinion on whether either of these is worth worrying
about)
Cheers,
aj
next prev parent reply other threads:[~2020-01-16 3:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-10 21:30 Matt Corallo
2020-01-10 22:21 ` Jorge Timón
2020-01-10 22:43 ` Matt Corallo
2020-01-10 23:07 ` Jorge Timón
2020-01-10 23:37 ` Luke Dashjr
2020-01-11 0:54 ` Jeremy
2020-01-14 19:22 ` Matt Corallo
2020-01-11 14:42 ` Anthony Towns
2020-01-12 5:58 ` Luke Dashjr
2020-01-14 19:42 ` Matt Corallo
2020-01-16 3:46 ` Anthony Towns [this message]
2020-01-13 8:34 Yosef
2020-01-14 3:20 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200116034617.zgkvtub55phdtxap@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox