update bitcoin_hashes and elements dependencies; related cleanups - #376
Open
apoelstra wants to merge 7 commits into
Open
update bitcoin_hashes and elements dependencies; related cleanups#376apoelstra wants to merge 7 commits into
bitcoin_hashes and elements dependencies; related cleanups#376apoelstra wants to merge 7 commits into
Conversation
…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.
apoelstra
force-pushed
the
2026-08/updates
branch
from
August 20, 2026 18:31
2d48eae to
0dabd97
Compare
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.
Updates the
bitcoin_hashesandelementsdependencies, 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.