path: root/3a/da305c684b05b160e4deff4813b646afb721bc

Delivery-date: Wed, 11 Jun 2025 17:02:15 -0700
Received: from mail-yw1-f185.google.com ([209.85.128.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRB65RVDBAMGQEXJJW77I@googlegroups.com>)
	id 1uPVOX-0000yZ-JF
	for bitcoindev@gnusha.org; Wed, 11 Jun 2025 17:02:15 -0700
Received: by mail-yw1-f185.google.com with SMTP id 00721157ae682-710da0af5c7sf4139137b3.3
        for <bitcoindev@gnusha.org>; Wed, 11 Jun 2025 17:02:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749686527; x=1750291327; 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=n4Bqf0Z9wbcSRdEsLX7kGrijRKaRFFqmHyrFppkn19c=;
        b=VNjs0/H8vSjRWRyo67vUM18WnGPEZf0uw3p8fgcWfQQlCC8G+j9IquPPwTSam2wOFg
         pbi2yAnLDDppcRXg6YADJ11i5HnhaHicAX9ShhhJ3sCxdKOdMn02rQW4tPGAP0pf+s5r
         dBjAqgRi8k5RlQjeo3ErNmp1skKy+1nlMD2iOyapuzbVfDHpBeXQBu4kjLo7TW2yVIqd
         2uGOZRD/ijDe3DIcUdFk0bE3igTKeOoigLTIVGXMKdSlfNwr67TrQnL7dxP4dXqbEkNe
         nhiC1izB6gWHqs4pxOHAB0XeOD4nPs6AZhRVXeTquWPBDUoj9NXmE3VLwt8BKl8jKR/H
         G+vA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749686527; x=1750291327; 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=n4Bqf0Z9wbcSRdEsLX7kGrijRKaRFFqmHyrFppkn19c=;
        b=M0v1VVpY/hrnwKkvnR5Q+GFMDQm/IaEo7iOwmPQiLYfzq4Cq8rW988n/FS6wnf1vPC
         Vv9992Xne+pPfCGfgNclLH/NMQ+d2u4VyddWYfbCSX/fWCjKEnScCVmwooC6C2gGO7ET
         WklatJ5kFUiekgTlzAv7j/ltzFMOQcQvoYjm0czNc+rjdZanL3o67E5IIpDaKiIptF89
         Md7D+0cu5pWSWAbFmVH1Kbq31iN7G8s/1PbwlJmQAXyHF2KJPnD/LKbyN0U7t1CXiccE
         Dtw287uXeZQlVgBO7ElgAaGPP1AIPHfXmPf5ufwL9WLr0I4HyrwsrfprTnXDBoh08sPP
         1N+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749686527; x=1750291327;
        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=n4Bqf0Z9wbcSRdEsLX7kGrijRKaRFFqmHyrFppkn19c=;
        b=relWT6stNPm1hohqoB1ziVB5EdwxA0Nx9Z8AuttMcxpBKbdcQcm+EhrOyF274MNpnh
         z6gk467/v0RWaAci04cAH22n4OtCCVBU+o2oyVuqJIMe4nEc76JvQynrXyXi+yIA6Zil
         JVMvD2M7Xd+kxI4fsmK5NS/RvY+C+8W6sfkdc4jaRPkOggqHFoJ1MAKJuVis0rT4HZuz
         mYswGoFoHCy9JI3QsC7Olmcrzp/UGGzfLDw/BnxpV3PTkE8m6Msr2iUzhfnbISYCnJIO
         VfbU5UODj2cQNj+5h1tfPtQeYuvc8Umah/wGvLl67M3ZgPptPowoI4ovxHWDcfeQVOiP
         xAAA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWIzdt8M1Hbtwt3Ojw7E6+EQx8G8iSVgr6SLo28/ofeB5rkx0ijh32c0xOqwwLqIxR+aa9uNMsKsEia@gnusha.org
X-Gm-Message-State: AOJu0YyD/xjg6Rnna1HcgIeeNe65tfUTdqguNtJ0FRKtf2LmF/eXO0rg
	3taBVvWdbhQF+tzVn5cEE3fb6a2J8fGj1iPP04FQo0BYP5vLKVzt7fkj
X-Google-Smtp-Source: AGHT+IGi3ok899EhM7PYVlSjyPeJX2virZ6t1QB6Ml/RslzqAtZ8+ctIBn4QvMLNJ0q9BVCizfXaeA==
X-Received: by 2002:a05:6902:a83:b0:e7f:733e:5d79 with SMTP id 3f1490d57ef6-e820c7f5ca1mr1434052276.14.1749686527253;
        Wed, 11 Jun 2025 17:02:07 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd7eseKAn4ykU7p2gXjHSvsbo5Jk2DjC1cjW+n5BTlp3Q==
Received: by 2002:a05:6902:6c0a:b0:e81:7cf7:5008 with SMTP id
 3f1490d57ef6-e820d685327ls204469276.0.-pod-prod-03-us; Wed, 11 Jun 2025
 17:02:02 -0700 (PDT)
X-Received: by 2002:a05:690c:1d:b0:70e:185b:356d with SMTP id 00721157ae682-71140a01ba1mr78957277b3.14.1749686522594;
        Wed, 11 Jun 2025 17:02:02 -0700 (PDT)
Received: by 2002:a05:690c:6711:b0:70d:e0e5:164f with SMTP id 00721157ae682-711413e21d6ms7b3;
        Tue, 10 Jun 2025 16:42:07 -0700 (PDT)
X-Received: by 2002:a05:690c:74c2:b0:70e:2d3d:ace6 with SMTP id 00721157ae682-71140a02060mr21942307b3.15.1749598926353;
        Tue, 10 Jun 2025 16:42:06 -0700 (PDT)
Date: Tue, 10 Jun 2025 16:42:05 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <9fa96f90-dd9c-45e4-947f-0ce1049ef534n@googlegroups.com>
In-Reply-To: <1147a254-5033-4663-99f0-7e98a5b6b6c0@mattcorallo.com>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <aEdoIvOgNNtT6L4s@mail.wpsoftware.net>
 <195051b7c393b9a28727e87647ac002b@dtrt.org>
 <aEgxuiy4dUo8sNkY@mail.wpsoftware.net>
 <1147a254-5033-4663-99f0-7e98a5b6b6c0@mattcorallo.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_12894_1199151036.1749598925767"
X-Original-Sender: antoine.riard@gmail.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 (/)

------=_Part_12894_1199151036.1749598925767
Content-Type: multipart/alternative; 
	boundary="----=_Part_12895_1279740688.1749598925767"

------=_Part_12895_1279740688.1749598925767
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,

Thanks for your post.

I think you can break the current version of CTV in the way it's currently=
=20
proposed as a
NOP refurbishment (i think OP_NOP4), which makes it a legacy script.

Currently, there is a max limit of 80_000 sigops per-block=20
(`MAX_BLOCK_SIGOPS_COST`
in `src/consensus/consensus.h). That limit is applied for all legacy, p2sh=
=20
and segwit
scripts, at time of `Chainstate::ConnectBlock`:

    // GetTransactionSigOpCost counts 3 types of sigops:
    // * legacy (always)
    // * p2sh (when P2SH enabled in flags and excludes coinbase)
    // * witness (when witness enabled in flags and excludes coinbase)
    nSigOpsCost +=3D GetTransactionSigOpCost(tx, view, flags);
    if (nSigOpsCost > MAX_BLOCK_SIGOPS_COST) {
        state.Invalid(BlockValidationResult::BLOCK_CONSENSUS,=20
"bad-blk-sigops", "too many sigops");
        break;
    }

This enforced limit means that any block with 80_001 signature operation
within is going to be rejected by the receiving full-node=20
("too-many-sigops").
where a signature operation is any opcode like a CHECKSIG or CHECKMULTISIG
(`GetSigOpCount()` in `src/script/script.h).=20

While signature operations is not necessarily somehting you're going to=20
think
about when you design and deploy second-layers or contract protocol (even=
=20
for
coinpool we only make assumptions of 1000-sized off-chain constructions, so
1000 sigs at max in the redeemscript), this signature operation limit is
obviously weighted in by block template construction to ensure a valid bloc=
k
is generated by the network and not an insane amount of watt has been=20
wasted.

E.g, the default block template algorithm attached in core is using this=20
limit:

     // TODO: switch to weight-based accounting for packages instead of=20
vsize-based accounting.
     if (nBlockWeight + WITNESS_SCALE_FACTOR * packageSize >=3D=20
m_options.nBlockMaxWeight) {
         return false;
     }
     if (nBlockSigOpsCost + packageSigOpsCost >=3D MAX_BLOCK_SIGOPS_COST) {
         return false;
     }
     return true;

While it is well-established that many miners are running their own block
construction algorithms, one can assume this limit exist for all while it's
more unclear if they're selecting the highest feerate, *highest sigops* txn
too. This selection of highest feerate, *highest sigops* block opens the=20
door
to an interesting exploitation for any use-cases with timelocks.

Namely, let's say you have a use-case U which is locking funds in a redeem
script S with path either alice_sig OR bob_timelock + bob_sig. Any adversar=
y
(i.e Bob) can fulfill the sequence of blocks from current chain tip leading
up to bob_timelock to *censor* alice of redeeming the funds with=20
high-feerate,
high-sigops junk txn.

Here a testcase on some bitcoin core 28.x branch doing so with empty=20
CHECKMULTISIG
as they have the highest ratio of sigops accounting per unit of feerate=20
that one
has to pay for:

https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68d=
a9ce4e

A honest counterparty to the use-case U can indeed over-bid in feerate to=
=20
get
her legit time-sensitive tx confirming in block template over the=20
adversary's junk.
However, game-theory wise the counterparty is limited by the max amount of=
=20
funds
locked in the shared coins U. E.g if the use-case U has a weight unit=20
surface of 20_000
WU and an amount of 100_000 satoshis, the honest counterparty will at most=
=20
burn
5 satoshis per WU.

This is a clear limit that the adversary, who is a counterparty to the=20
locked
funds, can evaluate ahead and from then be break-even by finding N+1=20
use-case U
of amount U or inferior where N is the timelock duration.

While this "block sigops overflow" attacks present a lot of "maybe", most=
=20
notably
what is the txn selection algorithm for block template runned by the=20
high-hashrate
miners over the network, it's still put a wonder for any CTV use-case with=
=20
a script
of the following form:

        OP_IF
                <my_little_vault_hash> OP_CTV
        OP_ELSE
                <alice_bob_their_family_aggregated_pubkey> OP_CHECKSIG
        OP_ENDIF

A simple upgrade can be to overhaul CTV design on top of a OP_SUCCESS or=20
another
tapscript upgrade paths, as tapscripts spends do not see their signature op=
s
accounted in the per-block limit (BIP342 per-script sigops budget). The onl=
y
way to further exploit would be inflate the txn spending the script, which=
=20
should
be correctly bounded by use-cases designers, I think.

As far as I know, this problem has always been there since the activation o=
f
SegWit in 2017, and if I'm correct - but please don't trust, verify - the=
=20
potential
exposure of any shared UTXO with timelocks and competing interest has=20
always been
there...However, as far as I know this ill-design limit for time-sensitive=
=20
use-cases
has never been really been discussed among devs circlces and my own=20
awareness of
this problem is itself quite recent.

That's all for the "letterocracy" and the ones who're currently thinking=20
that
covenant soft-forks are seriously technically reviewed...

The only thing I'll add I'm still eager to review in good faith _both_ your
proposal of CTV+CSFS and Poinsot's BIP54 in the future (in fine he's not=20
personally
responsible for what I did say on the BIP repos issue) in the future.

