Skip to content

update bitcoin_hashes and elements dependencies; related cleanups - #376

Open
apoelstra wants to merge 7 commits into
BlockstreamResearch:masterfrom
apoelstra:2026-08/updates
Open

update bitcoin_hashes and elements dependencies; related cleanups#376
apoelstra wants to merge 7 commits into
BlockstreamResearch:masterfrom
apoelstra:2026-08/updates

Conversation

@apoelstra

Copy link
Copy Markdown
Collaborator

Updates the bitcoin_hashes and elements dependencies, which give us new tools for manipulating sha256 midstates and generally cleaning up our CMR/TMR/IHR computations.

Also cleans up the policy module; there is some cruft here that doesn't play nicely with the new dependencies.

…okup

It's not totally clear how we should be telling the satisfier what
tapbranch it should be signing, but this isn't it. At the time that we
call this method we pass in TapLeafHash::all_zeroes() which is
incoherent and will go away in rust-elements 0.27.0. Then the only
implementor simply ignores the value.

For now just drop it.
This will get us constant-time midstate manipulation functions.
For the other Merkle roots it's unclear how far we can go with this --
in particular it seems unlikely that we'll be able to compute a jet CMR
in a constfn because jets are generic, without serious refactorings at
least. (And const words, and some others, will require minor refactors.)

But TMRs have just 3 constructors, unit sum and product, and we can make
them all const now.
Since we stopped using compile-time generic jets, there is no longer a
reason to have a separate JetConstructible trait. The `jet` method has
all the same generics as the other CoreConstructible methods. So it
should be folded in.

This will be a mildly annoying change for downstream implementors of the
*Constructible traits. They will have to delete their JetConstructible
impl and move the `fn jet` block into their CoreConstructible impl.

The next commit will have an even more annoying change to the
CoreConstructible trait, and I figure if we're making implementors
change stuff we might as well do it all at once.
The 'assembly' fragment of the policy language is a very half-baked
feature. It provides no way to serialize (the `serialize_no_witness`
method accepts two node types: ConstructibleCmr, where it will compute a
CMR and nothing else, and Arc<ContructNode<'_>>, where it will always
fail). We have two unit tests which demonstrate "satisfying" an asm
fragment, but none which attempt to serialize the program, because this
is impossible. In other words this feature literally cannot be used
other than for in-memory unit tests.

Also one of the tests was marked #[ignore] anyway so maybe you couldn't
even do that..

The next commit will make the `serialize_no_witness` method infallible.
It's only fallible because of the possibility that you might use the asm
fragment. This will remove a gazillion .expect()s from unrelated unit
tests.

Anyway the motivation for this is not to clean up Policy (if I wanted to
do this I would also eliminate some recursion in this module) but to
update the CoreConstructible trait to always carry a type arrow. Rather
than deciding what dummy arrow to put into this dumb fragment, let's
just preemptively delete it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant