From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 07 Jan 2026 20:36:21 -0800 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vdhkx-0001qn-KX for bitcoindev@gnusha.org; Wed, 07 Jan 2026 20:36:20 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3fef084337fsf2569422fac.1 for ; Wed, 07 Jan 2026 20:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1767846973; x=1768451773; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=iWiWKUeg6egu1YO1K2EXAEJp0wk/+KfQ+g70IVK6vhM=; b=ZJIcNvYRRyL0YzxKZBjrovH6H8OMsSiRICrfaAYcJN2ki7yqG7adTJQyJ+VEajc++9 Tvwj3zLX2MFzy97vKuY0dyvBq/eBWeHDUS/g4iJT5BAWtpHPG9CwRZMBRv6Z7AMGEdGG iYw+76UumV9Sm7uL42ToR0NtLuhuMh5+gxGaaqZfndVLwma4NfAUsOsUcGGdrcbHyODc 1FbZJs+zbVNr3tutLNSrLbMlKl54SsAKjIm+Zo2e5fnHMQKxjZAY3BPaFEOaIHfMsw6n lD3qDPNEObWJLxswg7Alq/KCjSQNbXwh/TIcWsulQa0c6aPNAFF5KatacPEGNFW6+bj/ 6raQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767846973; x=1768451773; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=iWiWKUeg6egu1YO1K2EXAEJp0wk/+KfQ+g70IVK6vhM=; b=LdvvhWJz4rl5IKD6hAUWqShXlEiA6v9iUePLus94fpJ1wNww16IFozAJ6gbpJzykVU HcaMpOWXNmiZeY+iSX7qPGmZ7KkUqXoYm8Ek0iGcvZ4aJFf7X+Hh+NRDtcmTQNQrMDJR H4Sj2QZJgjYwVY3tdlUPrjDYroBU0z4fE0dd8AziiHF7ou0LtKeXQoBx6jbvMvsrrnvJ GsT0w2ZBBJUgPjownhJAnX9el0f2CrrfRVqQRvQc74chcLc8sPJaOpnfsrZWpJhGn7si I6I05MbybvVHHJdmZk1o0xiPp5zSYEQ6KwILtOfvxIveHjhGzoMS9S6P40QIg/HDyWNi 22og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767846973; x=1768451773; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=iWiWKUeg6egu1YO1K2EXAEJp0wk/+KfQ+g70IVK6vhM=; b=ZNW445u54p1aFS1Gm8LDXDTjq07TTItrLkwFjvHEBX0XzU/fm4aCAR9YetqG3I/IRa IvyyZrobOjK9LNa91prL5pRLWmmvttLH4h/hJHdAVA7zz2i8/2mSlEEtwEv+T7CHnNMP 8KXHiDEjhtS1wmraV+znEzAVuKryjlcR/5VuGlr2kxP6qTTs8gCKuIZAGl9//GLGy2nW pdd77K0XX9TMoqAmy2ZXE5v0QBJX91uzeQ1bq7UTfZfPwn4IkqY0PQ0fc31zGVeNQG5u 9aJ0cf1Ug43EmAaswweOPyFCZwOxUln2+WoN3y66y7c0k+ipiVAXDDJCusS83mogO+eD GTGg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV1YDFH3T4JjvfnRgtCbZAbQjRAtriOK9VTHs7ZTHZR46idqkIWHitRdXU9ufffKntnFF9sAsZXKWOr@gnusha.org X-Gm-Message-State: AOJu0YxSFCRPMrOLSoLnXRp1pI9SOPR0N58xE0sDeftAczJg9mBbE3Jy A/FEkx59B8F9oSHhqjewPKAtDookY9hsDzBOOc9nlwS9D8D6kdUcKpQ0 X-Google-Smtp-Source: AGHT+IECiXomSpbD7+LUbr/4wiN1CNYfD537g0L7scWyBqdo2Lhy1dniSoPs2Fw0AZarht0fOZTS7A== X-Received: by 2002:a05:6870:1711:b0:3f9:f8bb:aee6 with SMTP id 586e51a60fabf-3ffc0c7162amr2268845fac.54.1767846972674; Wed, 07 Jan 2026 20:36:12 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYRG8Tt/ZDjPg5OLD6Bctwc9ScegTMI+fHUyW0QcYAFkg==" Received: by 2002:a05:6870:934b:b0:3fd:e7af:6a2 with SMTP id 586e51a60fabf-3ffc01eb702ls364524fac.1.-pod-prod-00-us-canary; Wed, 07 Jan 2026 20:36:08 -0800 (PST) X-Received: by 2002:a05:6808:4f1f:b0:450:aef0:ffd0 with SMTP id 5614622812f47-45a6b84c9a8mr2744630b6e.29.1767846967699; Wed, 07 Jan 2026 20:36:07 -0800 (PST) Received: by 2002:a0d:e506:0:b0:790:b655:de0c with SMTP id 00721157ae682-790b655e72cms7b3; Wed, 7 Jan 2026 20:29:30 -0800 (PST) X-Received: by 2002:a05:690e:1281:b0:644:6ce2:4a34 with SMTP id 956f58d0204a3-64716770e95mr3904930d50.32.1767846569313; Wed, 07 Jan 2026 20:29:29 -0800 (PST) Date: Wed, 7 Jan 2026 20:29:28 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Addressing remaining points on BIP 54 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_692506_1983909474.1767846568863" X-Original-Sender: antoine.riard@gmail.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 (/) ------=_Part_692506_1983909474.1767846568863 Content-Type: multipart/alternative; boundary="----=_Part_692507_1411469551.1767846568863" ------=_Part_692507_1411469551.1767846568863 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Poinsot, Thanks for the update. If I'm understanding correctly Luke's concern, currently the coinbase's scriptSig is used to store an extranonce. One has to observe first there is no consensus limit on the size of a transaction, which holds for the coinbase tx too, a fortiori there is no limit on the extranonce size a miner could fit in the scriptSig. The point being made is that the nLocktime field of the coinbase transaction could be used as a more efficient extra nonce due to the positional location of nLocktime in a serialized coinbase being one of the latest message block to be processed [0]. Nothing prevent a miner in already doing this and draw a speed advantage from the diminished computational work. I have not looked into CGminer code or one of its derivative forks, if there is an implemented option to do=20 that, but yes there could be non-published existing mining firmware doing it.=20 IIUC, BIP54 would nullify this theoretical "speed advantage" for all miners. Now, there could be an argument ecosystem-wise to let the nLocktime free, as who say speed advantage say less energy consumed network-wide (-- but isn't that a better outcome to maximize the energy burnt network-wide, even if it's probabilistic ?). One alternative design would be to store the height commitment in the commitment extension introduced by BIP141 [1]. In my understanding, as it has been pointed out by other minds in the design process about the actual proposal to put the height commitment in the nLocktime field,=20 in the eventuality of more than 1 commitment being introduced, a naive design would come with the burden for non-upgraded nodes to have data availability to all the merkle path to validate a specific soft-forked commitment. So a node could not just implement consensus validation rules for SF #2, without getting the merkle tree data for SF #1. It doesn't sound that this concern could be alleviated by making the "witness reserved value", a slot vectors of commitments (e.g=20 type-length-value), rather than a merkle tree, if you don't know the meaning of a commitment, there is no need to fetch over p2p the undefined data, just jump to the next slot. While indeed, such design would deserve better precision, I'm thinking it could be another option about where to fit the height=20 commitment. On the downside, as it has been pointed too before, it would render the validation done by embedded signers more complicated, as one would have to give the header + merkle proof for the coinbase tx inclusion + the=20 coinase tx + the witness reserved value commitment + the field in itself. Now, those embedded signers, for the most sophisticated one e.g validating=20 lighting channels, due to space constraints, are only validating a subset of the consensus rules (e.g it doesn't validate the lack of inflation). So it's unclear to me, that you would strongly clear about validating the height commitment of the coinbase tx (ensuring the lineage of the utxo down to your smart contract is sane ?). An alternative can be to split the u32 nLocktime field in a u24 | u8, with the u8 field being reserved as an extranonce. An u24 would waive the proble= m for few more hundreds of years. So it would be a 40-bit total nonce, made of a header's nonce + 8 bits nonce. I've not looked into historical blocks to see what is the extranonce size used in the scriptSig in average. About the second concern, i.e Jeremy / Eric's one, i.e the risks of creating a validity "seam" that might introduces unforeseen complexity in the design of smart contracts. Made the point w.r.t to the 2500 new sigops limit for legacy tx, but the 64-byte limit size comes with a corner case, when you're burning funds as additional fees to bump the confirmation of a time-sensitive tx. Post-BIP54, that means any tx smart contract=20 toolchain has to be updated to rule out this tx size (e.g for lightning, at=20 `closing_signed` processing). While indeed, not ruling out the 64-byte case might be only a benign effect= , evluating when you should do it or not ask for a lot of inner know-how from the PoV of the smart contract toolchain developer. And this is not somethin= g necessarily done once for all, the level of adversarial collaborative tx malleability that can be achieved by the counterparty can be silently call to re-evaluation e.g when you're upgrading your protocol form using p2wsh to p2tr where the signature size changes. Anyway, my thinking is that a fix long block validation time is a really=20 must have, fixes for difficulty adjustment exploits is also very good to have=20 (what was Vertcoin that got exploited on this ?), I'm more skeptical on the=20 merkle tree malleability fix (for protocols using SPV proofs, it can be mitigated by=20 additional check within their toolchain) and for the fix of duplicate coinbase=20 transactions, the fix design could be improved. As I echoed previously, we can still assign a deployment bit to each=20 proposed fix, while it's very obviously more coordination work ecosystem-wise in the=20 hypothesis of multiple distincts activations, this also let more room to get in=20 earlier the consensus cleanup more serious. Not a hill I'm ready to die on, but IMHO=20 separating the consensus changes in 4 distinct proposals is better development and=20 deployment practice (-- if social consensus is gathered to have all the fixes in one= =20 deployment we can still have one signaling bit and activation sequence). Best, Riard OTS hash: 808f61fd6438ac7a9e4a2c07a2665e6e7dffb7f831897f0dcbb8134cffad5d0b [0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf [1] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki [2]=20 https://gnusha.org/pi/bitcoindev/aa916637-befa-795a-caa1-e5ad50ce63c8@elect= rum.org/ Le jeudi 1 janvier 2026 =C3=A0 14:33:36 UTC, Antoine Poinsot a =C3=A9crit : > Hi everyone, > > Some previously raised points regarding BIP 54 have come up again=20 > recently, and > i would like to address them here for the record. > > The first one is Luke Dashjr's comment [0] that giving meaning to the=20 > coinbase > transaction nLockTime is undesirable as it's the ideal position for an > extranonce. But this extranonce only enables a theoretical optimisation= =20 > for a > non-bottleneck operation: saving an ASIC controller one SHA256 of the=20 > coinbase > transaction. Besides, committing to block height in nLockTime is the most > elegant way to guarantee coinbase transaction uniqueness without relying = on > non-portable BIP 30 validation. The field is intended for this purpose an= d > timelock validation neatly guarantees historical uniqueness. Furthermore,= =20 > it > makes it possible to extract the block height from the coinbase transacti= on > without having to parse Script, and enables constant-time proofs of block= =20 > height [1]. > > The second one is Jeremy Rubin's comment [2] that we may want to keep=20 > 64-byte > transactions, that the validity "seam" this introduces may bring unforese= en > complexity [3] in the design of smart contracts, and that it might be=20 > preferable > to introduce a whole new (sparse) Merkle tree instead. But as long as=20 > Bitcoin > remains remotely similar to today, any transaction that does not burn=20 > funds will > serialize as more than 64 witness-stripped bytes. This is valid regardles= s=20 > of > where the transaction is crafted. Not burning funds is already a concern= =20 > when > designing smart contracts: as long as this is covered, invalidating 64-by= te > transactions does not introduce an additional edge case. Moreover, the=20 > sparse > Merkle tree suggestion would be a major change to a core protocol=20 > component, > with far-reaching implications. Such a "soft" fork would blind unupgraded= =20 > nodes, > not only to others' transaction signatures like with Segwit, but to the= =20 > entirety > of the transaction traffic. This is not the right tradeoff. > > I certainly agree that introducing an explicit restriction on a specific > transaction size is inelegant, and i'm partial to arguments about=20 > unforeseen > complexity. But when the alternatives are leaving a notorious footgun to > upper-layer developers [4], or making a far more invasive change that > effectively mandates an extension block, this is pragmatically the least= =20 > bad > solution. > > Antoine Poinsot > > > [0]: Initially raised on the PR to the BIPs repository, but the latest=20 > iteration > is in response to my recent email to the Bitcoin mining development=20 > mailing list. > See here=20 > https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk/m/RBT_LBWQAgAJ > and the thread thereafter. > [1]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/26 > [2]: To the best of my knowledge, Jeremy has not published a description= =20 > of his > proposal. So i'm basing my response on this interview:=20 > https://youtu.be/FNKipXl5DTY?t=3D769. > [3]: An argument previously raised by Eric Voskuil and weighed in the=20 > Consensus > Cleanup's Delving thread. See this comment for an attempt at summarizing= =20 > the > discussion up to that point:=20 > https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41 > [4]: Even the BitVM bridge developers overlooked the need for implementin= g=20 > a > mitigation for this (https://github.com/BitVM/BitVM/issues/285). > --=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/= 05f5b0ee-b487-4733-9860-ac0705b6b901n%40googlegroups.com. ------=_Part_692507_1411469551.1767846568863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Poinsot,

