path: root/c0/08edc5f9383e091d1c6259c798877fb79588a7

Delivery-date: Sun, 27 Apr 2025 09:48:18 -0700
Received: from mail-ot1-f56.google.com ([209.85.210.56])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCMIFYEXXQGRBR57XHAAMGQECAVIKGQ@googlegroups.com>)
	id 1u95Au-0002nD-Ux
	for bitcoindev@gnusha.org; Sun, 27 Apr 2025 09:48:18 -0700
Received: by mail-ot1-f56.google.com with SMTP id 46e09a7af769-72c3169fa24sf963113a34.3
        for <bitcoindev@gnusha.org>; Sun, 27 Apr 2025 09:48:16 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1745772491; cv=pass;
        d=google.com; s=arc-20240605;
        b=khKthTcu50tJDuZpbXgPD9QWNF8/kKNYxuz9u5pWpjvgU69qC2WLQWyB1NVgqq4Mla
         0wLsE0PHYiNfq71ophi8+GUTsZEev8lyspTBdo39jSd0oxyba1HkMHxz7DqGE69xvNfe
         QZk+psdQcaVQ6puuRWt+zBv3woa3XIGbZs+giWjTXp44Hu/rp3VJfEZS7z0d5R63b2/g
         3R5F5gx+SdrarX8GwM3cnySBQz5g7xA9pBTlTT2hauWmr7ZL5YRmFQyeOw5iFwOapF2l
         O8i8YLxKwpqYKVEvN4uVVNzMUbd2Y2trAfz8bz+SFM3pja6QykEilDkkH9m0APyzg9xp
         P3Ag==
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:to:subject:message-id:date:from
         :mime-version:sender:dkim-signature:dkim-signature;
        bh=XRoJ20PtAL+iVuE8QoSjMnAD65iFD4kQwc/Pfb5AcYs=;
        fh=aFDcTsE7hWnQnDB9ksOx/SNU9iQ+JgdvrbywRznXv7I=;
        b=O5zYvfh4m1LuJKMLSsiGPZy8LYifNCaaOcFEmLDt4F9+8aPFkkJZwDljrU5WUrqohH
         sjmVnadru4CByc3irHPdTfka+iQ8lDiZOj59H7XYTsV40Cm4id15DkTBmZsRSQqlBL7N
         aU8ThlRdDXpIeZ7TCCt1BH3T+icV78+KYsfJWR3B/4xiG5LLO9yY7r+gCqJdfPGkLuJL
         //Qs9xjxnICJYvITZzpXRz4fjDdwpyrki5BAJKBalCcxUUdEoD2OUyaH6Il6rpKSxFdr
         EYE8MfyZ8SPYjYtsHBiucYTc3HpJwzwTP7f27sgxwJA5ne881PleqCPcMHO3KSmecKW1
         K/IA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=nXV398IR;
       spf=pass (google.com: domain of rsomsen@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) smtp.mailfrom=rsomsen@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=1745772491; x=1746377291; 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:to:subject:message-id:date:from:mime-version
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=XRoJ20PtAL+iVuE8QoSjMnAD65iFD4kQwc/Pfb5AcYs=;
        b=LQA1U7iw+yoaQRdrTd9jbKQcRLJpSm64D5+NzBoH/tqXTC0O8fWhCYogrKgt2eNdDs
         DB1DATd40/88Q4KQ/pmh2j3+ryN507qtM5eVD4l9Ygu4qwe+Wg6v+9jBgXGH0s1JlZyB
         aqBI1rtCl4sJnH89ftUKiBoJMpIid8leC2DLF37/vVG2QsJz+tZ5Saf3amM5GtNjMUqW
         IT9s3unGN9pa4aLf38E/7VEf+4fVV6nSS2uW/b0muwxn+j4zZbBzILk7T3h0w5tAWjQh
         U5p0PvegqiN4oaDWqKMZlxWSN7DCxBMDRlvyriHwU/lnlLmQdAWMgpNlqPzphih+/URf
         Pu7Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1745772491; x=1746377291; 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:to:subject:message-id:date:from:mime-version:from
         :to:cc:subject:date:message-id:reply-to;
        bh=XRoJ20PtAL+iVuE8QoSjMnAD65iFD4kQwc/Pfb5AcYs=;
        b=J+c77odsZiPg1WGri202TccZtDMbZS8SCXv1IW/brdWx7iRU3hbrgHfnCYOrVij0UP
         EjvxGZfiqky+vwR3APdefTy/S/E1fGS5pJykpMtBRM3uVC0iks1bdSmY80fkrgUQHs0/
         S5QzarvBuucu4chIu+z+krL9U7NLpTNtKvlf7Qzvu2Z6bmQufJWxNENdgiVc0NSGXUeh
         Em5SA2ftGVCX/d3jlRqbw5wosKSA2yrlroFYxzxA41+sNMDSf08uFxPUKBX1johHOEDB
         1Rs0XoeZG2JilCJfDZl7XIFSIsMO06SYeZInB8z8tKdYZqAaqFFQNKOXOKSIg0UqS86a
         Y7KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1745772491; x=1746377291;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:to:subject:message-id:date:from:mime-version
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XRoJ20PtAL+iVuE8QoSjMnAD65iFD4kQwc/Pfb5AcYs=;
        b=El8SzT7YfC7UoFlSN+kXISDDVehp0kmz3Vr003QVhf36bBPbrANiA5IhCVLGlsHuxM
         lrLPcWS5vcFc1KWvd76pZysOJvmQrtSaYZiy7WhDdCtY3ssqqYmRDYKVdq2Ru9fXGzyh
         b+nFy9ORPq3MUwv3Q9wVImyj/wEXMAuJYa3LHReHe2W9fN2yLi6TEndHMFOZMboUWNX9
         3mWwbYxTi/HYi1mG+qo4PbhpxSOzMwIHv2GJL7VVfD7chvuvAn597Srreb2F2zy4NKiq
         JWP6JYZcUXK+5UVjRSWjrHGYW7bRpcEJbXSSfB9Xq+D7CIrwPZv8Rc3u8b8glxbDDWHO
         SRLw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCURRTP9+X6St2JSc6zlz1gJZaKndV4xrOJbj2BkY/tg1evQfm1o8oG/pegldR+MsM/WPOntPTlW6qkr@gnusha.org
X-Gm-Message-State: AOJu0Yz/dKrbOLqN0CCw1d/ryUdNDzyEg+Amx8etv0qcj3TTIAJjuyAD
	qfaKQauAel4/ByIkB5vSn6rPRlOVIJ3LlLfrLM21RAgK6BhcpNPM
X-Google-Smtp-Source: AGHT+IF0oMfDPLu/WL6RZHv2/XGwlHMHau3WSGMcTpfF7MXmnGLhuJftkXHQNRox5NCKQuhI7jOu7Q==
X-Received: by 2002:a05:6808:6b96:b0:3f9:4f55:a002 with SMTP id 5614622812f47-401fd6f513bmr3425077b6e.12.1745772490546;
        Sun, 27 Apr 2025 09:48:10 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBE3ghe1OTEQjkz2RitalYF7h/h70DyD60KsyDUHfZ9GXA==
Received: by 2002:a4a:eac2:0:b0:602:40ed:5c6f with SMTP id 006d021491bc7-60643638b4dls824784eaf.0.-pod-prod-06-us;
 Sun, 27 Apr 2025 09:48:06 -0700 (PDT)
X-Received: by 2002:a05:6808:1ddb:b0:3f8:9781:3cc9 with SMTP id 5614622812f47-401fd72693emr3079411b6e.21.1745772486685;
        Sun, 27 Apr 2025 09:48:06 -0700 (PDT)
