path: root/bb/0fca58e9c4b1e624c2a0e27c3b382c583390db

Return-Path: <0xb10c@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 00391C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Nov 2021 17:29:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id D0D4980F3E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Nov 2021 17:29:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.216
X-Spam-Level: 
X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 NICE_REPLY_A=-0.117, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.com
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 eImxg57PVXDp
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Nov 2021 17:29:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [IPv6:2a00:1450:4864:20::42f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 8F34A8104C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Nov 2021 17:29:57 +0000 (UTC)
Received: by mail-wr1-x42f.google.com with SMTP id o13so5513299wrs.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Nov 2021 09:29:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:references:from:subject:message-id:date:user-agent:mime-version
 :in-reply-to:content-transfer-encoding:content-language;
 bh=VniVdolbCLGBpZkkhGhlyAX9Sh7y8FXD+YMiuPhhPwo=;
 b=aHqjTIWqZnhs3BD5ehsc2LxNz8b8KnSuiBh1eO7CRT7yfv0a+fzi68bWlZur/V/++I
 TcgajvnhVRk+wMMuQNhZrWq441Jo+Ua6hLl6UrNs/QHbP7B1RLoezOzd3Sx8XJBbkC+Y
 BlHKmMB2bTCq2giFbYnuCRskjr8OGp5dfOKxwWRHNT8Ed/Aq9MT78fowT2hFNGZ74KpM
 Mj027vYlrtT+iViJPesPeloxBaQMywpmsWDMqgQskiP4Yog5sS44h0bc6v0JaI4WPfYo
 oRgvJPAbHHkzznvbIG4iBjhXaCnRvtuPVKXzIcSNjr5YiB+II90Fan+z0KJtvgIMaGJV
 +caw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:to:references:from:subject:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding
 :content-language;
 bh=VniVdolbCLGBpZkkhGhlyAX9Sh7y8FXD+YMiuPhhPwo=;
 b=dXEr8LCgzJIuH2g7izcMdZFjRsu9YqFGtx5NEUJJPBxUzE31ypmO0Mu83eU7Hl5x/U
 s68FGjnvfa1Kp7WMdXYWylxDyJLb71FcXOPnjb04iWoYu1sOV/WUqyzOt8uHGWSI4XXU
 3uezbVSgaDtPLOCinNz0FdDBDJM3i7H+nMrC/7Hh8mAPln8fWN7ErD1RQPunmTwB0DhF
 +b+T9v/BapLhWa/6MiiQtOuxlEI+Hn0NdC/vNI0n0GElofH1qY56FJOK4vlERoM4ITg2
 NNjFQYkhYbmrszciHjhpS1uDOFHYWqkopdJYcVESFzQEj57o2iPeKpeEYMM+OnacVTkp
 OoNQ==
X-Gm-Message-State: AOAM532M358dM1nsUvP5rZHh3XzhRUsKM1cKNG+YNlkbhkrqwqd13afn
 EC0EZwyLSfwsFzpgW8/RoyZfj80SXsYDaw==
X-Google-Smtp-Source: ABdhPJyPftsE8yDnBbKWFbuZ0H+o/BeNS8GeIFBC3QU2LUv5RRxLv+2KKnPpGb3Ts99NneY0olYv1A==
X-Received: by 2002:adf:f5ce:: with SMTP id k14mr20558117wrp.100.1637774995492; 
 Wed, 24 Nov 2021 09:29:55 -0800 (PST)
Received: from [192.168.178.28] (fttx-pool-157.180.218.113.bambit.de.
 [157.180.218.113])
 by smtp.gmail.com with ESMTPSA id p12sm606738wrr.10.2021.11.24.09.29.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 24 Nov 2021 09:29:55 -0800 (PST)
To: Michael Folkson <michaelfolkson@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 alejandro@pow.energy
References: <HaQ-hY5Xi9DebQ3qteJXbi48IY8ojYlMWXeYrWcEFiKuy31TKY7lNAc42rTb2Sf_FMyhgCz9vp-cf8y-fVpFZ6XtWuR-sBsox1lOoSeGtxQ=@protonmail.com>
From: 0xB10C <0xb10c@gmail.com>
Message-ID: <b6046d93-d8d1-bef4-5ed8-97f95b9f9e0d@gmail.com>
Date: Wed, 24 Nov 2021 18:29:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <HaQ-hY5Xi9DebQ3qteJXbi48IY8ojYlMWXeYrWcEFiKuy31TKY7lNAc42rTb2Sf_FMyhgCz9vp-cf8y-fVpFZ6XtWuR-sBsox1lOoSeGtxQ=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Mailman-Approved-At: Wed, 24 Nov 2021 17:41:16 +0000
Subject: Re: [bitcoin-dev] Taproot activates - A time/block line
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: Wed, 24 Nov 2021 17:29:59 -0000

Thanks, Michael, for writing this up. I agree that it's good to archive
events like, for example, soft-fork activations in an ML post.

All bigger pools have now included multiple P2TR spends in their blocks.
I have a few comments on what happened at F2Pool and to some extend also
at AntPool. These were pool number three and pool number five to signal
taproot readiness. I'm not affiliated with them but was happy to help
F2Pool out and return the favor[1] when they asked for help debugging
why they don't include P2TR spends. I have the permission to share some
pool internals and hope this can help make future soft-forks even smoothe=
r.

Please take my comments with a grain of salt. On the one hand, it could
be that I'm naive in believing what the pools have told me in private
communication. On the other hand, I'm not as marked from the blocksize
war as others might be.


On 11/15/21 3:42 PM, Michael Folkson via bitcoin-dev wrote:
> [..]
>
> Block 709632: The first block where full nodes started enforcing
> Taproot rules was mined by F2Pool. It seems [2] F2Pool wasn=E2=80=99t
> enforcing Taproot rules and did not include any Taproot spends (some
> with high fee rates) in this block. [..] but it does lead to
> discussions for a later time on whether Speedy Trial signaling was
> effective if some mining pools signaled readiness months previous but
> then did not enforce the new soft fork rules on activation.
>
> Block 709633: Mined by AntPool. Similar to F2Pool they didn=E2=80=99t i=
nclude
> any Taproot spends in this block and one would assume that they also
> weren=E2=80=99t enforcing Taproot rules though this has not been confir=
med.
>
> Block 709634: Also mined by AntPool.
>
> Block 709635: The first block which included (numerous) valid Taproot
> spends (and no invalid Taproot spends) was mined by Foundry USA.
>
> [..]
>
> [1]: https://b10c.me/blog/007-spending-p2tr-pre-activation/
> [2]: https://twitter.com/satofishi/status/1459868549674065926
> <https://twitter.com/satofishi/status/1459868549674065926?s=3D20>
>
> [..]

While F2Pool responded they "Will upgrade soon" [2] to my question if
they haven't upgraded their nodes yet, I think they were primarily
buying time as they them-self weren't sure what the issue is. "We are
looking into it" could have been a better and more fitting response.

An F2Pool engineer reached out on the 16th (two days after activation),
mentioning they had been running Bitcoin Core v0.21.1 for a few weeks
now and upgraded to v22.0 today (on the 16th) in the hope that this
would fix their problem of not including P2TR spends. They asked if I
could create and _not_ broadcast a P2TR spending transaction for them to
check with testmempoolaccept/sendrawtransaction/getblocktemplate.

I constructed and sent a P2TR spend and asked them to check the versions
of their nodes peers too. testmempoolaccept returned "allowed": true
(expected as they were running >=3D v0.21.1). However, it turned out that=

they weren't connected to any P2TR-spend-relaying peers. They didn't
receive any P2TR spending transaction and couldn't include them in their
block templates. It seems like this was caused by a) using addnode to
directly connect to known, external peers that hadn't upgraded. But more
importantly, b) by applying a custom patch to their node's peer
selection behavior based on a heuristic that worked for a few years but
at some point broke without being noticed (I'm not publishing details on
purpose). F2Pool has fixed this. With connections to >=3D v0.21.1 nodes,
they started receiving and constructing blocks with P2TR spends.

