From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <9fa96f90-dd9c-45e4-947f-0ce1049ef534n@googlegroups.com> In-Reply-To: <1147a254-5033-4663-99f0-7e98a5b6b6c0@mattcorallo.com> References: <195051b7c393b9a28727e87647ac002b@dtrt.org> <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 OP_CTV OP_ELSE 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,

Thanks for your post.

I think you can break= the current version of CTV in the way it's currently proposed as a
NO= P refurbishment (i think OP_NOP4), which makes it a legacy script.
Currently, there is a max limit of 80_000 sigops per-block (`MAX_BLOCK_S= IGOPS_COST`
in `src/consensus/consensus.h). That limit is applied for = all legacy, p2sh and segwit
scripts, at time of `Chainstate::ConnectBl= ock`:

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

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

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

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

=C2=A0 =C2=A0 =C2=A0// TODO: switch to weight-based accou= nting for packages instead of vsize-based accounting.
=C2=A0 =C2=A0 = =C2=A0if (nBlockWeight + WITNESS_SCALE_FACTOR * packageSize >=3D m_optio= ns.nBlockMaxWeight) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return false;<= br />=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0if (nBlockSigOpsCost + = packageSigOpsCost >=3D MAX_BLOCK_SIGOPS_COST) {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0return false;
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2= =A0 =C2=A0return true;

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

Namely, let's sa= y you have a use-case U which is locking funds in a redeem
script S wi= th path either alice_sig OR bob_timelock + bob_sig. Any adversary
(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 high-fee= rate,
high-sigops junk txn.

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

https://github.com/ariard/bitcoin/commit/b85a426c43cb70= 00788a55ea140b73a68da9ce4e

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

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

While thi= s "block sigops overflow" attacks present a lot of "maybe", most notablywhat is the txn selection algorithm for block template runned by the hig= h-hashrate
miners over the network, it's still put a wonder for any CT= V use-case with a script
of the following form:

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 OP_IF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <my_little_vault_hash> OP_CTV
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 OP_ELSE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= <alice_bob_their_family_aggregated_pubkey> OP_CHECKSIG
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 OP_ENDIF

A simple upgrade can be to overhau= l CTV design on top of a OP_SUCCESS or another
tapscript upgrade paths= , as tapscripts spends do not see their signature ops
accounted in the= per-block limit (BIP342 per-script sigops budget). The only
way to fu= rther exploit would be inflate the txn spending the script, which shouldbe correctly bounded by use-cases designers, I think.

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

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

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

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

Don't trust, verify.<= br />
Best,
Antoine "the evil one"
OTS hash: 3598fa5db5a6f60= 639f938b58d85c2b563f4ff7728061eeb166998b7280287ce

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


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 co= nsensus
>> changes (or, at least, specifically the proposals for CTV &= ; CSFS)?
>>
>=20
> Because everybody actively working on Core has a project that, whi= le
> interesting and useful, does not affect users or the network in an= y
> visible way. Over the years there has been a ton of work refactori= ng
> the project into multiple libraries, rewriting the logic behind th= e
> 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, descript= or
> wallets and mempool unification. Some things, like TRUC, even chan= ge
> 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 k= ind of
> BS where making simple obvious mempool optimizations leads to Twit= ter
> brigading and funded FUD campaigns. (Let alone something like the = segwit
> 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 chang= e doesn't get linked
> on twitter" kinda things.
>=20
> But the result, when everybody feels this way, is a lack of engage= ment
> from the project as a whole.

I don't think this is a fair characterization in the slightest. Yes= , many people who contribute to=20
Bitcoin Core are not currently spending their time working on consensus= changes, but that doesn't=20
mean they didn't pick to work on something that they think is the h= ighest 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 im= provement to the security=20
model and usability of lightning, a widely-deployed and now highly util= ized critical piece of=20
bitcoin (Cash App's public numbers from the Vegas conference indica= te its about 25% of their=20
withdraw volume by count!).

While many of the letter signatories may think that that isn't the = right use of time, or the best=20
way to improve Bitcoin, I don't think its a fair conclusion to clai= m that 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 on consensus changes because=20
of the risk of Drama, but that's clearly not universal, given Antoi= ne's work to pick up and tweak=20
the Great Consensus Cleanup. Clearly some Bitcoin Core contributors thi= nk that working on consensus=20
changes is the best use of their time, just not the ones that the lette= r signatories happen to think=20
are the important ones.

Of course sign-on letters do little to reduce the impact of Drama, only= contribute to it :(

> Complicating matters is the fact that it's quite hard to contr= ibute
> 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 ha= rd to
> onboard new people who want to push on more-visible things.
>=20
>> The usual purpose of an open letter is to generate public pres= sure against
>> the target (otherwise, if you didn't want to generate publ= ic pressure, you
>> would send a private letter).
>=20
> There isn't really any place to send a "private" let= ter. For most
> open-source projects I could just file a discussion on their Githu= b
> repo, which would be unnoticed and unread by anyone else. Core doe= s not
> have that privilege.
>=20
> There are in-person meetups a few times a year but for (happy) fam= ily
> reasons I've been unable to attend, and won't be able to f= or the next
> few years at least.
>=20
> And of course I could email specific developers personally, but th= ere
> 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 lett= er giving a six-month=20
ultimatum is all the more likely to drive the incentives in the wrong d= irection, not the right one.=20
Asking individuals why they, personally, are not currently working towa= rds script expansion changes=20
is probably much more illuminating, or asking "what would it take = to convince you to work on these=20
kinds of changes".

In my experience, there is interest from various Bitcoin Core contribut= ors to spend time on this,=20
but four-year projects like mempool policy have some way to go towards = their conclusion and people=20
like to see things through :).

The fact that several companies are working to build and deploy Ark-bas= ed payment systems is also a=20
large part of that - having a concrete application where the developers= see substantial gains (which=20
can be independently evaluated, at least once things are up and running= , which as I understand it=20
will be soon) with specific consensus changes is a strong motivator. Pr= evious attempts at getting=20
CTV activated largely (in my experience) failed to get people excited b= ecause 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 that
>> runs counter to my own sense---I thought there was already sig= nificant
>> social pressure on Bitcoin Core contributors to work on CTV (a= nd now CSFS);
>> I wouldn't expect more pressure to achieve new results; ra= ther, I'd expect
>> more pressure to create more frustration on all sides.
>>
>=20
> I think that logistically there isn't any non-public medium th= at would
> work. Maybe solving this would also solve the incentive problems a= round
> making big changes!

Conferences, individual emails, signal messages are all options that ex= ist? I'm kinda confused by=20
this comment, honestly. Yea, there's no great way to "address = all of Bitcoin Core" at once, but that=20
doesn't mean most of the most prolific contributors don't go to= regular 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 B= itcoin Core contributor is at=20
least two conferences a year, and they're usually speakers so their= names are on the websites of the=20
conferences.

> I spent a while deliberating about whether signing onto an open le= tter
> would just cause flamewars and "more pressure" -- especi= ally 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 som= ething
> 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 ince= ntive
> problems that are getting in the way of that role.
>=20
>> Alternatively, if you feel like the lack of engagement is a re= sult of some
>> other condition, I would be curious to learn of that condition= and learn why
>> you thought an open letter (with what comes across as an ultim= atum) 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 integrat= ion" and no specified
> consquences (I'm not even sure what consequences would look li= ke ...
> perhaps a fork of Core? I can say that I personally would never go= along
> 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-signe= rs on the meaning of the "six=20
month" timeline :).

Matt

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