The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

No conflicts as of last run.

Concept ACK

Concept ACK.

Might still be used here: https://github.com/rust-bitcoin/rust-bitcoinconsensus

Ping @apoelstra @tcharding

Ping @Davidson-Souza

Concept ACK

Thank you, @1thales, for the ping.

I'm building a lightweight Bitcoin full node called Floresta, and I'm using libbitcoinconsensus through rust-bitcoinconsensus. I would rather not reimplement the entire script interpreter logic, given the complexity of keeping this code consensus-compatible with core. I did reimplement some consensus logic, but tx validation and script interpreter are the hardest ones to. libbitcoinconsensus has some issues, for example libbitcoinconsensus doesn't validate relative locktimes like CSV. I would prefer validating everything, including those.

Furthermore, I've exchanged some emails with @TheCharlatan about libbitcoinkernel, which is a great project. However, as it is, can't be used by Floresta because it relies on core's block-storage and leveldb. Since floresta is built using utreexo, we can't need those.

If libbitcoinkernel exposes stateless block/tx validation, that is, I give the transaction[s], the inputs and some context like block hash and MTP, and it spits out a "valid" or "not valid because X"; I would start using it as replacement without problems.

Concept ACK

If libbitcoinkernel exposes stateless block/tx validation, that is, I give the transaction[s], the inputs and some context like block hash and MTP, and it spits out a "valid" or "not valid because X"; I would start using it as replacement without problems.

Sounds pretty achievable in the short-term, and something that should be exposed for cross-implementation testing anyway?

Might still be used here: https://github.com/rust-bitcoin/rust-bitcoinconsensus

Ping @apoelstra @tcharding

rust-bitcoinconsensus can just do a "final" release using v27 and keep existing if folk want to use it, its trivial to maintain.

concept ACK. cc @danielabrozzoni @notmandatory (BDK group)

This is the list of dependencies that rely on libbitcoinconsensus.

I believe most of them use libbitcoinconsensus for testing script execution, with the only exception of floresta? While I found it beneficial for cross-testing complex scripts, the absence of core policy rule checking became a notable drawback.

We've transitioned our projects to utilize the bitcoind crate, incorporating integration tests akin to BitcoinTestFramework in the core. Though the setup might be a bit clunky, I believe(as of now) there is no substitute to running core node to check if a transaction satisfies core policy rules.

Thanks for the ping. (a) agreed that rust-bitcoinconsensus can just do a "final" release and this wouldn't be a problem for us, and (b) if there were a blackbox script validator somewhere else, we'd happily use that. Especially if it were a more maintained/supported part of Core rather than something hanging off the side.

I believe most of them use libbitcoinconsensus for testing script execution, with the only exception of floresta? While I found it beneficial for cross-testing complex scripts, the absence of core policy rule checking became a notable drawback.

Would something along the lines of https://github.com/ajtowns/bitcoin/commits/202309-evalscript/ be an interesting alternative?

$ ./bitcoin-util -script_flags=STANDARD evalscript '515193'
{
  "script": {
    "asm": "1 1 OP_ADD",
    "hex": "515193",
    "type": "nonstandard"
  },
  "sigversion": "witness_v0",
  "script_flags": "CHECKLOCKTIMEVERIFY,CHECKSEQUENCEVERIFY,CLEANSTACK,CONST_SCRIPTCODE,DERSIG,DISCOURAGE_OP_SUCCESS,DISCOURAGE_UPGRADABLE_NOPS,DISCOURAGE_UPGRADABLE_PUBKEYTYPE,DISCOURAGE_UPGRADABLE_TAPROOT_VERSION,DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM,LOW_S,MINIMALDATA,MINIMALIF,NULLDUMMY,NULLFAIL,P2SH,STRICTENC,TAPROOT,WITNESS,WITNESS_PUBKEYTYPE",
  "stack-after": [
    "02"
  ],
  "sigop-count": 0,
  "success": true
}

Would something along the lines of https://github.com/ajtowns/bitcoin/commits/202309-evalscript/ be an interesting alternative?

For my part I would rather have a library function than a CLI tool.

This library has existed for nearly 10 years with very little known uptake or impact. It has become a maintenance burden. In several cases it dictates our code/library structure (for example necessitating LIBBITCOIN_CRYPTO_BASE), as well as build-system procedures (building multiple copies of object files especially for the lib).

What is the status of LIBBITCOIN_CRYPTO_BASE? Is it kept around or moved into libbitcoin_common?

I see it's mentioned here: #29180 (comment) - would be useful to also add a note to libraries.md

Hey, I had a use case: create a chain of transactions in WASM (browser) in a multiparty protocol where the child transaction must be verified before signing their parents. The inputs of the parent are controlled by the verifying user so there's no "you need a full node anyway" argument. Thus libbitcoinkernel is not the solution. Now in my case the template is simple enough to not need libbitcoinconsensus - it's fine to just verify the signatures. But being able to just run the same code as Core would be very reassuring that there isn't an attack vector where the counterparty could produce invalid transaction that the client thinks is valid and I wonder if there is any other project that would need more complex verification.

There's another similar idea I had a long time ago: when ordering a node-in-a-box one could pre-open the channels during payment in the browser (same transaction) so one doesn't need to wait for channel opens after the node arrives and saves fees. However I'm not familiar with LN inner workings enough to tell whether libbitcoinconsensus would be needed for this. If the LN people could clarify this it'd be nice.

Also please note that I find the announcement period super short. This wasn't loudly communicated and if I wasn't a co-maintainer of rust-bitcoin I wouldn't have known. And even then I'm already writing this post-merge. I'd really appreciate if there was more time given and louder announcements for breaking changes in the future.

Also please note that I find the announcement period super short.

Removal happens at some unknown time after deprecation, but from what I can tell, not before the 28.0 release (~November 2024). The upcoming v27.* releases will be maintained for a while longer too: https://bitcoincore.org/en/lifecycle/

the child transaction must be verified before signing their parents

What exactly do you mean by "verified"? Are you checking proof-of-work from the headers? The signature?

I'm not familiar enough with what functions the kernel library exposes, to know if you can already do that. Otherwise perhaps more functions should be exposed, in order to be able to perform a subset of validation.

Removal happens at some unknown time after deprecation,

No, removal is going to happen pretty immediately after the 27.x branch off.

Removal happens at some unknown time after deprecation

That doesn't help people who really needed the library. Yeah, they will get screwed later but still they are getting screwed. I meant period to voice opposition to this change. Unless you're open to un-deprecating of course.

What exactly do you mean by "verified"?

It must be possible to include it in a block at some later time when the parent is confirmed and time locks are satisfied. Basically the same requirement as LN force close transaction just different conditions in scripts.

what functions the kernel library exposes

The information I found is that it performs IO and launches threads - both of those are impossible in WASM, so no functions can help unless it can conditionally not compile syscall-performing stuff. (Though even if it can I expect it will be a hell to integrate into other languages properly.)

That doesn't help people who really needed the library. Yeah, they will get screwed later but still they are getting screwed.

Is there a reason you can't stay on the lib of the 27.x or 26.x release?

27.x obviously won't be supported indefinitely

27.x obviously won't be supported indefinitely

Why not? I don't recall the last reported bug in libconsensus, but even if there was one in the future, the 27.x branch could be kept around idle, so that unlikely bugfixes could be applied.