path: root/a8/30f0ea00ba00ec0062ef2d8021a81830a5c2fc

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C1FEFC002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 13:10:58 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id d6so8602961lfv.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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>
 <CAD5xwhjGzWDw=dunVM5ZW8OvYCHb6xsXBw-ecwx6WAQq84sx5w@mail.gmail.com>
 <202204210637.44581.luke@dashjr.org>
In-Reply-To: <202204210637.44581.luke@dashjr.org>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Thu, 21 Apr 2022 08:10:45 -0500
Message-ID: <CAD5xwhikFoDMhA12f3FFQgrs9BSTN2+8Zk=hYHcQ8UjYok852g@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="000000000000237d4a05dd29d7e1"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">&gt;=C2=A0<span style=3D"font-family:Arial,Helvetica,sans-serif;c=
olor:rgb(34,34,34)">You&#39;d be confiscating your own funds by making an a=
bsurd spending condition.</span></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><=
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.</span></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)">The argument is that transactions=C2=A0which=C2=A0can be relayed an=
d in the mempool and then confirmed should not ever be restricted.</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">This is so that old node&#39;s mempools don&#39;t produce invalid block=
s after an upgrade.</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">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.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">Changing the detail you mentioned represents a tweak that =
could make old nodes mine invalid blocks. That&#39;s all I&#39;m ruling out=
.</div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-i=
m" style=3D"color:rgb(80,0,80)">&gt; In preparing it I just used what was a=
vailable in Core now, surely the last<br>&gt; year you could have gotten th=
e appropriate patches done?<br><br></span>They were done, reviewed, and dep=
loyed in time for Taproot. You personally<span class=3D"gmail-Apple-convert=
ed-space">=C2=A0</span><br>played a part in sabotaging efforts to get it me=
rged into Core, and violating<span class=3D"gmail-Apple-converted-space">=
=C2=A0</span><br>the community&#39;s trust in it by instead merging your BI=
P9 ST without<span class=3D"gmail-Apple-converted-space">=C2=A0</span><br>c=
onsensus. Don&#39;t play dumb. You have nobody to blame but yourself.<br></=
blockquote><div><br></div><div><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">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.</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Don&#39;t c=
onfuse consensus-seeking with preference. My preference was to leave versio=
nbits=C2=A0entirely.</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">Nor am I blame seeking. I&#39;m simply ask=
ing why, if this is _the_ most important thing for Bitcoin (as I&#39;ve hea=
rd some BIP8 LOT=3Dtrue people remark), did you not spend the last year imp=
roving your advocacy. And I&#39;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.</div></div></div>

--000000000000237d4a05dd29d7e1--