Update bitcoin_hashes to 1.0#282
Open
apoelstra wants to merge 4 commits into
Open
Conversation
Member
|
CI picked up a missing change in diff --git a/elementsd-tests/src/pset.rs b/elementsd-tests/src/pset.rs
index 7ce1d95..7b90727 100644
--- a/elementsd-tests/src/pset.rs
+++ b/elementsd-tests/src/pset.rs
@@ -8,7 +8,6 @@ use crate::{setup, Call};
use bitcoin::{self, Address, Amount};
use elements::encode::serialize;
-use elements::hashes::Hash;
use elements::hex::DisplayHex as _;
use elements::pset::PartiallySignedTransaction;
use elements::{AssetId, ContractHash};
diff --git a/elementsd-tests/src/taproot.rs b/elementsd-tests/src/taproot.rs
index 8dcc6b1..6b3c4c0 100644
--- a/elementsd-tests/src/taproot.rs
+++ b/elementsd-tests/src/taproot.rs
@@ -10,7 +10,6 @@ use bitcoin::Amount;
use elements::hex;
use elements::confidential::{AssetBlindingFactor, ValueBlindingFactor};
use elements::encode::{deserialize, serialize_hex};
-use elements::hashes::Hash;
use elements::script::Builder;
use elements::secp256k1_zkp;
use elements::sighash::{self, SighashCache};
@@ -215,7 +214,7 @@ fn taproot_spend_test(
);
let tweak = secp256k1_zkp::Scalar::from_be_bytes(tweak.to_byte_array()).expect("hash value greater than curve order");
let sig = secp.sign_schnorr(
- &secp256k1_zkp::Message::from_digest_slice(&sighash_msg[..]).unwrap(),
+ &secp256k1_zkp::Message::from_digest_slice(sighash_msg.as_byte_array()).unwrap(),
&output_keypair.add_xonly_tweak(secp, &tweak).unwrap(),
);
@@ -239,7 +238,7 @@ fn taproot_spend_test(
.unwrap();
let sig = secp.sign_schnorr(
- &secp256k1_zkp::Message::from_digest_slice(&sighash_msg[..]).unwrap(),
+ &secp256k1_zkp::Message::from_digest_slice(sighash_msg.as_byte_array()).unwrap(),
&test_data.leaf1_keypair,
);
``` |
apoelstra
force-pushed
the
2026-06/hashes-1.0
branch
from
6ec9fb2 to
c2bbe9a
Compare
Member
Author
|
Nice :) two @delta1 we want to use the infallible And even then we may want to use the |
apoelstra
force-pushed
the
2026-06/hashes-1.0
branch
2 times, most recently
from
e53ca8a to
f5876db
Compare
Member
Author
|
ACK f5876db; successfully ran local tests |
apoelstra
force-pushed
the
2026-06/hashes-1.0
branch
2 times, most recently
from
40739c1 to
4e00837
Compare
Member
Author
|
On 4e00837 successfully ran local tests |
In ElementsProject#279 we fixed some slicing bugs in a fairly ugly way so that we could easily backport the bugfixes without API breakage. However, the better solution is to close the RangeProofMessage type, add a dedicated error for parsing from an array, and update all callers. This changes the CT validation logic to allow rangeproofs to contain embedded asset IDs alongside explicit assets. This differs from Elements which only allows unblinding an output if both its value and asset commitment are confidential. However, if the confidential asset is explicit, it seems like the "right thing to do" to embed the asset ID and a zero blinding factor. This matches what we do in this library in TxIn::blind_issuances_with_bfs for example.
apoelstra
force-pushed
the
2026-06/hashes-1.0
branch
from
4e00837 to
d2b0605
Compare
Oops :) apparently I did not review this code as well as I should have.
This is a fairly big commit but it's mostly mechanical and it didn't seem super helpful to pull it out into multiple commits. The bulk of the prepatory work was done in ElementsProject#278.
apoelstra
force-pushed
the
2026-06/hashes-1.0
branch
from
d2b0605 to
6b97df8
Compare
Member
Author
|
Did some nontrivial changes for the new genesis-block stuff from #276. Likely needs re-review. |
Member
Author
|
On 6b97df8 successfully ran local tests |
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
2 participants
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.
As part of our project to modernize this library and its dependencies, upgrade to bitcoin_hashes 1.0. This has a number of API improvements:
Hashtrait methods with inherent methods so you don't need to import a trait anymorefrom_slicemethods with infalliblefrom_byte_arraymethodshashmethod and other "compute a hash from arbitrary data" methods on wrapper types likeTxid; these should only be constructed in specific prescribed waysAlso includes a followup commit to #279 to improve error typing.