If I'm correct on this "block sigops overflow" problem, there might be=20
anyway
things to re-think about, at least being sure we do not introduce new=20
issues of
this domain for current or upcoming use-cases.

Don't trust, verify.

Best,
Antoine "the evil one"
OTS hash: 3598fa5db5a6f60639f938b58d85c2b563f4ff7728061eeb166998b7280287ce

Le mardi 10 juin 2025 =C3=A0 21:33:41 UTC+1, Matt Corallo a =C3=A9crit :

>
>
> On 6/10/25 9:23 AM, Andrew Poelstra wrote:
> > Le Mon, Jun 09, 2025 at 04:08:21PM -1000, David A. Harding a =C3=A9crit=
 :
> >>
> >> Why do you think nobody in Core wants to engage at all with consensus
> >> changes (or, at least, specifically the proposals for CTV & CSFS)?
> >>
> >=20
> > Because everybody actively working on Core has a project that, while
> > interesting and useful, does not affect users or the network in any
> > visible way. Over the years there has been a ton of work refactoring
> > the project into multiple libraries, rewriting the logic behind the
> > RPC interface and help text, upgrading to new C++ versions, etc.,
> > and yet if you want to mine from your local node on a local miner
> > today you need to run Sjors' personal fork of the project plus two
> > other daemons.
> >=20
> > I'm being a bit unfair here -- over the same period there has been a
> > ton of critical infrastructure work on transaction relay, descriptor
> > wallets and mempool unification. Some things, like TRUC, even change
> > relay behavior on the network. But these are still things that no
> > ordinary user could articulate well enough to complain about.
> >=20
> > This is understandable -- I also don't want to deal with the kind of
> > BS where making simple obvious mempool optimizations leads to Twitter
> > brigading and funded FUD campaigns. (Let alone something like the segwi=
t
> > FUD campaign which was much larger and more professional.) And of
> > course, consensus changes requires large-scale public engagement; these
> > changes are not "luck of the draw" "hope your change doesn't get linked
> > on twitter" kinda things.
> >=20
> > But the result, when everybody feels this way, is a lack of engagement
> > from the project as a whole.
>
> I don't think this is a fair characterization in the slightest. Yes, many=
=20
> people who contribute to=20
> Bitcoin Core are not currently spending their time working on consensus=
=20
> changes, but that doesn't=20
> mean they didn't pick to work on something that they think is the highest=
=20
> ROI on their time for the=20
> bitcoin network as a whole.
>
> The relay changes you mention but sweep under the rug are a critical=20
> improvement to the security=20
> model and usability of lightning, a widely-deployed and now highly=20
> utilized critical piece of=20
> bitcoin (Cash App's public numbers from the Vegas conference indicate its=
=20
> about 25% of their=20
> withdraw volume by count!).
>
> While many of the letter signatories may think that that isn't the right=
=20
> use of time, or the best=20
> way to improve Bitcoin, I don't think its a fair conclusion to claim that=
=20
> they're somehow wrong,=20
> rather than simply of a different opinion.
>
> Its also probably fair that many developers don't really *want* to work o=
n=20
> consensus changes because=20
> of the risk of Drama, but that's clearly not universal, given Antoine's=
=20
> work to pick up and tweak=20
> the Great Consensus Cleanup. Clearly some Bitcoin Core contributors think=
=20
> that working on consensus=20
> changes is the best use of their time, just not the ones that the letter=
=20
> signatories happen to think=20
> are the important ones.
>
> Of course sign-on letters do little to reduce the impact of Drama, only=
=20
> contribute to it :(
>
> > Complicating matters is the fact that it's quite hard to contribute
> > things to Bitcoin Core -- it is hard to get reviews, when you can get
> > them they're slow, you need to spend months or years rebasing over the
> > codebase churn, etc. These problems are well-known. So it's hard to
> > onboard new people who want to push on more-visible things.
> >=20
> >> The usual purpose of an open letter is to generate public pressure=20
> against
> >> the target (otherwise, if you didn't want to generate public pressure,=
=20
> you
> >> would send a private letter).
> >=20
> > There isn't really any place to send a "private" letter. For most
> > open-source projects I could just file a discussion on their Github
> > repo, which would be unnoticed and unread by anyone else. Core does not
> > have that privilege.
> >=20
> > There are in-person meetups a few times a year but for (happy) family
> > reasons I've been unable to attend, and won't be able to for the next
> > few years at least.
> >=20
> > And of course I could email specific developers personally, but there
> > are no individuals that it makes sense to target, because this isn't an
> > individual problem. It's an incentive problem.
>
> If its an incentive problem, though, sending a vaguely-threatening letter=
=20
> giving a six-month=20
> ultimatum is all the more likely to drive the incentives in the wrong=20
> direction, not the right one.=20
> Asking individuals why they, personally, are not currently working toward=
s=20
> script expansion changes=20
> is probably much more illuminating, or asking "what would it take to=20
> convince you to work on these=20
> kinds of changes".
>
> In my experience, there is interest from various Bitcoin Core contributor=
s=20
> to spend time on this,=20
> but four-year projects like mempool policy have some way to go towards=20
> their conclusion and people=20
> like to see things through :).
>
> The fact that several companies are working to build and deploy Ark-based=
=20
> payment systems is also a=20
> large part of that - having a concrete application where the developers=
=20
> see substantial gains (which=20
> can be independently evaluated, at least once things are up and running,=
=20
> which as I understand it=20
> will be soon) with specific consensus changes is a strong motivator.=20
> Previous attempts at getting=20
> CTV activated largely (in my experience) failed to get people excited=20
> because the demonstrated=20
> use-cases for CTV by itself did not feel super compelling.
>
> >> Does that mean that you feel the lack of
> >> engagement is a result of a previous lack of pressure? I have to admit=
=20
> that
> >> runs counter to my own sense---I thought there was already significant
> >> social pressure on Bitcoin Core contributors to work on CTV (and now=
=20
> CSFS);
> >> I wouldn't expect more pressure to achieve new results; rather, I'd=20
> expect
> >> more pressure to create more frustration on all sides.
> >>
> >=20
> > I think that logistically there isn't any non-public medium that would
> > work. Maybe solving this would also solve the incentive problems around
> > making big changes!
>
> Conferences, individual emails, signal messages are all options that=20
> exist? I'm kinda confused by=20
> this comment, honestly. Yea, there's no great way to "address all of=20
> Bitcoin Core" at once, but that=20
> doesn't mean most of the most prolific contributors don't go to regular=
=20
> conferences, meetups, and=20
> aren't responsive to personal messages (at least in some cases).
>
> I imagine, maybe wrongly, but I imagine that nearly every substantial=20
> Bitcoin Core contributor is at=20
> least two conferences a year, and they're usually speakers so their names=
=20
> are on the websites of the=20
> conferences.
>
> > I spent a while deliberating about whether signing onto an open letter
> > would just cause flamewars and "more pressure" -- especially since I'm
> > probably closer to Core development than any of the other signers, and
> > because its specific technical demand (CTV + CSFS) is not even somethin=
g
> > I feel strongly about.
> >=20
> > My goal was to start exactly this discussion, by talking about the role
> > Core plays in this ecosystem and pointing to (in my view) the incentive
> > problems that are getting in the way of that role.
> >=20
> >> Alternatively, if you feel like the lack of engagement is a result of=
=20
> some
> >> other condition, I would be curious to learn of that condition and=20
> learn why
> >> you thought an open letter (with what comes across as an ultimatum)=20
> would
> >> help address it.
> >>
> >=20
> > I apologize if it comes off as an ultimatum -- it has a timeline, but
> > one for a "respectful ask" for "review and integration" and no specifie=
d
> > consquences (I'm not even sure what consequences would look like ...
> > perhaps a fork of Core? I can say that I personally would never go alon=
g
> > with a consensus-changing fork of Core, barring some extreme event like
> > outright abandonment of the project.)
>
>
> Fair enough. There are apparently differing views by other letter-signers=
=20
> on the meaning of the "six=20
> month" timeline :).
>
> Matt
>

--=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/=
9fa96f90-dd9c-45e4-947f-0ce1049ef534n%40googlegroups.com.

------=_Part_12895_1279740688.1749598925767
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,<br /><br />Thanks for your post.<br /><br />I think you can break=
 the current version of CTV in the way it's currently proposed as a<br />NO=
P refurbishment (i think OP_NOP4), which makes it a legacy script.<br /><br=
 />Currently, there is a max limit of 80_000 sigops per-block (`MAX_BLOCK_S=
IGOPS_COST`<br />in `src/consensus/consensus.h). That limit is applied for =
all legacy, p2sh and segwit<br />scripts, at time of `Chainstate::ConnectBl=
ock`:<br /><br />=C2=A0 =C2=A0 // GetTransactionSigOpCost counts 3 types of=
 sigops:<br />=C2=A0 =C2=A0 // * legacy (always)<br />=C2=A0 =C2=A0 // * p2=
sh (when P2SH enabled in flags and excludes coinbase)<br />=C2=A0 =C2=A0 //=
 * witness (when witness enabled in flags and excludes coinbase)<br />=C2=
=A0 =C2=A0 nSigOpsCost +=3D GetTransactionSigOpCost(tx, view, flags);<br />=
=C2=A0 =C2=A0 if (nSigOpsCost &gt; MAX_BLOCK_SIGOPS_COST) {<br />=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "ba=
d-blk-sigops", "too many sigops");<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;<=
br />=C2=A0 =C2=A0 }<br /><br />This enforced limit means that any block wi=
th 80_001 signature operation<br />within is going to be rejected by the re=
ceiving full-node ("too-many-sigops").<br />where a signature operation is =
any opcode like a CHECKSIG or CHECKMULTISIG<br />(`GetSigOpCount()` in `src=
/script/script.h). <br /><br />While signature operations is not necessaril=
y somehting you're going to think<br />about when you design and deploy sec=
ond-layers or contract protocol (even for<br />coinpool we only make assump=
tions of 1000-sized off-chain constructions, so<br />1000 sigs at max in th=
e redeemscript), this signature operation limit is<br />obviously weighted =
in by block template construction to ensure a valid block<br />is generated=
 by the network and not an insane amount of watt has been wasted.<br /><br =
