Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 20F3AC8F for ; Fri, 16 Aug 2019 16:06:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148096.authsmtp.net (outmail148096.authsmtp.net [62.13.148.96]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 677A38A6 for ; Fri, 16 Aug 2019 16:06:57 +0000 (UTC) Received: from punt19.authsmtp.com (punt19.authsmtp.com [62.13.128.203]) by punt18.authsmtp.com. (8.15.2/8.15.2) with ESMTP id x7GG6t9d071147 for ; Fri, 16 Aug 2019 17:06:55 +0100 (BST) (envelope-from user@petertodd.org) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt19.authsmtp.com. (8.15.2/8.15.2) with ESMTP id x7GG6tWU015654; Fri, 16 Aug 2019 17:06:55 +0100 (BST) (envelope-from user@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id x7GG6qMB026941 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 17:06:53 +0100 (BST) (envelope-from user@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 8336540160; Fri, 16 Aug 2019 16:06:52 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id A571F22636; Fri, 16 Aug 2019 12:06:50 -0400 (EDT) Date: Fri, 16 Aug 2019 12:06:50 -0400 From: Peter Todd To: John Newbery , Bitcoin Protocol Discussion Message-ID: <20190816160650.artngylrzy2id5tr@petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r7bp4rsr3tgacgpj" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Server-Quench: dd5278ff-c03f-11e9-b106-8434971169dc X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZIVwkA IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwQUGUATAgsB Am8bWlNeUFt7XGc7 bghPaBtcak9QXgdq T0pMXVMcXAIfdhpA e2weUB97cwQIf3ty YQg2CnVZW0wsI1su Qk0CCGwHMG59OmEf Vl1QcwBQeQRLfxlM PgMxNiYHcQ5VPz4z GA41ejw8IwAXAjlP UwALIho5enhDFzgw DwsPEiouAQUeQCsv ZxIhMF1UFU0NM1s7 LVomX0lw X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Burying CSV and segwit soft fork activations X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 16:06:58 -0000 --r7bp4rsr3tgacgpj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrot= e: > Once a consensus change has been activated and buried by sufficient work, > we consider the height of that change to be historic fact. The exact > activation method is no longer of practical interest. In some cases the > cause of activation is not even decidable. For example, we know that segw= it > activated at height 481,824 but it's debatable whether that was due to BIP > 9 version bits signaling, BIP 148 UASF, or a combination of the two. I just wanted to elaborate on this excellent point: This is debatable because Bitcoin is a decentralized, soft-forks are backwa= rds compatible, and it's very difficult if not impossible to measure the preferences of economically significant nodes. Both the BIP9 version bits signalling and the BIP 148 UASF had the same basic effect: enforce segwit. Furthermore, the BIP 148 UASF rejected blocks that didn't signal via the BI= P9 version bits. We can observe the fact that 100% of known blocks produced after Aug 1st 20= 17 have complied with segwit rules, and the BIP9 signalling protocol for segwi= t. But strictly speaking we don't really know why that happened. It's possible that miners were running the BIP9 signalling Bitcoin Core release around th= at time. It's also possible that miners were running UASF enforcing software. It's possible there was a combination of both. Or even entirely different software - remember that some miners produced segwit-valid blocks, but didn= 't actually mine segwit transactions. Each scenario leads to the same external= ly observable outcome. Furthermore there's the question as to why miners were producing segwit-compliant blocks: perhaps they thought the vast majority of economic= ally significant nodes would reject their blocks? Perhaps they just wanted to enforce segwit? These are all questions that have plausible answers, backed by evidence and argument. But because Bitcoin is a decentralized network no authority can t= ell you what the answers are. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --r7bp4rsr3tgacgpj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAl1W1JYACgkQJIFAPaXw kfuxZQf/V3q0ENJ3jzNNjikeZr1+Wq4da/q4B0NjGkqtBmFRa2YaG2G7DXtNBWKJ 0MEwXm2jY2rcXaK3AAK29Qqjgw0Q48uAmGew8mI9jls/scH34Kh5cdK9fFvdOJ3b 4IxjIwnINUDUFiguc4B74O23QIewejGg8UXP+A5kPlMiBXDkXP9E56lbxr2a6Uz8 vf5VHGz/VUyNeyah5Rnpok6xb5TySiAe0V556QXM6l78yZEZ9yjQRlBvBg19H5Sz PjJihAfMa7CqyvUVFzP9uqkVSoMdDEt/Xovj4evCObRc+/RQ2ev3H+o1LwsYzDYX dACWpqt6vC7t1tGDkxqguyycrWL7HQ== =E09C -----END PGP SIGNATURE----- --r7bp4rsr3tgacgpj--