diff options
author | Chris Stewart <stewart.chris1234@gmail.com> | 2025-02-10 15:21:59 -0600 |
---|---|---|
committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-02-10 13:23:38 -0800 |
commit | 2b6f315ce03afa4a59fb9c67eed2fc5c1eaf7a0e (patch) | |
tree | e45bbe3bd9366ea88fe5bbc25a9ccb6d5e261e35 | |
parent | 136c1122c51df651b670884d65952dda2b1caaec (diff) | |
download | pi-bitcoindev-2b6f315ce03afa4a59fb9c67eed2fc5c1eaf7a0e.tar.gz pi-bitcoindev-2b6f315ce03afa4a59fb9c67eed2fc5c1eaf7a0e.zip |
Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
-rw-r--r-- | ff/1b26edb0056f5bca3e1e13b67c18381cf3c203 | 791 |
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= +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><pre><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 <<a href=3D"mailto:stewart.chris1234@gm= +ail.com">stewart.chris1234@gmail.com</a>><br>=C2=A0 Status: Draft<br>=C2= +=A0 Type: Specification<br>=C2=A0 License: BSD-3-Clause<br>=C2=A0 Created: = +?<br></pre><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'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<ref>[<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]</ref><br><br>=3D=3DSpecificatio= +n=3D=3D<br><br>This BIP disallows bitcoin transactions that are serialized = +to 64 bytes in length without it'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<sub>0</sub> an= +d T<sub>1</sub>.<br>The merkle root for this block is H(T<su= +b>0</sub>||T<sub>1</sub>).<br>A user could find a mali= +cious 64 byte transaction T<sub>m</sub> that serializes to T<= +;sub>0</sub>||T<sub>1</sub>.<br>Next the malicious use= +r relays the block containing the malicious T<sub>m</sub> rathe= +r than the<br>valid bitcoin transactions T<sub>0</sub> and T<= +;sub>1</sub>.<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<sub>m</sub> <br>is not a= + valid transaction according to network consensus rules.<br>Other peers on = +the network receive the valid block containing T<sub>0</sub> an= +d T<sub>1</sub><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's merkle root. Finding this collision approximately 22 = +bits worth of work<ref>[<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.]</ref&= +gt;<br><br>This attack vector was fixed in 0.6.2<ref>[<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]</ref>, re-introduced in 0.13= +.x<ref>[<a href=3D"https://github.com/bitcoin/bitcoin/pull/7225">http= +s://github.com/bitcoin/bitcoin/pull/7225</a> #7225]</ref> and patched= + again in<br>0.14<ref>[<a href=3D"https://github.com/bitcoin/bitcoin/= +pull/9765">https://github.com/bitcoin/bitcoin/pull/9765</a> #9765]</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<sub>m</sub> that adheres to network consesnsus<br>rules req= +uires 224 bits of work<ref>[<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.]= +</ref>.<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<ref>= +[<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>provides a partial merkle tree format<ref>[<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]</ref><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<ref>[<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.]</ref> of work. This also re= +duces implementation complexity of SPV wallets<ref>[<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.]</ref>.<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 <ref>[<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]</ref><br>With the last tran= +saction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612<= +;ref>[<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]</ref><br>occurring at block height 41= +9,606<ref>[<a href=3D"https://mempool.space/block/0000000000000000003= +08f1efc24419f34a3bafcc2b53c32dd57e4502865fd84">https://mempool.space/block/= +000000000000000000308f1efc24419f34a3bafcc2b53c32dd57e4502865fd84</a> Block = +419,606]</ref>.<br><br>TODO<br><br>=3D=3DReference implementation=3D= +=3D<br><br><source lang=3D"cpp"><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& block, BlockValidationState& stat= +e, const ChainstateManager& 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& 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, "64-byte-transaction", strprintf("size of tx %s wit= +hout witness is 64 bytes", tx->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></source><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><references /><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 'Antoine Poinsot' via Bitcoin Development M= +ailing List <<a href=3D"mailto:bitcoindev@googlegroups.com">bitcoindev@g= +ooglegroups.com</a>> 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 <=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'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'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 "confiscation s= +urface", 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" 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" 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-- + |