Thanks for the update. If I'm understanding corre= ctly Luke's concern,
currently the coinbase's scriptSig is used to sto= re an extranonce. One
has to observe first there is no consensus limit= on the size of a
transaction, which holds for the coinbase tx too, a = fortiori there is
no limit on the extranonce size a miner could fit in= the scriptSig.

The point being made is that the nLocktime field= of the coinbase
transaction could be used as a more efficient extra n= once due to
the positional location of nLocktime in a serialized coinb= ase being
one of the latest message block to be processed [0].
Nothing prevent a miner in already doing this and draw a speed advantag= e
from the diminished computational work. I have not looked into CGmin= er code
or one of its derivative forks, if there is an implemented opt= ion to do that,
but yes there could be non-published existing mining f= irmware doing it. IIUC,
BIP54 would nullify this theoretical "speed ad= vantage" for all miners.

Now, there could be an argument ecosyst= em-wise to let the nLocktime free,
as who say speed advantage say less= energy consumed network-wide (-- but
isn't that a better outcome to m= aximize the energy burnt network-wide, even
if it's probabilistic ?).<= br />
One alternative design would be to store the height commitment i= n the
commitment extension introduced by BIP141 [1]. In my understandi= ng, as
it has been pointed out by other minds in the design process ab= out the
actual proposal to put the height commitment in the nLocktime = field,
in the eventuality of more than 1 commitment being introduced,= a naive
design would come with the burden for non-upgraded nodes to h= ave data
availability to all the merkle path to validate a specific so= ft-forked
commitment. So a node could not just implement consensus val= idation rules
for SF #2, without getting the merkle tree data for SF #= 1.

It doesn't sound that this concern could be alleviated by mak= ing the
"witness reserved value", a slot vectors of commitments (e.g t= ype-length-value),
rather than a merkle tree, if you don't know the me= aning of a commitment,
there is no need to fetch over p2p the undefine= d data, just jump to the
next slot. While indeed, such design would de= serve better precision, I'm
thinking it could be another option about = where to fit the height commitment.

On the downside, as it has b= een pointed too before, it would render the
validation done by embedde= d signers more complicated, as one would have
to give the header + mer= kle proof for the coinbase tx inclusion + the coinase
tx + the witness= reserved value commitment + the field in itself. Now,
those embedded = signers, for the most sophisticated one e.g validating
lighting chann= els, due to space constraints, are only validating a subset
of the con= sensus rules (e.g it doesn't validate the lack of inflation).
So it's = unclear to me, that you would strongly clear about validating
the heig= ht commitment of the coinbase tx (ensuring the lineage of the
utxo dow= n to your smart contract is sane ?).

An alternative can be to sp= lit the u32 nLocktime field in a u24 | u8, with
the u8 field being res= erved as an extranonce. An u24 would waive the problem
for few more hu= ndreds of years. So it would be a 40-bit total nonce, made
of a header= 's nonce + 8 bits nonce. I've not looked into historical blocks
to see= what is the extranonce size used in the scriptSig in average.

A= bout the second concern, i.e Jeremy / Eric's one, i.e the risks of
cre= ating a validity "seam" that might introduces unforeseen complexity
in= the design of smart contracts. Made the point w.r.t to the 2500 new
s= igops limit for legacy tx, but the 64-byte limit size comes with a cornercase, when you're burning funds as additional fees to bump the confirma= tion
of a time-sensitive tx. Post-BIP54, that means any tx smart contr= act toolchain
has to be updated to rule out this tx size (e.g for ligh= tning, at `closing_signed`
processing).

While indeed, not r= uling out the 64-byte case might be only a benign effect,
evluating wh= en you should do it or not ask for a lot of inner know-how from
the Po= V of the smart contract toolchain developer. And this is not something
necessarily done once for all, the level of adversarial collaborative txmalleability that can be achieved by the counterparty can be silently c= all
to re-evaluation e.g when you're upgrading your protocol form usin= g p2wsh
to p2tr where the signature size changes.

Anyway, m= y thinking is that a fix long block validation time is a really must
h= ave, fixes for difficulty adjustment exploits is also very good to have (wh= at
was Vertcoin that got exploited on this ?), I'm more skeptical on t= he merkle tree
malleability fix (for protocols using SPV proofs, it ca= n be mitigated by additional
check within their toolchain) and for the= fix of duplicate coinbase transactions,
the fix design could be impro= ved.

As I echoed previously, we can still assign a deployment bi= t to each proposed fix,
while it's very obviously more coordination wo= rk ecosystem-wise in the hypothesis
of multiple distincts activations,= this also let more room to get in earlier the
consensus cleanup more = serious. Not a hill I'm ready to die on, but IMHO separating
the conse= nsus changes in 4 distinct proposals is better development and deploymentpractice (-- if social consensus is gathered to have all the fixes in o= ne deployment
we can still have one signaling bit and activation seque= nce).

Best,
Riard
OTS hash: 808f61fd6438ac7a9e4a2c07a2= 665e6e7dffb7f831897f0dcbb8134cffad5d0b

[0] https://nvlpubs.nist.= gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[1] https://github.com/bitcoin/b= ips/blob/master/bip-0141.mediawiki
[2] https://gnusha.org/pi/bitcoinde= v/aa916637-befa-795a-caa1-e5ad50ce63c8@electrum.org/

Le jeudi 1 janvier = 2026 =C3=A0 14:33:36 UTC, Antoine Poinsot a =C3=A9crit=C2=A0:
Hi everyone,

Some previously raised points regarding BIP 54 have come up again recen= tly, and
i would like to address them here for the record.

The first one is Luke Dashjr's comment [0] that giving meaning to t= he coinbase
transaction nLockTime is undesirable as it's the ideal position for= an
extranonce. But this extranonce only enables a theoretical optimisation= for a
non-bottleneck operation: saving an ASIC controller one SHA256 of the c= oinbase
transaction. Besides, committing to block height in nLockTime is the mo= st
elegant way to guarantee coinbase transaction uniqueness without relyin= g on
non-portable BIP 30 validation. The field is intended for this purpose = and
timelock validation neatly guarantees historical uniqueness. Furthermor= e, it
makes it possible to extract the block height from the coinbase transac= tion
without having to parse Script, and enables constant-time proofs of blo= ck height [1].

The second one is Jeremy Rubin's comment [2] that we may want to ke= ep 64-byte
transactions, that the validity "seam" this introduces may br= ing unforeseen
complexity [3] in the design of smart contracts, and that it might be p= referable
to introduce a whole new (sparse) Merkle tree instead. But as long as B= itcoin
remains remotely similar to today, any transaction that does not burn f= unds will
serialize as more than 64 witness-stripped bytes. This is valid regardl= ess of
where the transaction is crafted. Not burning funds is already a concer= n when
designing smart contracts: as long as this is covered, invalidating 64-= byte
transactions does not introduce an additional edge case. Moreover, the = sparse
Merkle tree suggestion would be a major change to a core protocol compo= nent,
with far-reaching implications. Such a "soft" fork would blin= d unupgraded nodes,
not only to others' transaction signatures like with Segwit, but to= the entirety
of the transaction traffic. This is not the right tradeoff.

I certainly agree that introducing an explicit restriction on a specifi= c
transaction size is inelegant, and i'm partial to arguments about u= nforeseen
complexity. But when the alternatives are leaving a notorious footgun t= o
upper-layer developers [4], or making a far more invasive change that
effectively mandates an extension block, this is pragmatically the leas= t bad
solution.

Antoine Poinsot


[0]: Initially raised on the PR to the BIPs repository, but the latest = iteration
is in response to my recent email to the Bitcoin mining development mai= ling list.
See here https://groups= .google.com/g/bitcoinminingdev/c/jlqlNHHNSNk/m/RBT_LBWQAgAJ
and the thread thereafter.
[1]: https://delvingbitcoin.org/t/g= reat-consensus-cleanup-revival/710/26
[2]: To the best of my knowledge, Jeremy has not published a descriptio= n of his
proposal. So i'm basing my response on this interview: https://youtu.be/FNKipXl5DTY?t=3D769.
[3]: An argument previously raised by Eric Voskuil and weighed in the C= onsensus
Cleanup's Delving thread. See this comment for an attempt at summar= izing the
discussion up to that point: https:= //delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41
[4]: Even the BitVM bridge developers overlooked the need for implement= ing a
mitigation for this (https://github.com/BitVM/BitVM/issues/285).

--
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/msgid/bitcoind= ev/05f5b0ee-b487-4733-9860-ac0705b6b901n%40googlegroups.com.
------=_Part_692507_1411469551.1767846568863-- ------=_Part_692506_1983909474.1767846568863--