Received: by 2002:a05:6808:2002:b0:3fa:da36:efcd with SMTP id 5614622812f47-401f2fc0e20msb6e;
        Sun, 27 Apr 2025 09:45:18 -0700 (PDT)
X-Received: by 2002:a05:6e02:168d:b0:3d8:18f8:fae9 with SMTP id e9e14a558f8ab-3d942d59ce1mr59986275ab.6.1745772318074;
        Sun, 27 Apr 2025 09:45:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1745772318; cv=none;
        d=google.com; s=arc-20240605;
        b=kTmLeA2Sc47sv3i3ITNu4cVTkLHEDjlzBYXIf8C2iPr8C1BGzxjAmJFadq65+LM30F
         VpnRLxOLq2YDKN+OE8cTsJzYHwK+mxoyFk6iSfuSKjAsWR2NKTbsMJBYHClSN4DY36TW
         n5zAN6QFlJyltJepoMFDKBrN1xEgqKcOGvvw6jilQo4TqwtYOKd1q/nh5p5QBo0G8suK
         tSZbKTjW/aUkLO/IBfh3jG+9xRZ0DlckHkPVkmMPpqupYa6Hq1jy9M03HF87yCVBkUVI
         hNpfIrMvXDrMgM5HbF1mccEnrkyJxL52049GYmUvfquYWg1G9e9jOOQEURJjDa/+e3u9
         f5sA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=to:subject:message-id:date:from:mime-version:dkim-signature;
        bh=fKoZ52ZxNITYGS3eaCzkZ2ccD8kY8aa7iMWAoqqafKU=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=NtOfU9L+Bo6k5Xvyr08FCzBrrcTPnkSbhYc/VVwMVpEsuidv6CNUxC0bYuLOFTvu+J
         cmS1mUH6HYJzzGPlCS6Vz0A/XYiirxcGkezkVN1f6lHDlUTliZDmO3cQuftGTLNpm9V9
         h7ZKEUyGfi1zuEzuDIjYbATY6ZRrZYFS4alrb+ZOPLdFF5vJBIqL1XUfFn+ZVxMOXkBk
         oYU6me2X82mIC0Z9YcT89ZOCxCB+4ArWOr+ALMmUgZtCiOqV5Axg38guWtsAdjMZfB0y
         Vs2B8rupV6h6o2vMHYYEn+stlvnXSjxzBe8xK2b7cnZxuFGGIQuT4/GhqMRbk4eYUiF4
         0W+Q==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=nXV398IR;
       spf=pass (google.com: domain of rsomsen@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) smtp.mailfrom=rsomsen@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com. [2607:f8b0:4864:20::92d])
        by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-3d9315c02ebsi3107365ab.3.2025.04.27.09.45.18
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 27 Apr 2025 09:45:18 -0700 (PDT)
Received-SPF: pass (google.com: domain of rsomsen@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) client-ip=2607:f8b0:4864:20::92d;
Received: by mail-ua1-x92d.google.com with SMTP id a1e0cc1a2514c-86cce5dac90so1535406241.0
        for <bitcoindev@googlegroups.com>; Sun, 27 Apr 2025 09:45:18 -0700 (PDT)
X-Gm-Gg: ASbGncv2zQ41gawYXyH36X2oXTfW/WczMy7j5RnhCp83ab+5GhykcRcE881O6dkD200
	XpN2NSKfPLL+9yTJlu6eGs+8yFCGHTqU050JdXvi9g2ydN9/d9k+nAcejDRW0TwHpRYZPcjgYnP
	+sSNE2T/qv2DSKwV3gggtBUAQdbGo2frph2VjlS/6DhQjC6kV2+IUQbl4g
X-Received: by 2002:a05:6102:3590:b0:4c1:7a08:9279 with SMTP id
 ada2fe7eead31-4d640d7d8b7mr3411350137.15.1745772317281; Sun, 27 Apr 2025
 09:45:17 -0700 (PDT)
MIME-Version: 1.0
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sun, 27 Apr 2025 18:45:07 +0200
X-Gm-Features: ATxdqUH_8wWTqKshtfKOt4pNB1rPQ7c6vnwqzxzU4rRKNtRXHEcnS-MU9RCwCPE
Message-ID: <CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com>
Subject: [bitcoindev] The Tragic Tale of BIP30
To: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000d495c10633c54a1c"
X-Original-Sender: rsomsen@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=nXV398IR;       spf=pass
 (google.com: domain of rsomsen@gmail.com designates 2607:f8b0:4864:20::92d as
 permitted sender) smtp.mailfrom=rsomsen@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 (/)

--000000000000d495c10633c54a1c
Content-Type: text/plain; charset="UTF-8"

Markdown version:
https://gist.github.com/RubenSomsen/a02b9071bf81b922dcc9edea7d810b7c

### Introduction

In my recent exploration of [SwiftSync][1], I came to the realization that
[BIP30][2] has an unresolved consensus bug. It seems this bug can't be
triggered without a reorg back to 2010, so its seriousness is debatable. We
currently have checkpoints up to 2013, preventing such a reorg. Once we
fully [remove the checkpoints][3], the bug becomes theoretically (not
practically) exploitable.

BIP30 is also a bit of an odd duck in terms of consensus checks in that it
involves the entire UTXO set without being related to the spending of
inputs. This is inefficient, and complicates the implementation of
alternative validation methods such as utreexo, SwiftSync and quite
possibly ZKP systems such as ZeroSync. It would be nice if we could sunset
BIP30 altogether.

Without necessarily advocating for action (the status quo seems quite
tenable), I'd like to lay out possible solutions for both and open up the
discussion.

### 1. Consensus bug

There are two duplicate transactions that BIP30 treats like exceptions. The
last duplicate was the coinbase transaction in block 91880. When this
transaction gets processed, the coinbase transaction in block 91722 is
overwritten. The other instance occurs between these two blocks (91812,
91842).

The problem occurs when we reorg back to a point between block 91880 and
91722. When we rewind the blockchain, previously created outputs get
removed from the UTXO set again. As a result, the overwritten output
disappears from the UTXO set completely. A node that never witnessed the
reorg, however, will still have the UTXO in its set. If subsequently the
UTXO is ever spent, this would result in a fork.

#### Solution A

We could enforce that no reorg can take place between block 91722 and 91880
- you'd either have to reorg all of them, or none. This ensures both
reorged and fresh nodes will not have the problematic outputs in their UTXO
set. Considering this is only ~160 blocks at the low mining difficulty of
2010, this wouldn't be a big constraint.

#### Solution B

When discussing my findings with Sjors Provoost, he pointed out that the
removal of the checkpoints (which can be seen as a hard fork) [that is
being considered][3] also presents a window of opportunity to change the
pre-checkpoint consensus rules - we could fix the bug by no longer removing
the coinbase transaction in case of a reorg of block 91880 and 91842. Aside
from that, Sjors' observation also opens up the question whether there are
other pre-2013 consensus changes we'd want to consider making.

### 2. Sunsetting BIP30's UTXO set check

BIP30 is currently active from genesis until [BIP34][4] activates at block
height 227931 (March 2013). If this block is reorged out, BIP30 remains
active indefinitely. BIP34 has issues of its own that are being addressed
in the [Consensus Cleanup BIP][5] - you could go and read that, I won't go
into too much detail here.

Technically, BIP30 only prevents duplicate _unspent_ outputs. It does this
by checking for each output whether it's already in the UTXO set (this is
the inefficient part), and rejecting the block if it is. The two 2010
duplicates are hard-coded in as exceptions. Under these rules, spending an
output and recreating it is allowed. However, it seems this never occurred.

