Date: Thu, 16 Jan 2020 13:46:17 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <20200116034617.zgkvtub55phdtxap@erisian.com.au>
References: <20200111144207.5xzspeptstspsbsf@erisian.com.au>
 <a7fc5d7f-9b11-ed8e-0513-fd863881290e@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a7fc5d7f-9b11-ed8e-0513-fd863881290e@mattcorallo.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Modern Soft Fork Activation
Precedence: list

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