From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C31BBC077D for ; Thu, 16 Jan 2020 03:46:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id B9F9620468 for ; Thu, 16 Jan 2020 03:46:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz3HY0Z1V8Mq for ; Thu, 16 Jan 2020 03:46:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by silver.osuosl.org (Postfix) with ESMTPS id 9ACC82045B for ; Thu, 16 Jan 2020 03:46:27 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1irw6w-0001Ns-61; Thu, 16 Jan 2020 13:46:24 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 16 Jan 2020 13:46:17 +1000 Date: Thu, 16 Jan 2020 13:46:17 +1000 From: Anthony Towns To: Matt Corallo Message-ID: <20200116034617.zgkvtub55phdtxap@erisian.com.au> References: <20200111144207.5xzspeptstspsbsf@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Modern Soft Fork Activation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 03:46:28 -0000 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