From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id BE37BC000D for ; Mon, 11 Oct 2021 16:03:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9F949816F5 for ; Mon, 11 Oct 2021 16:03:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr3vduknJoKP for ; Mon, 11 Oct 2021 16:03:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5C6E680F6D for ; Mon, 11 Oct 2021 16:03:19 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 2C34EFBF84C; Mon, 11 Oct 2021 16:03:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1633968196; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=6Bc+MgE51oNetFwTsgk8RZuN96t1TSCobbsWhCXNdf4=; b=Q70M/0YEF7CH/XJAiJjgXkEHVEEz63hvsx+Hdbt4GqOZ4jvr+TUnvgf6T/ZH7xs6 eprK6Qj15p21fPgUVsonAmxojIOndeB2MbFJxUk7y+5gp2PwaDiRqhpi+lWQllpROFS MPS72HUrFGp8aUcE25SSeG/a6ho18g+H4Sqj7wG0MnWnAsMNNPfKDSol5B2gRFMfjcr 729Qh/z4iNRELsrMY+mk2ALvZJ2O+R1JoT/DwPVCRNjzl+BjmSfJPyusHBBrF1y9/da rT2jDUoX45v52X2SCAdk/D+IHYcVF1rKuQAYsUM5nYbqEZSuKJB/ly2sKaH6AbfFTcD avjohN0nrg== Date: Mon, 11 Oct 2021 18:03:16 +0200 (CEST) From: Prayank To: Michael Folkson Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1360451_2137504804.1633968196164" X-Mailman-Approved-At: Tue, 12 Oct 2021 15:34:37 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] On the regularity of soft forks 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: Mon, 11 Oct 2021 16:03:21 -0000 ------=_Part_1360451_2137504804.1633968196164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Michael, Agree with almost everything. > Miner signaling is a tool for signaling readiness. It is not voting for the soft fork or expressing support for the soft fork. There should not be any attempt to facilitate miner signaling until there is sufficient community consensus (the mining community is a subset of the community) on the soft fork. This is really important which gets ignored. I wish there was a way to solve this problem in a way that it is not misinterpreted by users. During signalling for taproot, there were lots of users in different communities that believed miners are voting for taproot and we need some percentage of miners to agree before making any changes in Bitcoin. It was not just non-technical users but few mining pools, exchanges etc. also considered miners signaling as some voting process. Best I could do at that moment was share this link: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/ However I am sure there are lot of people who still think miners vote during signaling. Opinions of few developers on MASF vs UASF also adds more confusion to this thing. I could not think of any solution to solve this problem. -- Prayank A3B1 E430 2298 178F ------=_Part_1360451_2137504804.1633968196164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

Agr= ee with almost everything.

> Miner signaling is a tool for signaling readiness. It is not vo= ting for the soft fork or expressing support for the soft fork. There shoul= d not be any attempt to facilitate miner signaling until there is sufficien= t community consensus (the mining community is a subset of the community) o= n the soft fork.

Th= is is really important which gets ignored. I wish there was a way to solve = this problem in a way that it is not misinterpreted by users.

During signalling for taproot, th= ere were lots of users in different communities that believed miners are vo= ting for taproot and we need some percentage of miners to agree before maki= ng any changes in Bitcoin. It was not just non-technical users but few mini= ng pools, exchanges etc. also considered miners signaling as some voting pr= ocess.

Best I could = do at that moment was share this link: https://bitcoin.stackexchange.com/qu= estions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/

However I am sure there are lot of people who still think m= iners vote during signaling. Opinions of few developers on MASF vs UASF als= o adds more confusion to this thing. I could not think of any solution to s= olve this problem.

--
= Prayank

A3B1 E430 2298 178F
------=_Part_1360451_2137504804.1633968196164--