path: root/ff/1b26edb0056f5bca3e1e13b67c18381cf3c203

Delivery-date: Mon, 10 Feb 2025 13:23:38 -0800
Received: from mail-oi1-f189.google.com ([209.85.167.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDML5DFJWQEBBUG4VG6QMGQETRCP2VQ@googlegroups.com>)
	id 1thbFg-0000QM-Ss
	for bitcoindev@gnusha.org; Mon, 10 Feb 2025 13:23:38 -0800
Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-3f3ad83609asf1882507b6e.1
        for <bitcoindev@gnusha.org>; Mon, 10 Feb 2025 13:23:37 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1739222611; cv=pass;
        d=google.com; s=arc-20240605;
        b=OouIIJqsqIPI6gRHEQlGWmpARNwSnLTzecDpaGug4343KTW6BVhpfxjCi5i43esSjO
         Z6QsrMZsBLTuemv4DhzBNCSBvsqedpy/irnwsGqE42bfwsPuvvGc83KnPTLt6a4+mmTM
         YbCQ8ea+snOG69pULlkYao9AFtRVH0mdKq3CsdzQncsvENGPa1pbzi9XPr2qkax2r213
         9XNO+ByFv/dxJb9hx8EId6JTrVmzM43Fylvb1WEkJoO2ZbsfXD3asJ9DlV5LbBdFSDw3
         nTDOpGyVmC51g8EpMg3eqjUl0TddxBb9dtXG2vmmLCp4x7XJ2lnWh8sW+bCd0xZFmxl/
         bVcA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=8hxl1qhpLJ3Efs69kHsma6+g4OP8TBml88Q49l3bq8o=;
        fh=TDAGZaFg54Bh1UOJxbi1fwz2KMCjgphfxiiL3HPhwRI=;
        b=Qo/FqoGISsRkLDwfle0vWA0SD3wOLxldgeHqHTVyCpfg+pq+XHiiUuzq30lC3scik5
         Lq5UGF2iW9LhaoaASZuhkb4gmFNV0vFYI0vWjrv9RoT+6YA45KbKyoIKtcWDdKaI4OaB
         dkMUQw+AQZalPrBqvfM9VQ8edPfcElqAVgUKRrgU3A9FxD4BHiHeVxhnNhgAJ5xJWqX2
         qGpS9Oi3FqLnavg5B9YEIOIi2V/SGSMj9GnU0c8MKyic5V6wEpr+NIljQDevhcuC84KQ
         tgvwSFZH9IF15+uEBMaV1lmaPK6/XzU5ipNhT76nQxonWoWTdWIvJDTJG0XbMowb1S1k
         L54Q==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b="IsABK/iK";
       spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1739222611; x=1739827411; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=8hxl1qhpLJ3Efs69kHsma6+g4OP8TBml88Q49l3bq8o=;
        b=bZC50vqechgBcJQ7s/rdLgvlAozxrf+1CBs5xFPm38sylL9GAiOai6HRpRy0iyTjNH
         +DLeBQVrotFQJv5Ex0mRpVHFIWFKN3DgukBo5u7CXkkkT2IrRlu5n6OkU9xNYKriHp7l
         7G+pg3KAmJ+l2Yz3lRKCtULzPXyKKeECoKAqQvWCG26SeXkzHzD6JBOCKNOHVKL4MgHs
         fT5Emd/E5IjjA+goKa5xyZIHbEu3Ljo1ZsPbMhFXI7dzhwl6Bw0hFZqugePkrfJhDK0D
         kD0CEKi1hacIoWKEwzqOeOE2Jp3JeOvP26CtFFIK8J0oW2j5D02m6V1pXLqiYwR6CVZF
         Xelw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1739222611; x=1739827411; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=8hxl1qhpLJ3Efs69kHsma6+g4OP8TBml88Q49l3bq8o=;
        b=c87nP6v7oazD1vfvZmlqEEgig+jNoGwVm6TCzDpKKoOAtm2vbc9hS51tRseeMX8hKj
         YpFzf4bU3zUYpcWooXb3nbe/ZtVIidfLnhwnoIZg6JDyYgnKN8ra4hcX32ZOj7fwfDli
         Zg10dxHTXWDc+w50oBGVmceohrfXsJFBAv4ZaFyOr/abR76RaMXuNaKTp3VMJzlCTrbs
         WTJqviWoJ7gA8dgOmhC7xtVHT+GYFBB7gdi8/9xu/AB8oIcb7pUTDlhAoHOW278qFz9O
         YUvRcOeFM/ZrZPchlqwIn42/3UuzUAiFJNRg5yFdEczUlwFCP2YGdMv8d7Zed/jQHo8I
         2YMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1739222611; x=1739827411;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=8hxl1qhpLJ3Efs69kHsma6+g4OP8TBml88Q49l3bq8o=;
        b=XnBAnngFYa5+VHQGWWlMU5W5qv8YMKPK2fVxoL8kDAfkzrJNFT2jyTEqgPRdmUPjFE
         CKyT155FBWHeCEEvIzP9uD1ZocHvRqedb/4JRMYLpCAMFe1ra13r/dtdu4E+JCq38orf
         BThRAbuTTmUXLhrbOb/YZ6Y822rTe3dNS2gTyVr4m/IDRZUlTNKWFiVUFWSzaXQ6/nS8
         DrFnO1c0OdNr7qx6y6HzgdK7s3GOrcz3SERwcx192NFSiuoob2JRkZeVz9xZ4TWXth42
         Nx14hYa8Ct/suBSyjNZeD13b1ufTbRIKQtzD2nNHR5izmt2onhO81tmF2S/Ex/GJEHwP
         0jkQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXlsyWJAMXYuIufMKoj7lhCUZXTcaCaq36SOHnAaGUgmcByIbcnMZolLOyzge5+ITJZ3D9s3ftPxq05@gnusha.org
X-Gm-Message-State: AOJu0YwFn+lKFd+vddhN7yV9FN/T+mBczT66DFOctbaaVM6GXEfxfDZC
	U0W0fmx9tL5ok9JI15uIoTACgdN+qnb8VfoqlK79WV8spjnIW1uI
X-Google-Smtp-Source: AGHT+IGOzcnmaQNXC0ltjPN9PSh8GaG4jsmHHodEO7WJ1OREqUmvMJzzojZCJ4B4LsTFQW8RMS86OA==
X-Received: by 2002:a05:6808:30a5:b0:3e6:3205:1a71 with SMTP id 5614622812f47-3f39223f211mr9244002b6e.15.1739222611066;
        Mon, 10 Feb 2025 13:23:31 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a4a:c443:0:b0:5f6:644a:2d43 with SMTP id 006d021491bc7-5fc97eb0922ls27431eaf.1.-pod-prod-08-us;
 Mon, 10 Feb 2025 13:23:28 -0800 (PST)
X-Received: by 2002:a05:6808:1ddf:b0:3f3:b830:627b with SMTP id 5614622812f47-3f3b8306fb1mr2930488b6e.2.1739222608130;
        Mon, 10 Feb 2025 13:23:28 -0800 (PST)
Received: by 2002:a05:6808:8fc:b0:3f3:b34a:69fc with SMTP id 5614622812f47-3f3b34a6b8emsb6e;
        Mon, 10 Feb 2025 13:22:14 -0800 (PST)
X-Received: by 2002:a05:6a00:1953:b0:72f:f872:30a7 with SMTP id d2e1a72fcca58-7305d463158mr23756869b3a.6.1739222532847;
        Mon, 10 Feb 2025 13:22:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1739222532; cv=none;
        d=google.com; s=arc-20240605;
        b=QrDQ2uIPOxUewtqXHe+O7s4+WoAz/FCEtiQrlJEz8jqFed8pgvuCf4GfaOfnExs8Aj
         6cei3Xgp1WL+5rv7z7xjXYVuVphJXFwo1fi4Cs/b8yaQzp234Pv0dFmnCCoCyH+Vqy8D
         7mo0KSkU+Mwt+GPa7e5idZPKaw3pGKONG1TBhQ4t+69QpMcVth54qhEbekNh8yv62Fg0
         iejFjFXqArb58FIefgYHQdGvog+B95yxyAJ3NUAQumrNJ/a4oMpFpWxRa4zlPuBBbd6a
         fg6L+aDOsyZTV0vQxvXStaCp24MOpjvJoc8BbSg2PwRfVz9Jl7yrxFcZ+xEv3AGeJs4a
         riDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=bK+zWwOgwfvYglt17YZY4DYnXBX9q6gmWLzkH+VPIYE=;
        fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=;
        b=M47tVko9WpL/VRpp879ouAZWNBoGC8IJwk/KSSw/dtGrFSnfqaikUERw94ReEtxRbQ
         dsrrZgiBs5MBntORay/Ruogvdf7j3XJ2A1vtkKn11IWlTKY3RUYAa/t+cGx35MNUJlNr
         FzONI4N9pRHe3m3Y+jgpFLT77Utmmv9GUGGE/n8v//TtnsXxhkZh0+A3pL9gBAffLuxp
         kiYUMcY3zMqoNCD0QKBuetLcf4GmC/xOuQsTtIepiOLjTG0rydDlqDnRbAIpppTDkGrz
         /WAmwH2SI1KFiaUDJsuQFbYEGXQ80h3loVRwLfGagPfM5XoCBzx35qXm0uiIy/jKK8Jd
         Egvg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b="IsABK/iK";
       spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com. [2607:f8b0:4864:20::1129])
        by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-730749bae68si258375b3a.5.2025.02.10.13.22.12
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 10 Feb 2025 13:22:12 -0800 (PST)
Received-SPF: pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) client-ip=2607:f8b0:4864:20::1129;
Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-6f4bc408e49so38999047b3.1
        for <bitcoindev@googlegroups.com>; Mon, 10 Feb 2025 13:22:12 -0800 (PST)
X-Gm-Gg: ASbGncswZ03Eba5pIR66NgDNZ1HRmI+U0U2sUPIU0FO4H0TQNdYCQyvj2MBVXoHO1LW
	T1BqFVx62+kDxi1goWEHX91LNhgStHlxUARfZKo25T3hW14ZCD6lmDlULZRjBMABPIqF1Pwhq
X-Received: by 2002:a05:690c:4986:b0:6f7:3e01:8a49 with SMTP id
 00721157ae682-6f9b29e61c4mr145086177b3.26.1739222530472; Mon, 10 Feb 2025
 13:22:10 -0800 (PST)
MIME-Version: 1.0
References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com>
In-Reply-To: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com>
From: Chris Stewart <stewart.chris1234@gmail.com>
Date: Mon, 10 Feb 2025 15:21:59 -0600
X-Gm-Features: AWEUYZkeEbEMWHXCMjaZKknsHxocLoyglyP0rKrXghMuPQjPKBycxHqKXljIUIE
Message-ID: <CAGL6+mFYCKjhD8O1G9diC4pbM=_XubW0YxTfeqyyRpDe9t2fng@mail.gmail.com>
Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000001d485c062dd04d64"
X-Original-Sender: stewart.chris1234@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b="IsABK/iK";       spf=pass
 (google.com: domain of stewart.chris1234@gmail.com designates
 2607:f8b0:4864:20::1129 as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--0000000000001d485c062dd04d64
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone! Excited to see this work moving forward. I've taken the
liberty of carving off the 64 byte transaction portion of this proposal and
drafted a BIP. You can view a rendered draft with references here:
https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX.medi=
awiki

<pre>
  BIP: ?
  Layer: Consensus (soft fork)
  Title: Disallow 64 byte transactions
  Author: Chris Stewart <stewart.chris1234@gmail.com>
  Status: Draft
  Type: Specification
  License: BSD-3-Clause
  Created: ?
</pre>

=3D=3DAbstract=3D=3D

This BIP describes the rationale for disallowing transactions that are
serialized to 64 bytes without the transaction's witness.
We describe the weaknesses to the merkle tree included in bitcoin block
headers, various exploits for those weaknesses.

=3D=3DMotivation=3D=3D

Bitcoin block headers include a commitment to the set of transactions in a
given
block, which is implemented by constructing a Merkle tree of transaction
id=E2=80=99s
(double-SHA256 hash of a transaction) and including the root of the tree in
the
block header. This in turn allows for proving to a Bitcoin light client
that a
given transaction is in a given block by providing a path through the tree
to the
transaction. However, Bitcoin=E2=80=99s particular construction of the Merk=
le tree
has
several security weaknesses, including at least two forms of block
malleability
that have an impact on the consensus logic of Bitcoin Core, and an attack o=
n
light clients, where an invalid transaction could be =E2=80=9Dproven=E2=80=
=9D to appear in
a block
by doing substantially less work than a SHA256 hash collision would require=
.
This has been prevented by relay policy since 2018<ref>[
https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a01=
6ba7064c89bf9ab6da3
PR #11423 disallows 64 byte transactions in bitcoin core relay]</ref>

=3D=3DSpecification=3D=3D

This BIP disallows bitcoin transactions that are serialized to 64 bytes in
length without it's witness.

=3D=3DRationale=3D=3D

=3D=3D=3D Block malleability =3D=3D=3D

64 byte transactions introduce block malleability. Malicious peers can
construct consensus valid and invalid 64 byte
transactions that have the same serialization as the concatenation of 2
nodes in the merkle tree.

Assume we have a valid bitcoin block with 2 transactions in it -
T<sub>0</sub> and T<sub>1</sub>.
The merkle root for this block is H(T<sub>0</sub>||T<sub>1</sub>).
A user could find a malicious 64 byte transaction T<sub>m</sub> that
serializes to T<sub>0</sub>||T<sub>1</sub>.
Next the malicious user relays the block containing the malicious
T<sub>m</sub> rather than the
valid bitcoin transactions T<sub>0</sub> and T<sub>1</sub>.

=3D=3D=3D=3D Block malleability with consensus INVALID transactions =3D=3D=
=3D=3D

The peer receiving the malicious block marks the block as invalid as
T<sub>m</sub>
is not a valid transaction according to network consensus rules.
Other peers on the network receive the valid block containing T<sub>0</sub>
and T<sub>1</sub>
add the block to their blockchain. Peers that receive the invalid block
before the valid block
will never come to consensus with their peers due to the malicious user
finding a collision
within the block's merkle root. Finding this collision approximately 22
bits worth of work<ref>[
https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-Bi=
tcoinMerkle.pdf
to produce a block that has a Merkle
root which is a hash of a 64-byte quantity that deserializes validly, it=E2=
=80=99s
enough
to just do 8 bits of work to find a workable coinbase (which will hash to
the first
32 bytes), plus another =E2=89=8822 bits of work ((1/5) =E2=88=97224, so sl=
ightly less) to
find
a workable second transaction which will hash to the second 32 bytes) =E2=
=80=93 a
very
small amount of computation.]</ref>

This attack vector was fixed in 0.6.2<ref>[
https://bitcoin.org/en/alert/2012-05-14-dos#risks CVE-2012-2459]</ref>,
re-introduced in 0.13.x<ref>[https://github.com/bitcoin/bitcoin/pull/7225
#7225]</ref> and patched again in
0.14<ref>[https://github.com/bitcoin/bitcoin/pull/9765 #9765]</ref> of
bitcoin core.

=3D=3D=3D=3D Block malleability with consensus VALID transactions =3D=3D=3D=
=3D

Producing a valid bitcoin transaction T<sub>m</sub> that adheres to network
consesnsus
rules requires 224 bits of work<ref>[
https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-Bi=
tcoinMerkle.pdf
Note that the first transaction in a block must be a coinbase, and as
discussed
above, that largely constrains the first 32 bytes of the first transaction:
only
the 4 version bytes are unconstrained. So it would take at least 28*8=3D 22=
4
bits
of work to find the first node in a given row of the tree that would match
the
first half of a coinbase, in addition to the amount of work required to
grind the
second half of the transaction to something meaningful (which is much
easier =E2=80=93
only 16 bytes or so are constrained, so approximately 128 bits of work to
find a collision). Of course, any of the rows in the Merkle tree could be
used, but it nevertheless seems clear that this should be computationally
infeasible.]</ref>.
This is computationally and financially expensive but theoretically
possible. This can lead to a persistent chain split on the network.

=3D=3D=3D Attack on SPV clients =3D=3D=3D

BIP37<ref>[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
BIP37]</ref>provides a partial merkle tree format<ref>[
https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki#user-content=
-Partial_Merkle_branch_format
Partial Merkle Tree Format]</ref>
that allows you to verify your bitcoin transaction is included in a merkle
root embedded in a bitcoin block header.
Notably this format does not commit to the height of the merkle tree.

Suppose a (valid) 64-byte transaction T is included in a block with the
property that the second 32 bytes (which
are less constrained than the first 32 bytes) are constructed so that they
collide
with the hash of some other fake, invalid transaction F. The attacker can
fool the SPV client into believing that F
was included in a bitcoin block rather than T with 81 bits<ref>[
https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-Bi=
tcoinMerkle.pdf
An attacker who can do 81 bits of work (followed by another 40 bits of
work, to
construct the funding transaction whose coins will be spent by this one) is
able
to fool an SPV client in this way.]</ref> of work. This also reduces
implementation complexity of SPV wallets<ref>[
https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The
steps needed to make sure a merkle proof for a transaction is
secure.]</ref>.

This could be mitigated by knowing the depth of the merkle tree. Requiring
SPV clients to request both the coinbase transaction could mitigate this
attack.
To produce a valid coinbase transaction at the same depth that our fake
transaction F occurs at would require 224 bits of work.
As mentioned above, this is computionally and financially expensive, but
theoretically possible.

=3D=3DBackward compatibility=3D=3D

There have been 5 64 byte transactions that have occcurred in the bitcoin
blockchain as of this
writing <ref>[
https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/64byte-tx-mai=
nnet.txt
64 byte transactions in the bitcoin blockchain]</ref>
With the last transaction
7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612<ref>[
https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5eda=
dd437f9e27a612
Last 64 byte transaction in the bitcoin blockchain]</ref>
occurring at block height 419,606<ref>[
https://mempool.space/block/000000000000000000308f1efc24419f34a3bafcc2b53c3=
2dd57e4502865fd84
Block 419,606]</ref>.

TODO

=3D=3DReference implementation=3D=3D

<source lang=3D"cpp">
/**
 * We want to enforce certain rules (specifically the 64-byte transaction
check)
 * before we call CheckBlock to check the merkle root. This allows us to
enforce
 * malleability checks which may interact with other CheckBlock checks.
 * This is currently called both in AcceptBlock prior to writing the block
to
 * disk and in ConnectBlock.
 * Note that as this is called before merkle-tree checks so must never
return a
 * non-malleable error condition.
 */
static bool ContextualBlockPreCheck(const CBlock& block,
BlockValidationState& state, const ChainstateManager& chainman, const
CBlockIndex* pindexPrev)
{
    if (DeploymentActiveAfter(pindexPrev, chainman,
Consensus::DEPLOYMENT_64BYTETX)) {
      for (const auto& tx : block.vtx) {
            if (::GetSerializeSize(TX_NO_WITNESS(tx)) =3D=3D 64) {
                return state.Invalid(BlockValidationResult::BLOCK_MUTATED,
"64-byte-transaction", strprintf("size of tx %s without witness is 64
bytes", tx->GetHash().ToString()));
            }
        }
    }

    return true;
}
</source>

https://github.com/bitcoin-inquisition/bitcoin/pull/24/files

=3D=3D Rationale =3D=3D

<references />

=3D=3DCopyright=3D=3D
This BIP is licensed under the [https://opensource.org/license/BSD-3-Clause
BSD-3-Clause License].

=3D=3DAcknowledgements=3D=3D

Suhas Daftuar, AJ Towns, Sergio Demian Lerner, Greg Maxwell, Matt Corallo,
Antoine Poinsont, Dave Harding and Erik Voskuil

On Wed, Feb 5, 2025 at 6:57=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Develo=
pment
Mailing List <bitcoindev@googlegroups.com> wrote:

> Hi everyone,
>
> A bit over a year ago i started working on revisiting the 2019 Great
> Consensus Cleanup proposal from
> Matt Corallo [0]. His proposal included:
> - making <=3D64 bytes transactions invalid to fix merkle tree weaknesses;
> - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATOR
> and non-standard sighash
>   types fail script validation to mitigate the worst case block validatio=
n
> time;
> - restrict the nTime field of the first block in each difficulty
> adjustment interval to be no less
>   than 600 seconds lower than the previous block's;
>
> I set out to research the impact of each of the vulnerabilities this
> intended to patch, the
> alternative fixes possible for each and finally if there was any other
> protocol bug fix we'd want to
> include if we went through the considerable effort of soft forking Bitcoi=
n
> already.
>
> Later in March i shared some first findings on Delving [1] and advertized
> the effort on this mailing
> list [2]. I also created a companion thread on Delving, kept private, to
> discuss the details of the
> worst case block validation time [3]. As one would expect due to the
> larger design space available
> to fix this issue, this private thread is where most of the discussion
> would happen. Thank you to
> everyone who contributed feedback, insights, ideas and argumented opinion=
s
> on the different issues
> all along the process.
>
> Now i would like to update the broader Bitcoin development community on
> the outcome of this effort.
> I believe a Consensus Cleanup proposal should include the following.
> - A fix for vulnerabilities surrounding the use of timestamps in the
> difficulty adjustment
>   algorithm.  In particular, a fix for the timewarp attack with a 7200
> seconds grace period as well
>   as a fix for the Murch-Zawy attack [4] by making invalid any difficulty
> adjustment period with a
>   negative duration.
> - A fix for long block validation times with a minimal "confiscation
> surface", by introducing a
>   per-transaction limit on the number of legacy sigops in the inputs.
> - A fix for merkle tree weaknesses by making transactions which serialize
> to exactly 64 bytes
>   invalid.
> - A fix for duplicate transactions to supplement BIP34 in order to avoid
> resuming unnecessary BIP30
>   validation in the future. This is achieved by mandating the nLockTime
> field of coinbase
>   transaction to be set to the height of their block minus 1.
>
> I have started drafting a BIP draft with the detailed specs for this.
>
> Antoine Poinsot
>
>
> [0]
> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe=
661050c2/bip-XXXX.mediawiki
> [1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
> [2] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ
> [3] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711
> [4]
> https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#var=
iant-on-zawys-attack-2
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZD=
Q65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3Mop=
uATI%3D%40protonmail.com
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAGL6%2BmFYCKjhD8O1G9diC4pbM%3D_XubW0YxTfeqyyRpDe9t2fng%40mail.gmail.com.

--0000000000001d485c062dd04d64
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi everyone! Excited to see this work moving forward. I&#3=
9;ve taken the=20
liberty of carving off the 64 byte transaction portion of this proposal and=
 drafted a
 BIP. You can view a rendered draft with references here: <a href=3D"https:=
//github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX.mediawiki"=
 target=3D"_blank">https://github.com/Christewart/bips/blob/2024-12-20-64by=
tetxs/bip-XXXX.mediawiki</a><br><br>&lt;pre&gt;<br>=C2=A0 BIP: ?<br>=C2=A0 =
Layer: Consensus (soft fork)<br>=C2=A0 Title: Disallow 64 byte transactions=
<br>=C2=A0 Author: Chris Stewart &lt;<a href=3D"mailto:stewart.chris1234@gm=
ail.com">stewart.chris1234@gmail.com</a>&gt;<br>=C2=A0 Status: Draft<br>=C2=
=A0 Type: Specification<br>=C2=A0 License: BSD-3-Clause<br>=C2=A0 Created: =
?<br>&lt;/pre&gt;<br><br>=3D=3DAbstract=3D=3D<br><br>This BIP describes the=
 rationale for disallowing transactions that are serialized to 64 bytes wit=
hout the transaction&#39;s witness. <br>We describe the weaknesses to the m=
erkle tree included in bitcoin block headers, various exploits for those we=
aknesses.<br><br>=3D=3DMotivation=3D=3D<br><br>Bitcoin block headers includ=
e a commitment to the set of transactions in a given<br>block, which is imp=
lemented by constructing a Merkle tree of transaction id=E2=80=99s<br>(doub=
le-SHA256 hash of a transaction) and including the root of the tree in the<=
br>block header. This in turn allows for proving to a Bitcoin light client =
that a<br>given transaction is in a given block by providing a path through=
 the tree to the<br>transaction. However, Bitcoin=E2=80=99s particular cons=
truction of the Merkle tree has<br>several security weaknesses, including a=
t least two forms of block malleability<br>that have an impact on the conse=
nsus logic of Bitcoin Core, and an attack on<br>light clients, where an inv=
alid transaction could be =E2=80=9Dproven=E2=80=9D to appear in a block<br>=
by doing substantially less work than a SHA256 hash collision would require=
.<br>This has been prevented by relay policy since 2018&lt;ref&gt;[<a href=
=3D"https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e23613=
3a016ba7064c89bf9ab6da3">https://github.com/bitcoin/bitcoin/pull/11423/comm=
its/7485488e907e236133a016ba7064c89bf9ab6da3</a> PR #11423 disallows 64 byt=
e transactions in bitcoin core relay]&lt;/ref&gt;<br><br>=3D=3DSpecificatio=
n=3D=3D<br><br>This BIP disallows bitcoin transactions that are serialized =
to 64 bytes in length without it&#39;s witness.<br><br>=3D=3DRationale=3D=
=3D<br><br>=3D=3D=3D Block malleability =3D=3D=3D<br><br>64 byte transactio=
ns introduce block malleability. Malicious peers can construct consensus va=
lid and invalid 64 byte<br>transactions that have the same serialization as=
 the concatenation of 2 nodes in the merkle tree.<br><br>Assume we have a v=
alid bitcoin block with 2 transactions in it - T&lt;sub&gt;0&lt;/sub&gt; an=
d T&lt;sub&gt;1&lt;/sub&gt;.<br>The merkle root for this block is H(T&lt;su=
b&gt;0&lt;/sub&gt;||T&lt;sub&gt;1&lt;/sub&gt;).<br>A user could find a mali=
cious 64 byte transaction T&lt;sub&gt;m&lt;/sub&gt; that serializes to T&lt=
;sub&gt;0&lt;/sub&gt;||T&lt;sub&gt;1&lt;/sub&gt;.<br>Next the malicious use=
r relays the block containing the malicious T&lt;sub&gt;m&lt;/sub&gt; rathe=
r than the<br>valid bitcoin transactions T&lt;sub&gt;0&lt;/sub&gt; and T&lt=
;sub&gt;1&lt;/sub&gt;.<br><br>=3D=3D=3D=3D Block malleability with consensu=
s INVALID transactions =3D=3D=3D=3D<br><br>The peer receiving the malicious=
 block marks the block as invalid as T&lt;sub&gt;m&lt;/sub&gt; <br>is not a=
 valid transaction according to network consensus rules.<br>Other peers on =
the network receive the valid block containing T&lt;sub&gt;0&lt;/sub&gt; an=
d T&lt;sub&gt;1&lt;/sub&gt;<br>add the block to their blockchain. Peers tha=
t receive the invalid block before the valid block<br>will never come to co=
nsensus with their peers due to the malicious user finding a collision<br>w=
ithin the block&#39;s merkle root. Finding this collision approximately 22 =
bits worth of work&lt;ref&gt;[<a href=3D"https://github.com/Christewart/bip=
s/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf">https://github.co=
m/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf</=
a> to produce a block that has a Merkle<br>root which is a hash of a 64-byt=
e quantity that deserializes validly, it=E2=80=99s enough<br>to just do 8 b=
its of work to find a workable coinbase (which will hash to the first<br>32=
 bytes), plus another =E2=89=8822 bits of work ((1/5) =E2=88=97224, so slig=
htly less) to find<br>a workable second transaction which will hash to the =
second 32 bytes) =E2=80=93 a very<br>small amount of computation.]&lt;/ref&=
gt;<br><br>This attack vector was fixed in 0.6.2&lt;ref&gt;[<a href=3D"http=
s://bitcoin.org/en/alert/2012-05-14-dos#risks">https://bitcoin.org/en/alert=
/2012-05-14-dos#risks</a> CVE-2012-2459]&lt;/ref&gt;, re-introduced in 0.13=
.x&lt;ref&gt;[<a href=3D"https://github.com/bitcoin/bitcoin/pull/7225">http=
s://github.com/bitcoin/bitcoin/pull/7225</a> #7225]&lt;/ref&gt; and patched=
 again in<br>0.14&lt;ref&gt;[<a href=3D"https://github.com/bitcoin/bitcoin/=
pull/9765">https://github.com/bitcoin/bitcoin/pull/9765</a> #9765]&lt;/ref&=
gt; of bitcoin core.<br><br>=3D=3D=3D=3D Block malleability with consensus =
VALID transactions =3D=3D=3D=3D<br><br>Producing a valid bitcoin transactio=
n T&lt;sub&gt;m&lt;/sub&gt; that adheres to network consesnsus<br>rules req=
uires 224 bits of work&lt;ref&gt;[<a href=3D"https://github.com/Christewart=
/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf">https://githu=
b.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.p=
df</a> Note that the first transaction in a block must be a coinbase, and a=
s discussed<br>above, that largely constrains the first 32 bytes of the fir=
st transaction: only<br>the 4 version bytes are unconstrained. So it would =
take at least 28*8=3D 224 bits<br>of work to find the first node in a given=
 row of the tree that would match the<br>first half of a coinbase, in addit=
ion to the amount of work required to grind the<br>second half of the trans=
action to something meaningful (which is much easier =E2=80=93<br>only 16 b=
ytes or so are constrained, so approximately 128 bits of work to find a col=
lision). Of course, any of the rows in the Merkle tree could be used, but i=
t nevertheless seems clear that this should be computationally infeasible.]=
&lt;/ref&gt;.<br>This is computationally and financially expensive but theo=
retically possible. This can lead to a persistent chain split on the networ=
k.<br><br>=3D=3D=3D Attack on SPV clients =3D=3D=3D<br><br>BIP37&lt;ref&gt;=
[<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki"=
>https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki</a> BIP37]&=
lt;/ref&gt;provides a partial merkle tree format&lt;ref&gt;[<a href=3D"http=
s://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki#user-content-Par=
tial_Merkle_branch_format">https://github.com/bitcoin/bips/blob/master/bip-=
0037.mediawiki#user-content-Partial_Merkle_branch_format</a> Partial Merkle=
 Tree Format]&lt;/ref&gt;<br>that allows you to verify your bitcoin transac=
tion is included in a merkle root embedded in a bitcoin block header.<br>No=
tably this format does not commit to the height of the merkle tree.<br><br>=
Suppose a (valid) 64-byte transaction T is included in a block with the pro=
perty that the second 32 bytes (which<br>are less constrained than the firs=
t 32 bytes) are constructed so that they collide<br>with the hash of some o=
ther fake, invalid transaction F. The attacker can fool the SPV client into=
 believing that F<br>was included in a bitcoin block rather than T with 81 =
bits&lt;ref&gt;[<a href=3D"https://github.com/Christewart/bips/blob/2024-12=
-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf">https://github.com/Christewart/=
bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf</a> An attacker=
 who can do 81 bits of work (followed by another 40 bits of work, to<br>con=
struct the funding transaction whose coins will be spent by this one) is ab=
le<br>to fool an SPV client in this way.]&lt;/ref&gt; of work. This also re=
duces implementation complexity of SPV wallets&lt;ref&gt;[<a href=3D"https:=
//delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43">https://delv=
ingbitcoin.org/t/great-consensus-cleanup-revival/710/43</a> The steps neede=
d to make sure a merkle proof for a transaction is secure.]&lt;/ref&gt;.<br=
><br>This could be mitigated by knowing the depth of the merkle tree. Requi=
ring SPV clients to request both the coinbase transaction could mitigate th=
is attack.<br>To produce a valid coinbase transaction at the same depth tha=
t our fake transaction F occurs at would require 224 bits of work.<br>As me=
ntioned above, this is computionally and financially expensive, but theoret=
ically possible.<br><br>=3D=3DBackward compatibility=3D=3D<br><br>There hav=
e been 5 64 byte transactions that have occcurred in the bitcoin blockchain=
 as of this<br>writing &lt;ref&gt;[<a href=3D"https://github.com/Christewar=
t/bips/blob/2024-12-20-64bytetxs/64byte-tx-mainnet.txt">https://github.com/=
Christewart/bips/blob/2024-12-20-64bytetxs/64byte-tx-mainnet.txt</a> 64 byt=
e transactions in the bitcoin blockchain]&lt;/ref&gt;<br>With the last tran=
saction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612&lt=
;ref&gt;[<a href=3D"https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d=
30c7f4b08e2ce57b5edadd437f9e27a612">https://mempool.space/tx/7f2efc6546011a=
d3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612</a> Last 64 byte transac=
tion in the bitcoin blockchain]&lt;/ref&gt;<br>occurring at block height 41=
9,606&lt;ref&gt;[<a href=3D"https://mempool.space/block/0000000000000000003=
08f1efc24419f34a3bafcc2b53c32dd57e4502865fd84">https://mempool.space/block/=
000000000000000000308f1efc24419f34a3bafcc2b53c32dd57e4502865fd84</a> Block =
419,606]&lt;/ref&gt;.<br><br>TODO<br><br>=3D=3DReference implementation=3D=
=3D<br><br>&lt;source lang=3D&quot;cpp&quot;&gt;<br>/**<br>=C2=A0* We want =
to enforce certain rules (specifically the 64-byte transaction check)<br>=
=C2=A0* before we call CheckBlock to check the merkle root. This allows us =
to enforce<br>=C2=A0* malleability checks which may interact with other Che=
ckBlock checks.<br>=C2=A0* This is currently called both in AcceptBlock pri=
or to writing the block to<br>=C2=A0* disk and in ConnectBlock.<br>=C2=A0* =
Note that as this is called before merkle-tree checks so must never return =
a<br>=C2=A0* non-malleable error condition.<br>=C2=A0*/<br>static bool Cont=
extualBlockPreCheck(const CBlock&amp; block, BlockValidationState&amp; stat=
e, const ChainstateManager&amp; chainman, const CBlockIndex* pindexPrev)<br=
>{<br>=C2=A0 =C2=A0 if (DeploymentActiveAfter(pindexPrev, chainman, Consens=
us::DEPLOYMENT_64BYTETX)) {<br>=C2=A0 =C2=A0 =C2=A0 for (const auto&amp; tx=
 : block.vtx) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (::GetSeria=
lizeSize(TX_NO_WITNESS(tx)) =3D=3D 64) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 return state.Invalid(BlockValidationResult::BLOCK_=
MUTATED, &quot;64-byte-transaction&quot;, strprintf(&quot;size of tx %s wit=
hout witness is 64 bytes&quot;, tx-&gt;GetHash().ToString()));<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>=
=C2=A0 =C2=A0 }<br><br>=C2=A0 =C2=A0 return true;<br>}<br>&lt;/source&gt;<b=
r><br><a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/24/fil=
es">https://github.com/bitcoin-inquisition/bitcoin/pull/24/files</a><br><br=
>=3D=3D Rationale =3D=3D<br><br>&lt;references /&gt;<br><br>=3D=3DCopyright=
=3D=3D<br>This BIP is licensed under the [<a href=3D"https://opensource.org=
/license/BSD-3-Clause">https://opensource.org/license/BSD-3-Clause</a> BSD-=
3-Clause License].<br><br>=3D=3DAcknowledgements=3D=3D<br><br>Suhas Daftuar=
, AJ Towns, Sergio Demian Lerner, Greg Maxwell, Matt Corallo, Antoine Poins=
ont, Dave Harding and Erik Voskuil<br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 5, =
2025 at 6:57=E2=80=AFPM &#39;Antoine Poinsot&#39; via Bitcoin Development M=
ailing List &lt;<a href=3D"mailto:bitcoindev@googlegroups.com">bitcoindev@g=
ooglegroups.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">Hi everyone,<br>
<br>
A bit over a year ago i started working on revisiting the 2019 Great Consen=
sus Cleanup proposal from<br>
Matt Corallo [0]. His proposal included:<br>
- making &lt;=3D64 bytes transactions invalid to fix merkle tree weaknesses=
;<br>
- making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATOR a=
nd non-standard sighash<br>
=C2=A0 types fail script validation to mitigate the worst case block valida=
tion time;<br>
- restrict the nTime field of the first block in each difficulty adjustment=
 interval to be no less<br>
=C2=A0 than 600 seconds lower than the previous block&#39;s;<br>
<br>
I set out to research the impact of each of the vulnerabilities this intend=
ed to patch, the<br>
alternative fixes possible for each and finally if there was any other prot=
ocol bug fix we&#39;d want to<br>
include if we went through the considerable effort of soft forking Bitcoin =
already.<br>
<br>
Later in March i shared some first findings on Delving [1] and advertized t=
he effort on this mailing<br>
list [2]. I also created a companion thread on Delving, kept private, to di=
scuss the details of the<br>
worst case block validation time [3]. As one would expect due to the larger=
 design space available<br>
to fix this issue, this private thread is where most of the discussion woul=
d happen. Thank you to<br>
everyone who contributed feedback, insights, ideas and argumented opinions =
on the different issues<br>
all along the process.<br>
<br>
Now i would like to update the broader Bitcoin development community on the=
 outcome of this effort.<br>
I believe a Consensus Cleanup proposal should include the following.<br>
- A fix for vulnerabilities surrounding the use of timestamps in the diffic=
ulty adjustment<br>
=C2=A0 algorithm.=C2=A0 In particular, a fix for the timewarp attack with a=
 7200 seconds grace period as well<br>
=C2=A0 as a fix for the Murch-Zawy attack [4] by making invalid any difficu=
lty adjustment period with a<br>
=C2=A0 negative duration.<br>
- A fix for long block validation times with a minimal &quot;confiscation s=
urface&quot;, by introducing a<br>
=C2=A0 per-transaction limit on the number of legacy sigops in the inputs.<=
br>
- A fix for merkle tree weaknesses by making transactions which serialize t=
o exactly 64 bytes<br>
=C2=A0 invalid.<br>
- A fix for duplicate transactions to supplement BIP34 in order to avoid re=
suming unnecessary BIP30<br>
=C2=A0 validation in the future. This is achieved by mandating the nLockTim=
e field of coinbase<br>
=C2=A0 transaction to be set to the height of their block minus 1.<br>
<br>
I have started drafting a BIP draft with the detailed specs for this.<br>
<br>
Antoine Poinsot<br>
<br>
<br>
[0] <a href=3D"https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0c=
c6d2197d3eabe661050c2/bip-XXXX.mediawiki" rel=3D"noreferrer" target=3D"_bla=
nk">https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3ea=
be661050c2/bip-XXXX.mediawiki</a><br>
[1] <a href=3D"https://delvingbitcoin.org/t/great-consensus-cleanup-revival=
/710" rel=3D"noreferrer" target=3D"_blank">https://delvingbitcoin.org/t/gre=
at-consensus-cleanup-revival/710</a><br>
[2] <a href=3D"https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3B=
iOuAAAJ" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/g/b=
itcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ</a><br>
[3] <a href=3D"https://delvingbitcoin.org/t/worst-block-validation-time-inq=
uiry/711" rel=3D"noreferrer" target=3D"_blank">https://delvingbitcoin.org/t=
/worst-block-validation-time-inquiry/711</a><br>
[4] <a href=3D"https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-at=
tack/1062#variant-on-zawys-attack-2" rel=3D"noreferrer" target=3D"_blank">h=
ttps://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#varian=
t-on-zawys-attack-2</a><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cU=
lWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40protonmail.com" rel=3D"nor=
eferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/jiy=
MlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0=
HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40protonmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAGL6%2BmFYCKjhD8O1G9diC4pbM%3D_XubW0YxTfeqyyRpDe9t2fng%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAGL6%2BmFYCKjhD8O1G9diC4pbM%3D_XubW0YxTfeqyyRpDe9t2fng%=
40mail.gmail.com</a>.<br />

--0000000000001d485c062dd04d64--