One last point to address is why BIP34 gets deactivated if block 227931 is
reorged out. The reason for this is because otherwise it'd open the door to
possibly creating outputs prior to BIP34's activation that will conflict
with BIP34's rules for ensuring coinbase transaction uniqueness (the exact
issue the Consensus Cleanup is seeking to resolve).

Ideally, it'd be nice to be able to sunset the BIP30 UTXO set check
completely, ensuring it's no longer required, even in case of a reorg.

#### Solution

Given that we have no duplicates, barring the two exceptions, we could
replace the inefficient BIP30 UTXO set check with a coinbase uniqueness
check. We simply cache the coinbase TXIDs and ensure there are no
duplicates. Doing this until block 227931 results in a modest ~7MB cache.
However, BIP30 might not deactivate, in which case we'd have an
ever-growing cache. This is solvable as follows.

Aside from checking for coinbase uniqueness, we could also check that the
coinbase will not conflict with any future coinbases (i.e. not conflict
with BIP34 as well as the Consensus Cleanup BIP). This ensures BIP34 can
simply activate at block height 227931, regardless of whether there's a
reorg.

### In closing

These were some of the issues with BIP30 and possible solutions. Regardless
of whether we choose to take action, this write-up will serve as a
reference. Thanks to Antoine Poinsot, Pieter Wuille, and Sjors Provoost for
the discussions prior to publishing.

-- Ruben Somsen


[1]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd
[2]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
[3]: https://github.com/bitcoin/bitcoin/pull/31649
[4]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
[5]: https://github.com/bitcoin/bips/pull/1800

-- 
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/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw%40mail.gmail.com.

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

<div dir=3D"ltr">Markdown version:<div><a href=3D"https://gist.github.com/R=
ubenSomsen/a02b9071bf81b922dcc9edea7d810b7c">https://gist.github.com/RubenS=
omsen/a02b9071bf81b922dcc9edea7d810b7c</a><br><br>### Introduction<br><br>I=
n my recent exploration of [SwiftSync][1], I came to the realization that [=
BIP30][2] has an unresolved consensus bug. It seems this bug can&#39;t be t=
riggered without a reorg back to 2010, so its seriousness is debatable. We =
currently have checkpoints up to 2013, preventing such a reorg. Once we ful=
ly [remove the checkpoints][3], the bug becomes theoretically (not practica=
lly) exploitable.<br><br>BIP30 is also a bit of an odd duck in terms of con=
sensus checks in that it involves the entire UTXO set without being related=
 to the spending of inputs. This is inefficient, and complicates the implem=
entation of alternative validation methods such as utreexo, SwiftSync and q=
uite possibly ZKP systems such as ZeroSync. It would be nice if we could su=
nset BIP30 altogether.<br><br>Without necessarily advocating for action (th=
e status quo seems quite tenable), I&#39;d like to lay out possible solutio=
ns for both and open up the discussion.<br><br>### 1. Consensus bug<br><br>=
There are two duplicate transactions that BIP30 treats like exceptions. The=
 last duplicate was the coinbase transaction in block 91880. When this tran=
saction gets processed, the coinbase transaction in block 91722 is overwrit=
ten. The other instance occurs between these two blocks (91812, 91842).<br>=
<br>The problem occurs when we reorg back to a point between block 91880 an=
d 91722. When we rewind the blockchain, previously created outputs get remo=
ved from the UTXO set again. As a result, the overwritten output disappears=
 from the UTXO set completely. A node that never witnessed the reorg, howev=
er, will still have the UTXO in its set. If subsequently the UTXO is ever s=
pent, this would result in a fork.<br><br>#### Solution A<br><br>We could e=
nforce that no reorg can take place between block 91722 and 91880 - you&#39=
;d either have to reorg all of them, or none. This ensures both reorged and=
 fresh nodes will not have the problematic outputs in their UTXO set. Consi=
dering this is only ~160 blocks at the low mining difficulty of 2010, this =
wouldn&#39;t be a big constraint.<br><br>#### Solution B<br><br>When discus=
sing my findings with Sjors Provoost, he pointed out that the removal of th=
e checkpoints (which can be seen as a hard fork) [that is being considered]=
[3] also presents a window of opportunity to change the pre-checkpoint cons=
ensus rules - we could fix the bug by no longer removing the coinbase trans=
action in case of a reorg of block 91880 and 91842. Aside from that, Sjors&=
#39; observation also opens up the question whether there are other pre-201=
3 consensus changes we&#39;d want to consider making.<br><br>### 2. Sunsett=
ing BIP30&#39;s UTXO set check<br><br>BIP30 is currently active from genesi=
s until [BIP34][4] activates at block height 227931 (March 2013). If this b=
lock is reorged out, BIP30 remains active indefinitely. BIP34 has issues of=
 its own that are being addressed in the [Consensus Cleanup BIP][5] - you c=
ould go and read that, I won&#39;t go into too much detail here.<br><br>Tec=
hnically, BIP30 only prevents duplicate _unspent_ outputs. It does this by =
checking for each output whether it&#39;s already in the UTXO set (this is =
the inefficient part), and rejecting the block if it is. The two 2010 dupli=
cates are hard-coded in as exceptions. Under these rules, spending an outpu=
t and recreating it is allowed. However, it seems this never occurred.<br><=
br>One last point to address is why BIP34 gets deactivated if block 227931 =
is reorged out. The reason for this is because otherwise it&#39;d open the =
door to possibly creating outputs prior to BIP34&#39;s activation that will=
 conflict with BIP34&#39;s rules for ensuring coinbase transaction uniquene=
ss (the exact issue the Consensus Cleanup is seeking to resolve).<br><br>Id=
eally, it&#39;d be nice to be able to sunset the BIP30 UTXO set check compl=
etely, ensuring it&#39;s no longer required, even in case of a reorg.<br><b=
r>#### Solution<br><br>Given that we have no duplicates, barring the two ex=
ceptions, we could replace the inefficient BIP30 UTXO set check with a coin=
base uniqueness check. We simply cache the coinbase TXIDs and ensure there =
are no duplicates. Doing this until block 227931 results in a modest ~7MB c=
ache. However, BIP30 might not deactivate, in which case we&#39;d have an e=
ver-growing cache. This is solvable as follows.<br><br>Aside from checking =
for coinbase uniqueness, we could also check that the coinbase will not con=
flict with any future coinbases (i.e. not conflict with BIP34 as well as th=
e Consensus Cleanup BIP). This ensures BIP34 can simply activate at block h=
eight 227931, regardless of whether there&#39;s a reorg.<br><br>### In clos=
ing<br><br>These were some of the issues with BIP30 and possible solutions.=
 Regardless of whether we choose to take action, this write-up will serve a=
s a reference. Thanks to Antoine Poinsot, Pieter Wuille, and Sjors Provoost=
 for the discussions prior to publishing.</div><div><br></div><div>-- Ruben=
 Somsen<br><br><br>[1]: <a href=3D"https://gist.github.com/RubenSomsen/a61a=
37d14182ccd78760e477c78133cd">https://gist.github.com/RubenSomsen/a61a37d14=
182ccd78760e477c78133cd</a><br>[2]: <a href=3D"https://github.com/bitcoin/b=
ips/blob/master/bip-0030.mediawiki">https://github.com/bitcoin/bips/blob/ma=
ster/bip-0030.mediawiki</a><br>[3]: <a href=3D"https://github.com/bitcoin/b=
itcoin/pull/31649">https://github.com/bitcoin/bitcoin/pull/31649</a><br>[4]=
: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki=
">https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki</a><br>[5]=
: <a href=3D"https://github.com/bitcoin/bips/pull/1800">https://github.com/=
bitcoin/bips/pull/1800</a></div></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/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw%40mail.g=
mail.com</a>.<br />

--000000000000d495c10633c54a1c--