milksad
/
rust-bitcoin-unsafe-fast
14
0
Fork 0
Code Issues Pull Requests Activity

Merge rust-bitcoin/rust-bitcoin#701: Decrease Huffman Weights to u32 

1518517374 Decrease Huffman weight type to 32 bits (Jeremy Rubin)

Pull request description:

  This builds on https://github.com/rust-bitcoin/rust-bitcoin/pull/699 but is the more bikesheddable part since it changes the API.

  > u32 of weight should be enough for any branch.
  -- Bill Gates

ACKs for top commit:
  dr-orlovsky:
    utACK 1518517374
  Kixunil:
    ACK 1518517374

Tree-SHA512: 9c507ae6129dda8dc069b0a142181a78cf89cb3ebf9d2169c46662822cb4ea9ed075bf484528f5399fe0ed383a425174a702e2d685f31c246f5a86c46ed17c3a
This commit is contained in:
Dr. Maxim Orlovsky 2021-12-11 22:40:51 +02:00
parent 31f0beb8df 1518517374
commit 9ae0f05d74
No known key found for this signature in database
GPG Key ID: AF91255DEA466640
1 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
src/util/taproot.rs
View File

@ -200,20 +200,23 @@ impl TaprootSpendInfo {
/// ///
/// - When the optimal huffman tree has a depth more than 128 /// - When the optimal huffman tree has a depth more than 128
/// - If the provided list of script weights is empty /// - If the provided list of script weights is empty
/// - If the script weight calculations overflow. This should not happen unless you are ///
/// dealing with numbers close to 2^64. /// # Edge Cases:
/// - If the script weight calculations overflow, a sub-optimal tree may be generated. This
/// should not happen unless you are dealing with billions of branches with weights close to
/// 2^32.
pub fn with_huffman_tree<C, I>( pub fn with_huffman_tree<C, I>(
secp: &Secp256k1<C>, secp: &Secp256k1<C>,
internal_key: schnorr::PublicKey, internal_key: schnorr::PublicKey,
script_weights: I, script_weights: I,
) -> Result<Self, TaprootBuilderError> ) -> Result<Self, TaprootBuilderError>
where where
I: IntoIterator<Item = (u64, Script)>, I: IntoIterator<Item = (u32, Script)>,
C: secp256k1::Verification, C: secp256k1::Verification,
{ {
let mut node_weights = BinaryHeap::<(Reverse<u128>, NodeInfo)>::new(); let mut node_weights = BinaryHeap::<(Reverse<u64>, NodeInfo)>::new();
for (p, leaf) in script_weights { for (p, leaf) in script_weights {
node_weights.push((Reverse(p as u128), NodeInfo::new_leaf_with_ver(leaf, LeafVersion::default()))); node_weights.push((Reverse(p as u64), NodeInfo::new_leaf_with_ver(leaf, LeafVersion::default())));
} }
if node_weights.is_empty() { if node_weights.is_empty() {
return Err(TaprootBuilderError::IncompleteTree); return Err(TaprootBuilderError::IncompleteTree);
@ -223,7 +226,7 @@ impl TaprootSpendInfo {
let (p1, s1) = node_weights.pop().expect("len must be at least two"); let (p1, s1) = node_weights.pop().expect("len must be at least two");
let (p2, s2) = node_weights.pop().expect("len must be at least two"); let (p2, s2) = node_weights.pop().expect("len must be at least two");
// Insert the sum of first two in the tree as a new node // Insert the sum of first two in the tree as a new node
// N.B.: p1 + p2 can never actually saturate as you would need to have 2**64 max u64s // N.B.: p1 + p2 can not practically saturate as you would need to have 2**32 max u32s
// from the input to overflow. However, saturating is a reasonable behavior here as // from the input to overflow. However, saturating is a reasonable behavior here as
// huffman tree construction would treat all such elements as "very likely". // huffman tree construction would treat all such elements as "very likely".
let p = Reverse(p1.0.saturating_add(p2.0)); let p = Reverse(p1.0.saturating_add(p2.0));