From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Tue, 10 Jun 2025 16:42:05 -0700 (PDT) [thread overview]
Message-ID: <9fa96f90-dd9c-45e4-947f-0ce1049ef534n@googlegroups.com> (raw)
In-Reply-To: <1147a254-5033-4663-99f0-7e98a5b6b6c0@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 14743 bytes --]
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
<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
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/9fa96f90-dd9c-45e4-947f-0ce1049ef534n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 16398 bytes --]
next prev parent reply other threads:[~2025-06-12 0:02 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 11:40 James O'Beirne
2025-06-09 12:51 ` Michael Folkson
2025-06-09 14:41 ` James O'Beirne
2025-06-09 15:56 ` Michael Folkson
2025-06-09 13:51 ` Matt Corallo
2025-06-09 14:43 ` James O'Beirne
2025-06-09 17:51 ` Matt Corallo
2025-06-09 19:27 ` /dev /fd0
2025-06-09 21:12 ` Matt Corallo
2025-06-09 18:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 2:02 ` Paul Sztorc
2025-06-09 23:02 ` Andrew Poelstra
2025-06-10 2:08 ` David A. Harding
2025-06-10 13:23 ` Andrew Poelstra
2025-06-10 17:17 ` Matt Corallo
2025-06-10 23:42 ` Antoine Riard [this message]
2025-06-12 3:34 ` James O'Beirne
2025-06-10 23:42 ` Antoine Riard
2025-06-11 13:52 ` Peter Todd
2025-06-10 14:03 ` James O'Beirne
2025-06-10 16:56 ` Sjors Provoost
2025-06-10 17:15 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 19:04 ` Paul Sztorc
2025-06-11 18:09 ` Brandon Black
2025-06-10 2:28 ` Melvin Carvalho
2025-06-10 13:19 ` Greg Sanders
2025-06-11 14:12 ` James O'Beirne
[not found] ` <CAB3F3Dsf8=rbOyPf1yTQDzyQQX6FAoJWTg16VC8PVs4_uBkeTw@mail.gmail.com>
2025-06-11 16:50 ` James O'Beirne
2025-06-11 18:34 ` James O'Beirne
2025-06-11 20:30 ` Matt Corallo
2025-06-12 0:59 ` Harsha Goli
2025-06-12 18:04 ` Matt Corallo
2025-06-12 18:38 ` James O'Beirne
2025-06-12 18:43 ` Matt Corallo
2025-06-12 19:51 ` Andrew Poelstra
2025-06-12 22:44 ` Matt Corallo
2025-06-12 2:06 ` Greg Maxwell
2025-06-12 3:23 ` James O'Beirne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fa96f90-dd9c-45e4-947f-0ce1049ef534n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox