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 NOP 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_SIGOPS_COST` in `src/consensus/consensus.h). That limit is applied for all legacy, p2sh 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 += GetTransactionSigOpCost(tx, view, flags); if (nSigOpsCost > MAX_BLOCK_SIGOPS_COST) { state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "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 ("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 necessarily somehting you're going to think about when you design and deploy second-layers or contract protocol (even 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 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: // TODO: switch to weight-based accounting for packages instead of vsize-based accounting. if (nBlockWeight + WITNESS_SCALE_FACTOR * packageSize >= m_options.nBlockMaxWeight) { return false; } if (nBlockSigOpsCost + packageSigOpsCost >= 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 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 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-feerate, high-sigops junk txn. Here a testcase on some bitcoin core 28.x branch doing so with empty CHECKMULTISIG as they have the highest ratio of sigops accounting per unit of feerate that one has to pay for: https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e A honest counterparty to the use-case U can indeed over-bid in feerate to get her legit time-sensitive tx confirming in block template over the adversary's junk. However, game-theory wise the counterparty is limited by the max amount of funds locked in the shared coins U. E.g if the use-case U has a weight unit surface of 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 evaluate 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 this "block sigops overflow" attacks present a lot of "maybe", most notably what is the txn selection algorithm for block template runned by the high-hashrate miners over the network, it's still put a wonder for any CTV use-case with 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 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 further exploit would be inflate the txn spending the script, which should be 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 potential exposure of any shared UTXO with timelocks and competing interest has always been there...However, as far as I know this ill-design limit for time-sensitive use-cases has never been really been discussed 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 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 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 anyway things to re-think about, at least being sure we do not introduce new 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 à 21:33:41 UTC+1, Matt Corallo a écrit : > > > On 6/10/25 9:23 AM, Andrew Poelstra wrote: > > Le Mon, Jun 09, 2025 at 04:08:21PM -1000, David A. Harding a écrit : > >> > >> Why do you think nobody in Core wants to engage at all with consensus > >> changes (or, at least, specifically the proposals for CTV & CSFS)? > >> > > > > 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. > > > > 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. > > > > 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 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 change doesn't get linked > > on twitter" kinda things. > > > > 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 > people who contribute to > Bitcoin Core are not currently spending their time working on consensus > changes, but that doesn't > mean they didn't pick to work on something that they think is the highest > ROI on their time for the > bitcoin network as a whole. > > The relay changes you mention but sweep under the rug are a critical > improvement to the security > model and usability of lightning, a widely-deployed and now highly > utilized critical piece of > bitcoin (Cash App's public numbers from the Vegas conference indicate its > about 25% of their > withdraw volume by count!). > > While many of the letter signatories may think that that isn't the right > use of time, or the best > way to improve Bitcoin, I don't think its a fair conclusion to claim that > they're somehow wrong, > rather than simply of a different opinion. > > Its also probably fair that many developers don't really *want* to work on > consensus changes because > of the risk of Drama, but that's clearly not universal, given Antoine's > work to pick up and tweak > the Great Consensus Cleanup. Clearly some Bitcoin Core contributors think > that working on consensus > changes is the best use of their time, just not the ones that the letter > signatories happen to think > 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 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. > > > >> The usual purpose of an open letter is to generate public pressure > against > >> the target (otherwise, if you didn't want to generate public pressure, > you > >> would send a private letter). > > > > 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. > > > > 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. > > > > 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 > giving a six-month > ultimatum is all the more likely to drive the incentives in the wrong > direction, not the right one. > Asking individuals why they, personally, are not currently working towards > script expansion changes > is probably much more illuminating, or asking "what would it take to > convince you to work on these > kinds of changes". > > In my experience, there is interest from various Bitcoin Core contributors > to spend time on this, > but four-year projects like mempool policy have some way to go towards > their conclusion and people > like to see things through :). > > The fact that several companies are working to build and deploy Ark-based > payment systems is also a > large part of that - having a concrete application where the developers > see substantial gains (which > can be independently evaluated, at least once things are up and running, > which as I understand it > will be soon) with specific consensus changes is a strong motivator. > Previous attempts at getting > CTV activated largely (in my experience) failed to get people excited > because the demonstrated > 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 significant > >> social pressure on Bitcoin Core contributors to work on CTV (and now > CSFS); > >> I wouldn't expect more pressure to achieve new results; rather, I'd > expect > >> more pressure to create more frustration on all sides. > >> > > > > 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 > exist? I'm kinda confused by > this comment, honestly. Yea, there's no great way to "address all of > Bitcoin Core" at once, but that > doesn't mean most of the most prolific contributors don't go to regular > conferences, meetups, and > aren't responsive to personal messages (at least in some cases). > > I imagine, maybe wrongly, but I imagine that nearly every substantial > Bitcoin Core contributor is at > least two conferences a year, and they're usually speakers so their names > are on the websites of the > 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 something > > I feel strongly about. > > > > 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. > > > >> Alternatively, if you feel like the lack of engagement is a result 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 ultimatum) > would > >> help address it. > >> > > > > 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 specified > > 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 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-signers > on the meaning of the "six > month" timeline :). > > Matt > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a9203193-e061-4dd1-a137-78bb1578bfa6n%40googlegroups.com.