/>E.g, the default block template algorithm attached in core is using this =
limit:<br /><br />=C2=A0 =C2=A0 =C2=A0// TODO: switch to weight-based accou=
nting for packages instead of vsize-based accounting.<br />=C2=A0 =C2=A0 =
=C2=A0if (nBlockWeight + WITNESS_SCALE_FACTOR * packageSize &gt;=3D m_optio=
ns.nBlockMaxWeight) {<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return false;<=
br />=C2=A0 =C2=A0 =C2=A0}<br />=C2=A0 =C2=A0 =C2=A0if (nBlockSigOpsCost + =
packageSigOpsCost &gt;=3D MAX_BLOCK_SIGOPS_COST) {<br />=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0return false;<br />=C2=A0 =C2=A0 =C2=A0}<br />=C2=A0 =C2=
=A0 =C2=A0return true;<br /><br />While it is well-established that many mi=
ners are running their own block<br />construction algorithms, one can assu=
me this limit exist for all while it's<br />more unclear if they're selecti=
ng the highest feerate, *highest sigops* txn<br />too. This selection of hi=
ghest feerate, *highest sigops* block opens the door<br />to an interesting=
 exploitation for any use-cases with timelocks.<br /><br />Namely, let's sa=
y you have a use-case U which is locking funds in a redeem<br />script S wi=
th path either alice_sig OR bob_timelock + bob_sig. Any adversary<br />(i.e=
 Bob) can fulfill the sequence of blocks from current chain tip leading<br =