I haven't been in contact with AntPool directly and don't know details
about their situation. Alejandro De La Torre (@bitentrepreneur)
communicated with them and said I can include the following:

"I spoke with antpool after I noticed from b10c=E2=80=99s tweet that they=
 had
not included P2TR [spends]. They were quick to react when I inquired.
They had not updated to bitcoind 22.0, but had tested it and were
planning to update soon. The next day they indeed updated and were able
to include a tx with a P2TR spend."

and

=C2=A0"[Anpool] said that the old peer issue that F2Pool faced 'may be th=
e
issue'."

AntPool didn't provide more information to Alejandro. It's not clear to
me what the actual issues and fixes were.


I'll leave it to someone else to properly reflect on speedy trial. I,
however, want to add: F2Pool mentioned that they "upgraded to v0.21.1
several weeks ago". This indicates that they were signaling without
being ready. I don't blame them and assume they were not the only pool
just setting the version bit. IMO some of the motivations for fake
signaling: a) Immense community pressure (e.g., on Twitter) to just set
the bit and then get ready in the next six months. b) Running nodes with
custom patches. These require longer to upgrade, especially if you want
to ensure there aren't any bugs in your patches...


It's out of the scope of the Bitcoin Core project to consider people's
custom patches, and it's impossible if they are unpublished. In this
particular case, upstreaming the patch does not make sense.

However, with only just above 50% of taproot nodes[3] (more than a week
after activation), there might still be motivation for having a feature
(sometime before the next soft-fork) to alert/warn a node operator if
his node does not have any peers relaying soft-fork X transaction.
Should PROTOCOL_VERSION be bumped to show support for soft-fork
transaction relay? Or does a service flag for relay makes sense (it
seems complicated to decommission service flags reliably)? Parsing the
subver (e.g. "/Satoshi:0.21.1/") doesn't make sense as there are not
only Bitcoin Core nodes on the network. Could there be a message that is
exchanged between two nodes to indicate soft-fork readiness?

How a node operator can be alerted, besides logging, is an
implementation detail of Bitcoin Core. Maybe a getnodealerts RPC that a
node operator can hook up to his monitoring?

Additionally, for the next soft-fork where relay is affected,
instructions for mining pool signaling could state: "Upgrade to version
Z and make sure you have a few version Z peers before starting to signal
readiness".

Thanks,
0xB10C

[3] http://azure.erisian.com.au/~aj/taproot/taproot.html