From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1FEFC002C for ; Thu, 21 Apr 2022 13:11:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A9A4561350 for ; Thu, 21 Apr 2022 13:11:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItbkFg1TVcrT for ; Thu, 21 Apr 2022 13:10:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9935F61335 for ; Thu, 21 Apr 2022 13:10:58 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id d6so8602961lfv.9 for ; Thu, 21 Apr 2022 06:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EJSEuqwSixoDayUYcZKgRyMQvynTVRaZdB1mdm05LUc=; b=XoqS/l7AGlXezM+a/iAcrEkLAkw2jaVq2P82DWA1Pq2Magouh7rSvQGaczqeVGF0ME ox6oFJCKer82ULhEMcTtgun+gcoFvHpFfcdA54+2HaMKPcZCf2wAFVnRxrP5zxocaI+F Ksqa/E9xFxNw6ktR8lgrVW5h6qkWS9UmmuPjwQ0z8kLPauL6C2FU2tKjB6QuKdOVxiR3 XbbxddubKSOWK2/jPXuwSUmqDRx6DIqV/w1+hd7vKxEE4kxCl2CLcj4ZY1BLxkSMmgq5 Ph1UBycvWnVxWHN2Yuw2oaBHkxDMLc34rQS1SVgNsZgcujKdBwJxmSQFgvGhonXY66yP +wSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EJSEuqwSixoDayUYcZKgRyMQvynTVRaZdB1mdm05LUc=; b=P8LSdVik2wJJor3OStHgyZj2Lnc00FRv8BZjcK7BoWNSqKiYDHx+nQM4Wm3OXND2V5 a1F9O+BuI9QouaKN3MpbGa80+wud78V69GML85fissbi+d+FYm3C+8Cw4Qdn8z4ngX6c JihSxwlIyWPUkDpk2+2FYPrtkgajNHR+MSx8Oydby1sw2wpGe2DxnYD2ZDYEQjDg8/wx 5x8E2pdS9UItd+sLEAOV1I2P/dGIHM3mdZlppowxGnhD0woL1EikZj+YZ7SfOVM/67tW d/rvcQhsGuxrjKIaS/omeLzXRBO9akpHdrmNmgE9X0ALusk1hbhdvYhQmEVSqp6tvpeM A6qg== X-Gm-Message-State: AOAM533/WK/Llr9GihAtgoCJ5KWRHsjprz3ddAORTrKJTPSp/1YscPni ox7RiJxB/UCAbu/EgyEQrAH7QEl4zP3EFJsNOO4= X-Google-Smtp-Source: ABdhPJzVkGZhkz/bgia4OfXS8OiAj3p6C6z66CsIRG96puYCvlYBOBGtmkNqjDEddz/uObky11sPwmtLoA44wj0yIIA= X-Received: by 2002:a05:6512:1112:b0:471:a77b:abe6 with SMTP id l18-20020a056512111200b00471a77babe6mr9425162lfg.262.1650546656377; Thu, 21 Apr 2022 06:10:56 -0700 (PDT) MIME-Version: 1.0 References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> <202204210556.54781.luke@dashjr.org> <202204210637.44581.luke@dashjr.org> In-Reply-To: <202204210637.44581.luke@dashjr.org> From: Jeremy Rubin Date: Thu, 21 Apr 2022 08:10:45 -0500 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="000000000000237d4a05dd29d7e1" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV 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, 21 Apr 2022 13:11:00 -0000 --000000000000237d4a05dd29d7e1 Content-Type: text/plain; charset="UTF-8" > You'd be confiscating your own funds by making an absurd spending condition. > By this argument, ALL softforks would have to be ruled out. The argument is that transactions which can be relayed and in the mempool and then confirmed should not ever be restricted. This is so that old node's mempools don't produce invalid blocks after an upgrade. This is what a good chunk of policy is for, and we (being core) do bounce these txns to make clear what might be upgraded. Changing the detail you mentioned represents a tweak that could make old nodes mine invalid blocks. That's all I'm ruling out. > > In preparing it I just used what was available in Core now, surely the > last > > year you could have gotten the appropriate patches done? > > They were done, reviewed, and deployed in time for Taproot. You personally > > played a part in sabotaging efforts to get it merged into Core, and > violating > the community's trust in it by instead merging your BIP9 ST without > consensus. Don't play dumb. You have nobody to blame but yourself. > Even if I accept full responsibility for BIP9 ST without consensus, you still had the last year to convince the rest of the maintainers to review and merge your activation code, which you did not do. Don't confuse consensus-seeking with preference. My preference was to leave versionbits entirely. Nor am I blame seeking. I'm simply asking why, if this is _the_ most important thing for Bitcoin (as I've heard some BIP8 LOT=true people remark), did you not spend the last year improving your advocacy. And I'm suggesting that you redouble those efforts by, e.g., opening a new PR for Core with logic you find acceptable and continuing to drive the debate forward. None of these things happen without advocacy. --000000000000237d4a05dd29d7e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0You'd be confiscating your own funds by making an a= bsurd spending condition.
<= span style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">&= gt; By this argument, ALL softforks would have to be ruled out.

The argument is that transactions=C2=A0which=C2=A0can be relayed an= d in the mempool and then confirmed should not ever be restricted.

This is so that old node's mempools don't produce invalid block= s after an upgrade.

This is what a good chunk of policy is for,= and we (being core) do bounce these txns to make clear what might be upgra= ded.

Changing the detail you mentioned represents a tweak that = could make old nodes mine invalid blocks. That's all I'm ruling out= .

=C2=A0
> In preparing it I just used what was a= vailable in Core now, surely the last
> year you could have gotten th= e appropriate patches done?

They were done, reviewed, and dep= loyed in time for Taproot. You personally=C2=A0
played a part in sabotaging efforts to get it me= rged into Core, and violating= =C2=A0
the community's trust in it by instead merging your BI= P9 ST without=C2=A0
c= onsensus. Don't play dumb. You have nobody to blame but yourself.


Even if I accept full responsibility for BIP9 ST without consensus, you s= till had the last year to convince the rest of the maintainers to review an= d merge your activation code, which you did not do.

Don't c= onfuse consensus-seeking with preference. My preference was to leave versio= nbits=C2=A0entirely.

Nor am I blame seeking. I'm simply ask= ing why, if this is _the_ most important thing for Bitcoin (as I've hea= rd some BIP8 LOT=3Dtrue people remark), did you not spend the last year imp= roving your advocacy. And I'm suggesting that you redouble those effort= s by, e.g., opening a new PR for Core with logic you find acceptable and co= ntinuing to drive the debate forward. None of these things happen without a= dvocacy.
--000000000000237d4a05dd29d7e1--