/>up to bob_timelock to *censor* alice of redeeming the funds with high-fee=
rate,<br />high-sigops junk txn.<br /><br />Here a testcase on some bitcoin=
 core 28.x branch doing so with empty CHECKMULTISIG<br />as they have the h=
ighest ratio of sigops accounting per unit of feerate that one<br />has to =
pay for:<br /><br />https://github.com/ariard/bitcoin/commit/b85a426c43cb70=
00788a55ea140b73a68da9ce4e<br /><br />A honest counterparty to the use-case=
 U can indeed over-bid in feerate to get<br />her legit time-sensitive tx c=
onfirming in block template over the adversary's junk.<br />However, game-t=
heory wise the counterparty is limited by the max amount of funds<br />lock=
ed in the shared coins U. E.g if the use-case U has a weight unit surface o=
f 20_000<br />WU and an amount of 100_000 satoshis, the honest counterparty=
 will at most burn<br />5 satoshis per WU.<br /><br />This is a clear limit=
 that the adversary, who is a counterparty to the locked<br />funds, can ev=
aluate ahead and from then be break-even by finding N+1 use-case U<br />of =
amount U or inferior where N is the timelock duration.<br /><br />While thi=
s "block sigops overflow" attacks present a lot of "maybe", most notably<br=
 />what is the txn selection algorithm for block template runned by the hig=
h-hashrate<br />miners over the network, it's still put a wonder for any CT=
V use-case with a script<br />of the following form:<br /><br />=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 OP_IF<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 &lt;my_little_vault_hash&gt; OP_CTV<br />=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 OP_ELSE<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 &lt;alice_bob_their_family_aggregated_pubkey&gt; OP_CHECKSIG<br />=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 OP_ENDIF<br /><br />A simple upgrade can be to overhau=
l CTV design on top of a OP_SUCCESS or another<br />tapscript upgrade paths=
, as tapscripts spends do not see their signature ops<br />accounted in the=
 per-block limit (BIP342 per-script sigops budget). The only<br />way to fu=
rther exploit would be inflate the txn spending the script, which should<br=
 />be correctly bounded by use-cases designers, I think.<br /><br />As far =
as I know, this problem has always been there since the activation of<br />=
SegWit in 2017, and if I'm correct - but please don't trust, verify - the p=
otential<br />exposure of any shared UTXO with timelocks and competing inte=
rest has always been<br />there...However, as far as I know this ill-design=
 limit for time-sensitive use-cases<br />has never been really been discuss=
ed among devs circlces and my own awareness of<br />this problem is itself =
quite recent.<br /><br />That's all for the "letterocracy" and the ones who=
're currently thinking that<br />covenant soft-forks are seriously technica=
lly reviewed...<br /><br />The only thing I'll add I'm still eager to revie=
w in good faith _both_ your<br />proposal of CTV+CSFS and Poinsot's BIP54 i=
n the future (in fine he's not personally<br />responsible for what I did s=
ay on the BIP repos issue) in the future.<br /><br />If I'm correct on this=
 "block sigops overflow" problem, there might be anyway<br />things to re-t=
hink about, at least being sure we do not introduce new issues of<br />this=
 domain for current or upcoming use-cases.<br /><br />Don't trust, verify.<=
br /><br />Best,<br />Antoine "the evil one"<br />OTS hash: 3598fa5db5a6f60=
639f938b58d85c2b563f4ff7728061eeb166998b7280287ce<br /><br /><div class=3D"=
gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le mardi 10 juin 2025 =
=C3=A0 21:33:41 UTC+1, Matt Corallo a =C3=A9crit=C2=A0:<br/></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px sol=
id rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>On 6/10/25 9:23 AM, Andrew Poelstra wrote:
<br>&gt; Le Mon, Jun 09, 2025 at 04:08:21PM -1000, David A. Harding a =C3=
=A9crit :
<br>&gt;&gt;
<br>&gt;&gt; Why do you think nobody in Core wants to engage at all with co=
nsensus
<br>&gt;&gt; changes (or, at least, specifically the proposals for CTV &amp=
; CSFS)?
<br>&gt;&gt;
<br>&gt;=20
<br>&gt; Because everybody actively working on Core has a project that, whi=
le
<br>&gt; interesting and useful, does not affect users or the network in an=
y
<br>&gt; visible way. Over the years there has been a ton of work refactori=
ng
<br>&gt; the project into multiple libraries, rewriting the logic behind th=
e
<br>&gt; RPC interface and help text, upgrading to new C++ versions, etc.,
<br>&gt; and yet if you want to mine from your local node on a local miner
<br>&gt; today you need to run Sjors&#39; personal fork of the project plus=
 two
<br>&gt; other daemons.
<br>&gt;=20
<br>&gt; I&#39;m being a bit unfair here -- over the same period there has =
been a
<br>&gt; ton of critical infrastructure work on transaction relay, descript=
or
<br>&gt; wallets and mempool unification. Some things, like TRUC, even chan=
ge
<br>&gt; relay behavior on the network. But these are still things that no
<br>&gt; ordinary user could articulate well enough to complain about.
<br>&gt;=20
<br>&gt; This is understandable -- I also don&#39;t want to deal with the k=
ind of
<br>&gt; BS where making simple obvious mempool optimizations leads to Twit=
ter
<br>&gt; brigading and funded FUD campaigns. (Let alone something like the =
segwit
<br>&gt; FUD campaign which was much larger and more professional.) And of
<br>&gt; course, consensus changes requires large-scale public engagement; =
these
<br>&gt; changes are not &quot;luck of the draw&quot; &quot;hope your chang=
e doesn&#39;t get linked
<br>&gt; on twitter&quot; kinda things.
<br>&gt;=20
<br>&gt; But the result, when everybody feels this way, is a lack of engage=
ment
<br>&gt; from the project as a whole.
<br>
<br>I don&#39;t think this is a fair characterization in the slightest. Yes=
, many people who contribute to=20
<br>Bitcoin Core are not currently spending their time working on consensus=
 changes, but that doesn&#39;t=20
<br>mean they didn&#39;t pick to work on something that they think is the h=
ighest ROI on their time for the=20
<br>bitcoin network as a whole.
<br>
<br>The relay changes you mention but sweep under the rug are a critical im=
provement to the security=20
<br>model and usability of lightning, a widely-deployed and now highly util=
ized critical piece of=20
<br>bitcoin (Cash App&#39;s public numbers from the Vegas conference indica=
te its about 25% of their=20
<br>withdraw volume by count!).
<br>
<br>While many of the letter signatories may think that that isn&#39;t the =
right use of time, or the best=20
<br>way to improve Bitcoin, I don&#39;t think its a fair conclusion to clai=
m that they&#39;re somehow wrong,=20
<br>rather than simply of a different opinion.
<br>
<br>Its also probably fair that many developers don&#39;t really *want* to =
work on consensus changes because=20
<br>of the risk of Drama, but that&#39;s clearly not universal, given Antoi=
ne&#39;s work to pick up and tweak=20
<br>the Great Consensus Cleanup. Clearly some Bitcoin Core contributors thi=
nk that working on consensus=20
<br>changes is the best use of their time, just not the ones that the lette=
r signatories happen to think=20
<br>are the important ones.
<br>
<br>Of course sign-on letters do little to reduce the impact of Drama, only=
 contribute to it :(
<br>
<br>&gt; Complicating matters is the fact that it&#39;s quite hard to contr=
ibute
<br>&gt; things to Bitcoin Core -- it is hard to get reviews, when you can =
get
<br>&gt; them they&#39;re slow, you need to spend months or years rebasing =
over the
<br>&gt; codebase churn, etc. These problems are well-known. So it&#39;s ha=
rd to
<br>&gt; onboard new people who want to push on more-visible things.
<br>&gt;=20
<br>&gt;&gt; The usual purpose of an open letter is to generate public pres=
sure against
<br>&gt;&gt; the target (otherwise, if you didn&#39;t want to generate publ=
ic pressure, you
<br>&gt;&gt; would send a private letter).
<br>&gt;=20
<br>&gt; There isn&#39;t really any place to send a &quot;private&quot; let=
ter. For most
<br>&gt; open-source projects I could just file a discussion on their Githu=
b
<br>&gt; repo, which would be unnoticed and unread by anyone else. Core doe=
s not
<br>&gt; have that privilege.
<br>&gt;=20
<br>&gt; There are in-person meetups a few times a year but for (happy) fam=
ily
<br>&gt; reasons I&#39;ve been unable to attend, and won&#39;t be able to f=
or the next
<br>&gt; few years at least.
<br>&gt;=20
<br>&gt; And of course I could email specific developers personally, but th=
ere
<br>&gt; are no individuals that it makes sense to target, because this isn=
&#39;t an
<br>&gt; individual problem. It&#39;s an incentive problem.
<br>
<br>If its an incentive problem, though, sending a vaguely-threatening lett=
er giving a six-month=20
<br>ultimatum is all the more likely to drive the incentives in the wrong d=
irection, not the right one.=20
<br>Asking individuals why they, personally, are not currently working towa=
rds script expansion changes=20
<br>is probably much more illuminating, or asking &quot;what would it take =
to convince you to work on these=20
<br>kinds of changes&quot;.
<br>
<br>In my experience, there is interest from various Bitcoin Core contribut=
ors to spend time on this,=20
<br>but four-year projects like mempool policy have some way to go towards =
their conclusion and people=20
<br>like to see things through :).
<br>
<br>The fact that several companies are working to build and deploy Ark-bas=
ed payment systems is also a=20
<br>large part of that - having a concrete application where the developers=
 see substantial gains (which=20
<br>can be independently evaluated, at least once things are up and running=
, which as I understand it=20
<br>will be soon) with specific consensus changes is a strong motivator. Pr=
evious attempts at getting=20
<br>CTV activated largely (in my experience) failed to get people excited b=
ecause the demonstrated=20
<br>use-cases for CTV by itself did not feel super compelling.
<br>
<br>&gt;&gt; Does that mean that you feel the lack of
<br>&gt;&gt; engagement is a result of a previous lack of pressure?  I have=
 to admit that
<br>&gt;&gt; runs counter to my own sense---I thought there was already sig=
nificant
<br>&gt;&gt; social pressure on Bitcoin Core contributors to work on CTV (a=
nd now CSFS);
<br>&gt;&gt; I wouldn&#39;t expect more pressure to achieve new results; ra=
ther, I&#39;d expect
<br>&gt;&gt; more pressure to create more frustration on all sides.
<br>&gt;&gt;
<br>&gt;=20
<br>&gt; I think that logistically there isn&#39;t any non-public medium th=
at would
<br>&gt; work. Maybe solving this would also solve the incentive problems a=
round
<br>&gt; making big changes!
<br>
<br>Conferences, individual emails, signal messages are all options that ex=
ist? I&#39;m kinda confused by=20
<br>this comment, honestly. Yea, there&#39;s no great way to &quot;address =
all of Bitcoin Core&quot; at once, but that=20
<br>doesn&#39;t mean most of the most prolific contributors don&#39;t go to=
 regular conferences, meetups, and=20
<br>aren&#39;t responsive to personal messages (at least in some cases).
<br>
<br>I imagine, maybe wrongly, but I imagine that nearly every substantial B=
itcoin Core contributor is at=20
<br>least two conferences a year, and they&#39;re usually speakers so their=
 names are on the websites of the=20
<br>conferences.
<br>
<br>&gt; I spent a while deliberating about whether signing onto an open le=
tter
<br>&gt; would just cause flamewars and &quot;more pressure&quot; -- especi=
ally since I&#39;m
<br>&gt; probably closer to Core development than any of the other signers,=
 and
<br>&gt; because its specific technical demand (CTV + CSFS) is not even som=
ething
<br>&gt; I feel strongly about.
<br>&gt;=20
<br>&gt; My goal was to start exactly this discussion, by talking about the=
 role
<br>&gt; Core plays in this ecosystem and pointing to (in my view) the ince=
ntive
<br>&gt; problems that are getting in the way of that role.
<br>&gt;=20
<br>&gt;&gt; Alternatively, if you feel like the lack of engagement is a re=
sult of some
<br>&gt;&gt; other condition, I would be curious to learn of that condition=
 and learn why
<br>&gt;&gt; you thought an open letter (with what comes across as an ultim=
atum) would
<br>&gt;&gt; help address it.
<br>&gt;&gt;
<br>&gt;=20
<br>&gt; I apologize if it comes off as an ultimatum -- it has a timeline, =
but
<br>&gt; one for a &quot;respectful ask&quot; for &quot;review and integrat=
ion&quot; and no specified
<br>&gt; consquences (I&#39;m not even sure what consequences would look li=
ke ...
<br>&gt; perhaps a fork of Core? I can say that I personally would never go=
 along
<br>&gt; with a consensus-changing fork of Core, barring some extreme event=
 like
<br>&gt; outright abandonment of the project.)
<br>
<br>
<br>Fair enough. There are apparently differing views by other letter-signe=
rs on the meaning of the &quot;six=20
<br>month&quot; timeline :).
<br>
<br>Matt
<br></blockquote></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/9fa96f90-dd9c-45e4-947f-0ce1049ef534n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/9fa96f90-dd9c-45e4-947f-0ce1049ef534n%40googlegroups.com</a>.<br />

------=_Part_12895_1279740688.1749598925767--

------=_Part_12894_1199151036.1749598925767--