Repository navigation
Conversation
Don't actually build bitcoin yet; just refactor build.rs
For dumb "C polymorphism" reasons we have two structures in the C code named txEnv. We can call the corresponding Rust structures different things, but we need to access them from the C file env.c, which provides some C wrappers for FFI stuff. Since you can't have two different structs with the same name in one compilation unit, split it into two: add depend/bitcoin_env.c holding the Bitcoin txEnv wrappers, alongside the existing depend/env.c for Elements.
This is the more correct trait. When we update the Jet trait we will be forced to pick one, and we will pick Borrow.
Updates to BlockstreamResearch/simplicity#324 This PR does a couple things simultaneously: * Runs vendor-simplicity.sh and update-jets.sh * Updates the `Jet` trait to have associated transaction and environment types, and for the environment to be paramterized by the transaction type. * Changes the Core environment from () to CoreEnv::<Infallible> * Updates some fixed Core CMR/IHR vectors (this update to libsimplicity changes the benchmarks for the Core jets and thus changes these vectors) * Uncomments the commented-out symbols in simplicity-sys/src/c_jets/c_env/bitcoin.rs * Adds the "build bitcoin" lines to simplicity-sys/build.rs The update to the `Jet` trait is a bit noisy but ultimately mechanical: everywhere that we're generic over all J: Jet, we now also have to be generic over all T: Borrow<J::Transaction>, which leads to some extra line noise especially in unit tests where we have assert_* helper functions. The last four points are tiny diffs, thanks to the previous preparatory commits. The use of CoreEnv::<Infallible> as the core environment type is kinda fun. It means that it is impossible to execute any code which attempts to access the transaction in the environment. (No such code exists, since it would be nonsensical, but now we have some assurance that it won't exist by accident in the future.) Unfortunately this mixes mechanical and non-mechanical things in one commit. But the mechanical changes are exclusively in simplicity-sys/depend/ and src/jet/init/ and the non-mechanical changes are exclusively outside of those files, so it should be possible to review this.
Change the JetEnvironment impl for BitcoinEnv and ElementsEnv to be generic over T: Borrow<Transaction> instead of fixed to Arc<Transaction>. Update Policy::satisfy, get_satisfier, execute_successful, execute_unsuccessful, and serialize test helpers to accept ElementsEnv<impl Borrow<Transaction>>. This allows callers to construct environments without Arc overhead (for example, using a plain reference or owned value), and is required so that BitcoinEnv::c_jet_env can return a real CTxEnv from a borrowed transaction.
Now that we've updated the Jet trait to allow the transactions in environments to be arbitrary T: Borrow<Transaction>, we don't need to use Arc everywhere. In many cases we can use normal references.
This is a Rust type which can be used, among other things, to construct the transaction environment needed by C jets. Also provides accessors for the underlying transaction and input index, both of which are used (in the Elements version of this struct) in the policy satisfier.
rust-bitcoin 0.32 removed Witness::taproot_annex. Replace it with an inline BIP341 annex extraction: the last witness element that begins with 0x50 is the annex. This matches the Elements c_env helper and the BIP341 specification.
Replace the unimplemented!() stub in Bitcoin::cmr() with a match table of 32-byte CMR values. Each entry is derived from the canonical primitiveJetNode.inc in libsimplicity. The table covers all jets in the Bitcoin jet set. The cost() method remains a stub pending a separate commit.
Replace the unimplemented!() cost() stub for Bitcoin jets with a match table derived from primitiveJetNode.inc (.cost values, milliweight). Add a #[cfg(test)] module that asserts every Bitcoin jet's cmr() matches the 32-byte CMR recorded in primitiveJetNode.inc, and checks representative cost() values. These guard the hardcoded tables against drift from the canonical C source.
Add Cost::get_padding_size, which returns the chain-agnostic byte length of the witness stack item required to bring a program cost within budget. The required length depends only on the item's serialized size, not its content, and is the same for Bitcoin and Elements. Add Cost::get_padding_bytes, which returns the chain-specific bytes that fill that length: - Bitcoin (cfg bitcoin, not elements): a plain all-zero item. A leading 0x50 byte would be misread as an annex, so Bitcoin must not use one. - Elements (cfg elements): an annex item: [0x50] followed by zeros. Deprecate Cost::get_padding (Elements annex form), which now delegates to get_padding_bytes. Make get_budget and is_budget_valid chain-agnostic by computing the witness-stack serialized length with explicit CompactSize math instead of the elements consensus encoder.
This was referenced Oct 5, 2026
ivanlele
reviewed
Oct 6, 2026
| /// | ||
| /// The script witness is passed as `&Vec<Vec<u8>>` in order to use | ||
| /// the consensus encoding implemented for this type. | ||
| #[cfg(feature = "elements")] |
Contributor
There was a problem hiding this comment.
I assume we do not need this anymore, bacause it was implemented in wrong way?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #386
Two independent pieces of work, kept together because both touch jet
cost accounting:
Bitcoin jet cost table
Replaces the
unimplemented!()stub inBitcoin::cost()with amatch table of milliweight values transcribed from libsimplicity's
primitiveJetNode.inc(.costfield) -- same source as the CMRtable in the previous PR.
Adds a
#[cfg(test)]self-check module that asserts every Bitcoinjet's
cmr()against the canonical value inprimitiveJetNode.incand spot-checks representative
cost()values, so both hardcodedtables are guarded against drift from the C source.
Cost padding API split
Splits
Cost::get_paddinginto:get_padding_size-- the chain-agnostic byte length needed tobring a program's cost within budget (depends only on the
witness item's serialized size).
get_padding_bytes-- the chain-specific fill content: anall-zero item for Bitcoin, vs. an annex-prefixed
[0x50, 0, 0, ...]itemfor Elements.
get_padding(Elements annex form) is deprecated and now delegatesto
get_padding_bytes.get_budget/is_budget_validbecomechain-agnostic, computing the witness-stack serialized length via
explicit CompactSize math instead of the Elements consensus
encoder -- this is what makes the Bitcoin cost table in (1)
meaningful: without it, budget checks were Elements-only.