From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B7737C000E for ; Sat, 26 Jun 2021 21:43:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8B2744031E for ; Sat, 26 Jun 2021 21:43:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fninkbIukRQ8 for ; Sat, 26 Jun 2021 21:43:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1F208402BC for ; Sat, 26 Jun 2021 21:43:57 +0000 (UTC) Received: by mail-pf1-x42f.google.com with SMTP id d12so2824973pfj.2 for ; Sat, 26 Jun 2021 14:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=kFSbDilUjBVcCp0BNm7OWi+Ky5C6cdOjmyJD0490v4s=; b=i14hnmVrW0iYNGJ72BTPQ2YvQ0yH9+XkFbQ/VkeflwSqTgFmQpC3PKA+0hhxX7psxF 3ILqj2ORgJMQH5yPXkNaFll7mescpXZaILZSmPn62yvoLK3vIua/aJWXbGQuOOovTJki FngOlDzd/pFBAprMmhbJn4KJqb5f5AHpcOCIeC3LcY5aGM+PFmaRoK4Zkm0ftMppFRn5 Ip/5XMWoqp3pLQHWla3UvsG622ZlU9AgmjF1371brZpmSoI2vihM/zx1jAnHS9GscvQW 9+o2NExbiytY7MX9XRPTHaZakCC8BNFUDbbeR7qeScUMhYL4OhiT+T7KLhyAxs86/2cv dtZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=kFSbDilUjBVcCp0BNm7OWi+Ky5C6cdOjmyJD0490v4s=; b=lQETPIfXPR2cp2Pd4S8dxQiTnWK7uALiYMLt/mDJOI9X89939jaA9TjcaJlgpVgitX SUspW8tbDtGDLFXzbsHXSKQTuZZ+lXeOJjWPt+fVq0aUAk/LLuZRAuExId79c1LX+cRL SqLE3PVWNj/PQxflqy7ziPYT40d7a5RQZJqh6/ms6MExpwZ2dA0KRa8KFv8iBN6J8QSf lmpKxCj2JS2n+G3K/6KfvoMQIRnzKBzOViDsyRWQHYVGNJaS7UdzU7AGPV52HtIWDb1R MSjZmAKhGFSQ6UYDhaMmByFTWgQPhQCy83NbM0jaWW7uxDiN5unNnXpP9l/lgRFqMgkk oMFg== X-Gm-Message-State: AOAM533EyWu8w/Y56hbDD/kUV5izirWp913Hrkrj8PmffPce6K9cUmyD OmWDP9VW9AJqfEfjH/qWWkzKjQ== X-Google-Smtp-Source: ABdhPJzH2UXy/TLuzfsT9stH07Yo1RmD1k5UYR0R0taHamfdWxP34R8Z3+/PuADCn2gINeZQ/KrSAg== X-Received: by 2002:a62:8647:0:b029:302:4642:ae52 with SMTP id x68-20020a6286470000b02903024642ae52mr17077748pfd.7.1624743837322; Sat, 26 Jun 2021 14:43:57 -0700 (PDT) Received: from smtpclient.apple ([2601:600:9c00:1d0::437e]) by smtp.gmail.com with ESMTPSA id y3sm9456358pga.72.2021.06.26.14.43.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Jun 2021 14:43:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Sat, 26 Jun 2021 14:43:55 -0700 Message-Id: References: <202106262113.05006.luke@dashjr.org> In-Reply-To: <202106262113.05006.luke@dashjr.org> To: Luke Dashjr , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (18F72) Cc: Billy Tetrud Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades 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: Sat, 26 Jun 2021 21:43:59 -0000 For some definitions of =E2=80=9Cblock=E2=80=9D. Without majority hash power support, activation simply means you are off on a= chain split. Anyone can of course split off from a chain by changing a rule= (soft or otherwise) at any time, so this is a bit of an empty claim. Nobody can stop a person from splitting. The relevant question is how to *pr= event* a split. And activation without majority hash power certainly does no= t =E2=80=9Censure=E2=80=9D this. e > On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev wrote: >=20 > =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade entir= ely. They can=20 > still slow it down. >=20 > It also already has the trinary state you seem to be describing (although=20= > perhaps this could be better documented in the BIP): users who oppose the=20= > softfork can and should treat the successful signal (whether MASF or UASF)= as=20 > invalid, thereby ensuring they do not follow a chain with the rules in for= ce. >=20 > No additional bit is needed, as softforks are coordinated between users, N= OT=20 > miners (who have no particular say in them, aside from their role as also=20= > being users). The miner involvement is only out of necessity (to set the b= it=20 > in the header, which users coordinate with) and potentially to accelerate=20= > activation by protecting upgrade-lagging users. >=20 > Luke >=20 >=20 >> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote: >> Given the recent controversy over upgrade mechanisms for the >> non-controversial taproot upgrade, I have been thinking about ways to sol= ve >> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue propon= ents >> make the point that lazy miners failing to upgrade in a timely manner slo= w >> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse >> proponents make the point that LOT=3Dtrue can lead to undesirable forks t= hat >> might cause a lot of chaos. I believe both points are essentially correct= >> and have created a proposal >> > ip-trinary-version-bits.md> for soft fork upgrades that solve both proble= ms. >>=20 >> The proposal uses trinary version signaling rather than binary signaling.= >> For any particular prospective soft fork upgrade, this allows for three >> signaling states: >>=20 >> * Actively support the change. >> * Actively oppose the change. >> * Not signaling (neither support or oppose). This is the default state. >>=20 >> Using this additional information, we can release non-contentious upgrade= s >> much quicker (with a much lower percent of miners signaling support). For= >> contentious upgrades, miners who oppose the change are incentivized to >> update their software to a version that can actively signal opposition to= >> the change. The more opposition there is, the higher the threshold >> necessary to lock in the upgrade. With the parameters I currently >> recommended in the proposal, this chart shows how much support signaling >> would be necessary given a particular amount of active opposition >> signaling: >>=20 >> [image: thresholdChart.png] >> If literally no one signals opposition, a 60% threshold should be >> relatively safe because it is a supermajority amount that is unlikely to >> change significantly very quickly (ie if 60% of miners support the change= >> today, its unlikely that less than a majority of miners would support the= >> change a year or two from now), and if no one is signaling opposition, >> chances are that the vast majority of the other 40% would also eventually= >> signal support. >>=20 >> This both gives an incentive for "lazy" miners to upgrade if they actuall= y >> oppose the change while at the same time allowing these lazy miners to >> remain lazy without slowing down the soft fork activation much. >>=20 >> I think now is the right time to discuss new soft fork upgrade mechanisms= , >> when there are no pressing soft fork upgrades ready to deploy. Waiting >> until we need to deploy a soft fork to discuss this will only delay thing= s >> and cause contention again like it did with taproot. >>=20 >> I'm very curious to know what people think of this mechanism. I would >> appreciate any comments here, or written as github issues on the proposal= >> repo itself. >>=20 >> Thanks, >> BT >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev