summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChris Stewart <stewart.chris1234@gmail.com>2025-02-10 15:21:59 -0600
committerbitcoindev <bitcoindev@googlegroups.com>2025-02-10 13:23:38 -0800
commit2b6f315ce03afa4a59fb9c67eed2fc5c1eaf7a0e (patch)
treee45bbe3bd9366ea88fe5bbc25a9ccb6d5e261e35
parent136c1122c51df651b670884d65952dda2b1caaec (diff)
downloadpi-bitcoindev-2b6f315ce03afa4a59fb9c67eed2fc5c1eaf7a0e.tar.gz
pi-bitcoindev-2b6f315ce03afa4a59fb9c67eed2fc5c1eaf7a0e.zip
Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
-rw-r--r--ff/1b26edb0056f5bca3e1e13b67c18381cf3c203791
1 files changed, 791 insertions, 0 deletions
diff --git a/ff/1b26edb0056f5bca3e1e13b67c18381cf3c203 b/ff/1b26edb0056f5bca3e1e13b67c18381cf3c203
new file mode 100644
index 000000000..8ca3bcd88
--- /dev/null
+++ b/ff/1b26edb0056f5bca3e1e13b67c18381cf3c203
@@ -0,0 +1,791 @@
+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--
+