From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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 Date: Sun, 27 Apr 2025 18:45:07 +0200 X-Gm-Features: ATxdqUH_8wWTqKshtfKOt4pNB1rPQ7c6vnwqzxzU4rRKNtRXHEcnS-MU9RCwCPE Message-ID: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
Markdown version:
https://gist.github.com/RubenS= omsen/a02b9071bf81b922dcc9edea7d810b7c

### Introduction

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'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.

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.

Without necessarily advocating for action (th= e status quo seems quite tenable), I'd like to lay out possible solutio= ns 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 tran= saction gets processed, the coinbase transaction in block 91722 is overwrit= ten. The other instance occurs between these two blocks (91812, 91842).
=
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.

#### Solution A

We could e= nforce 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. Consi= dering this is only ~160 blocks at the low mining difficulty of 2010, this = wouldn't be a big constraint.

#### Solution B

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'd want to consider making.

### 2. Sunsett= ing BIP30's UTXO set check

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't go into too much detail here.

Tec= hnically, 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 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>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 uniquene= ss (the exact issue the Consensus Cleanup is seeking to resolve).

Id= eally, it'd be nice to be able to sunset the BIP30 UTXO set check compl= etely, ensuring it's no longer required, even in case of a reorg.
#### Solution

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'd have an e= ver-growing cache. This is solvable as follows.

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's a reorg.

### In clos= ing

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.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw%40mail.g= mail.com.
--000000000000d495c10633c54a1c--