From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 05 Feb 2026 14:52:20 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vo8Cx-0006bP-BJ for bitcoindev@gnusha.org; Thu, 05 Feb 2026 14:52:20 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-4042356948fsf6788370fac.3 for ; Thu, 05 Feb 2026 14:52:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770331933; cv=pass; d=google.com; s=arc-20240605; b=BBH00nNd7ydpK2TT14dmKOsBsHUEUS22B0uM8r55pl0I8fzDjVKxa8IgpCZT5Gwwr2 LqEgA1J6DYj5bdQ3xkJyuhNTT0CxPMw1a3YV6i1MiiTgaukMAFRr1w0cDskYhvo+lvtU 2bpakh0SNg0hCMMCsBalACgX7QAduNTYjHpZUGNVZaBXz9n5bT9YCuvP/R0RR3ymPqeK YWE5gmhansSVJKGQZTs4jNTXNXqjtdE1yASyZTp++PpvyZwc7UtMRxy7Tc5p9QxnMcle QePH0REA34C/sOnbQN7pv+V4AbM7iKVBSHiPD5MMskPpWMf+0VmEIGeE61L+04tGi6b7 BpDg== 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:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=xNTtvf0QxaI2/Q/vDJTISa/Y1TWDIIutx4fNiyg9WAI=; fh=AMT0ZNQgA5TKmYenPXB0pym5jbW6dwynoGrWWK7E1ww=; b=bUUoAxLarjNMrDqxLlAdCHlWT9NLt2qcFHE+tiguHgpxVRWWaEqzSrUijIurK4W0FS v99HSM8cJIPWXj3bzZkzquIrAeI9wn1HXyzWGH2R4q3p+Q7q2q48j2uKWgXopMDY/nvw kBFJ758WtVfNXCw99KJUy+wa/cpndAjmgRoaQIBfDlzxasTkSLDdtyi9UNCHw22DT2GN vDWTgELFM7YAbyNRsjJWYIPGPuQWqztht8Uz3wIeGDX3VlKR2Ro2ScDACfwhr/CGeEzK FV+68pYvfK8Esnbsed0fMOjTSt57vUzpggimS484GGbYLt6pAKagXHxqwKmE5NeUMHH6 4NEQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Iw+uuyB4; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770331933; x=1770936733; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=xNTtvf0QxaI2/Q/vDJTISa/Y1TWDIIutx4fNiyg9WAI=; b=e/EnxvOzVujb/kQ8mE1z83NSa7F4vY3O8TcrgRzMpElv+bu0uQyNfXqkC2Yc2hAtHB 4IN5QIBrowFixF7B1C5VZGp8binfOJhPvX/9bQ62Rh3L8LksKjh1rgXgjOUngxQiVgAa ++nN+rXzoOvG2w/2+jsbM357kMkFPCaL+FqQ8BwqtIKCZedQbx17jFOxNr1OpRt7qzmF lQXdic0BlhZrleBHyaRn+kG+gSoknNnEA0N8uveCugD9WGxkbMRyMxW72HYzCgvQR58k BLH6EqYDy0td2G+cwKpE4rGbeKXy041/j7gsoVYXXo6ukWMUNGDS7QuUXzBk1rGWhHm5 gerg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770331933; x=1770936733; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xNTtvf0QxaI2/Q/vDJTISa/Y1TWDIIutx4fNiyg9WAI=; b=lOOqBDPxwi812pcUwt+toN8qkEbpxnLrn3s/uHXUtUT0DDurMx89KC0wFYak35KHA5 MIsaKGgPKwlnmrwsqXaZINvdnvZ33eT1hRVPtDXw3nd5pqE5pzxefuVExVIZVrj6hC8B eEtBPlWWeGWLyZPkofeMh+PUsCUX3psglweeeZnW1kD+AEjpNDp14NKCyPUCw3l5rrGl ItjY+iYKtQnNMcc4EJ0pCS88A1EiU5LSNmu2cGCjuBMv8UYNll19Pa8fTxyN4MDgny4P S61NRWrgLZpydw/btWJpbX5MGI2747sBIzyhEbMJTO/66iQMchYoKB3+TM/zrVO7tfC8 /T0Q== X-Forwarded-Encrypted: i=2; AJvYcCX2uXEJZqLqBE540xyaB1fMt2MNnprHMp8y82t6Mx8e627QsM6qqq3wmtjeiQ8WyDB0Lrs9z9doRjV2@gnusha.org X-Gm-Message-State: AOJu0Yx2WvxzbuyQIyJrvPEX017b/QC2yCCZQ8XRBGMfbYptPkA2TZ9k 8Heh+EJYD21S4A+W+tYYGTX/O9YyIKJ9RdaXUqcHumqcbMU+rI3x9gJ6 X-Received: by 2002:a05:6870:8a23:b0:3ff:4ab3:941c with SMTP id 586e51a60fabf-40a97008a59mr533031fac.40.1770331932907; Thu, 05 Feb 2026 14:52:12 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+E24chrX7zZF2vR7r/Dmc4J//Dz+Q8wjlH/rizUHvCc2Q==" Received: by 2002:a05:6870:194d:b0:3ff:9f0a:cf52 with SMTP id 586e51a60fabf-40a74d8da96ls999811fac.2.-pod-prod-07-us; Thu, 05 Feb 2026 14:52:07 -0800 (PST) X-Received: by 2002:a05:6808:c2ac:b0:459:b48b:d51e with SMTP id 5614622812f47-462fcb63e03mr612699b6e.24.1770331927882; Thu, 05 Feb 2026 14:52:07 -0800 (PST) Received: by 2002:a05:600c:4c17:b0:477:b663:eee5 with SMTP id 5b1f17b1804b1-4832008efaems5e9; Thu, 5 Feb 2026 14:48:44 -0800 (PST) X-Received: by 2002:a05:6000:2411:b0:435:a4a9:6f79 with SMTP id ffacd0b85a97d-4362933bef4mr1081712f8f.8.1770331722501; Thu, 05 Feb 2026 14:48:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770331722; cv=none; d=google.com; s=arc-20240605; b=hQFl08XOERmt9vpuON7Ptx4lUd4XXoERkRvt1JgkqwvX6geWS+xKd+M/L78AlqFl8C DEklaiz3pATg7BeS4/E1Sfjc0cEonGH0tnXxYZ4tQ/juOPiTehqYfCsZ79JNdEwgSQVM ZYvxGb6x75Zd1mQV1tXsS5iKHMBX81K8y6yvUqfodwmCzp2Orl3SrR+KlmkE2k2KaRJI yTw1hvlni2i8dzk/k8uDfnOp8TIJ6o/sKjjCe3/bQn9/w4zjNSUkgUWmTfI2koyuOSvY Tg/MRmJA/iyA+2pBiqrhML9KBgPVuuquXO9G4hcOU0I57cUZsFWjDSmA0wZd5bOj08Su jzDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=ggTp73VEd3YT9WYjcJKCMeO7FamM+GN/Wz1WxDAuKps=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=CWj6jNiVdNQp2h7U5k7I3mE7TbCGqwGOi5Avgi7W9S+NNN/+KhCr6jHWWckEG3lj5T Oyx95FeM0xdSrY9UZWNsGNK+rc56KEX8Vr+E010abKnS/NuljMRDvrPMZG//HOnHb3ZK mY24I2aEKBAv1OeMqmznCslcDnlujvnzHs5oVoEyuxlwLbV7ggfax9eqk6EpJq9llf5r yqPD/VRlvpwXmF9oam7zTIrmvQyPxC7JDdLpj7lhQUlUHrdCOEHj74nRbYhCE4HBOVfx z7a3PChA99KyNdocj8kAQ2W2foq9dTWraVIa3hXSoSeIqkEKmpgddHeV1a+8WtAQD62w JPcA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Iw+uuyB4; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-43629b6e4dasi12672f8f.8.2026.02.05.14.48.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 14:48:42 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22; Date: Thu, 05 Feb 2026 22:48:37 +0000 To: Antoine Riard From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Addressing remaining points on BIP 54 Message-ID: <0Gc3rCZzaVbzL88b9G3EDjXdayArs8JtirCO2nmmMVLDgbxovIEu7-hhQp0G4wPnEB3YABywEppEFbC-zSudJUiR7HW680kM6LWtHDmp_Hc=@protonmail.com> In-Reply-To: References: <05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com> <9C946151-D6DD-4CB7-B524-15FD9F625D9D@sprovoost.nl> <492f9bba-8a1f-4fa2-8618-98bd564a6178@murch.one> <1B807731-DC2A-4E59-B462-5C210EF1FB73@sprovoost.nl> <_C0iWeaJ-v24dZgcdCnKZKEgK9E493DmpG_-wD1NZnOAuECi97dZpVLuZxkONIfZjTe7km_TWFdSFfmSzVWfJ5Lkz6JTc8JwDOTg9XAInVo=@protonmail.com> <1dd74f45-bd0a-4fd7-bf80-56a3b2a44128@murch.one> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 1975903add004236eaae5cdf7e735ce9cdf623fd MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Iw+uuyB4; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) Hi, Thanks for your careful review of our BIP. There still appears to be some confusion around the rationale for also cons= training the nSequence, which suggests the explanation needs to be clearer. I=E2=80=99ve noted this= in my collected feedback for the BIP [0] and will restate the rationale in more detail below. The purpose of constraining the nSequence of coinbase transactions is to en= sure that timelock validation is performed. An nSequence set as final (i.e. equal to 0xfffffff= f) allows timelock validation to be bypassed. Enforcing timelock validation gives us a context= -independent guarantee when validating a block that no past block in the chain could possibly have= had the same pair of nLockTime and nSequence. Therefore, assuming SHA256 isn=E2=80=99t broken, t= he txid of the coinbase transaction in the block being validated is guaranteed to be unique. Of course, we already know that no block pre-BIP 34 activation had its nLoc= kTime set in the historical chain [2]. However, being able to state that post-BIP 54 activat= ion no coinbase transaction can possibly be a duplicate is a useful reduction in complexity= . For instance, if BIP 54 activation height ever gets buried in Bitcoin Core, the BIP 30 check could = just be disabled past this height instead of having to figure out if we are on a chain that conta= ins the historical BIP 34 activation block hash [3]. Hopefully this clarifies the rationale. I=E2=80=99ll now respond to some sp= ecific points from your email. > With BIP 30, there is now a check at block validation to reject as invali= d any > block posterior to the BIP activation cutoff (March 15, 2012, 00:00 UTC) = [0]. Technically, as per the code you point to, BIP 30 is enforced from genesis = in Bitcoin Core with the exception of the specific blocks at height 91,842 and 91,880 in the histori= cal chain. > the only implicit mentioning I'm seeing of this problem, is here [3], it = doesn't seem it has been > very peer reviewed, less even said to be documented in the BIP rational o= r the implementation. Your point that the BIP and code documentation could expand on this aspect = is well taken. However it is incorrect to say it's only been mentioned implicitly by AJ in this comme= nt. He later suggested to me to also constrain the nSequence in direct communication, and i publicly = shared my decision to include his suggestion in the BIP in the Consensus Cleanup thread on Delvin= g [4], the same same thread you point to. In this post i explain the rationale for this decision= , which is essentially the reasoning i presented at the beginning of this email. Furthermore, the BIP also explicitly gives this rationale. It reads "There = are multiple ways of achieving this, but setting and enforcing the timelock for the coinbase tra= nsaction makes it so all coinbase transactions past Consensus Cleanup activation could not have been= valid before this height and therefore cannot be a duplicate." And then it links to a footnote that = goes into greater details about timelock enforcement: "Technically it could be argued a duplicate cou= ld in principle always be possible before block 31,001 when nLockTime enforcement was originally soft= -forked. But treating coinbase transactions as not having duplicate past Consensus Cleanup activa= tion would be consistent for any implementation which enforces nLockTime from the genesis block, whi= ch is the behaviour notably of Bitcoin Core but also of all other implementations the authors a= re aware of." > And therefore, the nSequence field can be preserved as future extranonce = (-- while it would be > still worthy to have a network-wide policy rule to avoid intempestive usa= ge of the field). I assume you mean default Bitcoin Core mining policy here? Talking about ne= twork wide policy for transactions that don't get relayed is a bit confusing. Best, Antoine [0]: https://github.com/bitcoin-inquisition/bitcoin/pull/99#discussion_r263= 6788599 [1]: https://github.com/bitcoin/bips/pull/2015#issuecomment-3773345379 [2]: In fact, the nLockTime of all coinbase transactions in the 227,835 fir= st blocks in the historical chain are all set to 0. [3]: https://github.com/bitcoin/bitcoin/blob/28d860788286ec31981f5509a8cbe6= a9ba4cddc5/src/validation.cpp#L2391-L2461 [4]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/79 On Thursday, January 29th, 2026 at 11:13 PM, Antoine Riard wrote: > Hi, >=20 > > "that giving meaning to the coinbase transaction nLockTime is undesirab= le" >=20 > On the rational of asking the block height to be in the coinbase's nLockt= ime, > to enforce coinbase uniqueness in a post-BIP34-implies-BIP30-limit (i.e h= eight > =3D 1,983,702), I think there is a point that would be valuable to clarif= y and > that is not documented in the BIP. >=20 > Let's remind the problem solved with BIP 30. Originally, since genesis, c= oinbase > and spending transactions identifiers were able to be duplicated. That me= ans, > accidentally, an ulterior coinbase transaction was able to overwrite an u= nspent > coinbase tx. E.g, if you have block N=3D50 with coinbase tx_id=3D0xbeef a= nd if this > transaction is unspent at block=3D100, a miner could generate a block wit= h coinbase > tx_id=3D0xbeef _again_ and erase the coinbase output included in an anter= ior block. >=20 > With BIP 30, there is now a check at block validation to reject as invali= d any > block posterior to the BIP activation cutoff (March 15, 2012, 00:00 UTC) = [0]. > This uniqueness validation has been then enhanced with BIP34, of which th= e two > problems it aims to solve was to introduce a network-wide mechanism to up= grade > blocks and transactions and enforce block and coinbase uniqueness. Solvin= g the > second problem is a partially overlapping set of the BIP 30 implemented s= olution > [1]. >=20 > However, and what is the motivation for including the block height in the= coinbase > transaction as part of the BIP54 consensus cleanup, there are some pre-BI= P34 > activation height coinbase transactions of which the BIP34 solution, i.e = requiring > a CSscriptSig to commit to the block height, are violating historically v= iolating > said solution [2]. Therefore no optimized validation could be done in the= future for > those BIP-34 historical transactions and BIP54, by mandating another uniq= ueness > mechanism than the BIP34 one, would allow to get rid off the BIP30 foreve= r. >=20 > Problem, and that's where the BIP54 document and its implementation is si= lent, > there is the potential issue of historical BIP34-violating coinbase trans= actions > (i.e with a CScriptNum[..] =3D 1,983,702+) where the nLocktime field has = a value > equal or superiror to the "post-BIP54 activation height". While coinbase = finality > has always been enforced, if the coinbase's unique nSequence field is set= to > CTxIn::SequenceFinal, the nLocktime should be ignored (see `IsFinal()`'s = code > comment "in which case nLocktime is ignored"). >=20 > While, I have no checked yet if the behavior always hold on all version o= f the code > (it's all `ContextualCheckBlock()`), the only implicit mentioning I'm see= ing of > this problem, is here [3], it doesn't seem it has been very peer reviewed= , less > even said to be documented in the BIP rational or the implementation. >=20 > Present coinbase uniqueness implementation asks for the nSequence field t= o be > also set to SequenceFinal, but given the goal is coinbase uniqueness (and= not > timelock semantics, as it would be for any other transaction), I don't be= lieve > it's necessary to set the sequence field to final. And therefore, the nSe= quence > field can be preserved as future extranonce (-- while it would be still w= orthy > to have a network-wide policy rule to avoid intempestive usage of the fie= ld). >=20 > For where encoding the uniqueness of the coinbase and the arguments that > have been raised so far in the thread, I'm still favoring the coinbase ov= er > the additional op_return field, nLocktime is already a mandatory transact= ion > field so it's more information-theoretic space efficient. As I was raisin= g in > a previous comment, I don't think there is an additional risk of cryptoec= onomic > kind of attack, where the coinbase time finality could be used, it's alre= ady > implicitly possible for all post-BIP34 coinbase transactions. >=20 > Best, > Antoine > OTS hash: f4d42a800a2b6672609b48097a25d961840d7b91cfc5e9caffff65ecd7533dd= 5 >=20 > [0] bitcoin-inquistion, commit 8d513a0, validation.cpp L2591 > [1] bitcoin-inquisition, commit 8d513a0, validation.cpp L4300 > [2] bitcoin-inquisition, commit 8d513a0, validation.cpp L2554 > [3] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/6 > Le Wednesday, January 14, 2026 =C3=A0 6:59:48=E2=80=AFPM UTC, Murch a =C3= =A9crit : >=20 > > Ah right, the Merkle root is calculated based on the stripped > > transaction, and therefore AJ=E2=80=99s idea works fine. Nevermind, car= ry on! > >=20 > > Thanks, > > Murch > >=20 > > On 2026-01-14 07:33, Antoine Poinsot wrote: > > > Thanks everyone for the comments. > > > > > > Sjors, transactions are serialized in modern blocks as described by M= urch. > > > > > > Murch, for the purpose of computing the Merkle root transactions are = serialized without witness data. > > > > > > Best, > > > Antoine > > > > > > > > > > > > On Wednesday, January 14th, 2026 at 5:23 AM, Sjors Provoost wrote: > > > > > >> Hi Murch, > > >> > > >> You're referring to the "serialization with witness data" defined in= BIP 141. > > >> > > >> But that's not how the transaction is serialised in a block, since t= he witness is > > >> segregated. > > >> > > >>> The witness is committed in a tree that is nested into the block's = existing > > >> merkle root via the coinbase transaction for the purpose of making t= his BIP > > >> soft fork compatible. A future hard fork can place this tree in its = own branch. > > >> > > >> As long as the miner doesn't touch the SegWit OP_RETURN , which also= commits > > >> to the coinbase witness, it can safely use the legacy transaction se= rialisation. > > >> > > >> - Sjors > > >> > > >> [0] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#t= ransaction-id > > >> > > >>> Op 14 jan 2026, om 01:23 heeft Murch mu...@murch.one het volgende g= eschreven: > > >>> > > >>> Hi Sjors, > > >>> > > >>> On 2026-01-08 00:30, Sjors Provoost wrote: > > >>> > > >>>> The approach suggested by Towns [4] of appending a 0-sat OP_RETURN= output with > > >>>> padding so a 4-byte nonce lands in the final 64-byte SHA256 chunk = is probably > > >>>> better, but not because like nLockTime it has a small hashing mids= tate > > >>>> benefit. It's easier to implement. > > >>>> I can=E2=80=99t access Delving right now to read AJ=E2=80=99s comm= ent, but a small nit on the idea of using an additional output: BIP=E2=80= =AF141 requires coinbase transaction inputs to have a 32-byte witness. Sinc= e the witness section follows the outputs in the serialization, the bytes b= efore the `nLocktime` in a coinbase transaction are the witness of the coin= base input, not the last output script. > > >>> -Murch > > >> -- > > >> You received this message because you are subscribed to the Google G= roups "Bitcoin Development Mailing List" group. > > >> To unsubscribe from this group and stop receiving emails from it, se= nd an email to bitcoindev+...@googlegroups.com. > > >> To view this discussion visit https://groups.google.com/d/msgid/bitc= oindev/1B807731-DC2A-4E59-B462-5C210EF1FB73%40sprovoost.nl. >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/e758af9b-72fc-4fdd-8e07-e1126635780an%40googlegroups.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/= 0Gc3rCZzaVbzL88b9G3EDjXdayArs8JtirCO2nmmMVLDgbxovIEu7-hhQp0G4wPnEB3YABywEpp= EFbC-zSudJUiR7HW680kM6LWtHDmp_Hc%3D%40protonmail.com.