Skip to content

Cpunet rebase 0.33.0 beta#5

Closed
Sansh2356 wants to merge 1643 commits intocpunetfrom
cpunet-rebase-0.33.0-beta
Closed

Cpunet rebase 0.33.0 beta#5
Sansh2356 wants to merge 1643 commits intocpunetfrom
cpunet-rebase-0.33.0-beta

Conversation

@Sansh2356
Copy link

No description provided.

rustaceanrob and others added 30 commits January 16, 2026 13:45
`Params` is not included in the `bitcoin-network-kind` crate, and this
method simply takes the network from params and calls `ok`. This
conversion is already possible via `TryFrom`.
Introduce `bitcoin-network-kind` to `p2p` and update lock files.
Encoder/decoder types are not typically exported outside of the module
they are defined in. The BlockTimeDecoder (and associated error) are.

Remove BlockTimeDecoder and BlockTimeDecoderError from root level
re-export in primitives.
… unchecked blocks

f26ddba Use as_parts to encode Block<Unchecked> without cloning (Alkamal01)

Pull request description:

  Removes an unnecessary clone in `Block<Unchecked>` encoding.
  Based on review feedback, this adds `as_parts` to `Block<Unchecked>` instead of introducing new getters. That lets us encode without cloning while keeping the API stable for the 1.0 release.


ACKs for top commit:
  tcharding:
    ACK f26ddba
  apoelstra:
    ACK f26ddba; successfully ran local tests


Tree-SHA512: 224dbb6dd8e87ade12c0c2e70257d04710d09a06fae028118beef53ffd88d98b6ab8d70d6cad484514f07043c9072320b49fd23605b1769cbece76566a8ab7ee
…e inputs

af7a11b primitives: reject transaction with duplicate inputs (jrakibi)

Pull request description:

  As part of adding validation rules to transactions, this check rejects transactions with duplicate inputs during the decoding stage
  
  Also updated a test case in the encode/decode roundtrip, the test was using duplicated inputs which causes it to fail with the current implementation.
  
  Addresses part of rust-bitcoin#5383
  
  Related: CVE-2018-17144


ACKs for top commit:
  apoelstra:
    ACK af7a11b; successfully ran local tests
  tcharding:
    ACK af7a11b


Tree-SHA512: d1d071973b855ee83af42c42c23bbda2207d8a6dda1f90208ce25d98f144ba7ce927e9dc1073ce57187e89aa7d37ac0b5eb1fe75962d3e15dd29c562ad2638be
…f funding utxos

a5bd502 Fix unreachable error bug during iteration of funding utxos (Shing Him Ng)

Pull request description:

  Found this while working on a psbt fuzz target:
  
  ```
  INFO: Running with entropic power schedule (0xFF, 100).
  INFO: Seed: 3835569058
  INFO: Loaded 1 modules   (61329 inline 8-bit counters): 61329 [0x100a2acf0, 0x100a39c81),
  INFO: Loaded 1 PC tables (61329 PCs): 61329 [0x100a39c88,0x100b29598),
  target/aarch64-apple-darwin/release/bitcoin_arbitrary_psbt: Running 1 inputs 1 time(s) each.
  Running: fuzz/artifacts/bitcoin_arbitrary_psbt/crash-ba0bb9c6187caa78cd865a232ef56ea1a690e25b
  
  thread '<unnamed>' (7096951) panicked at bitcoin/src/psbt/mod.rs:204:18:
  internal error: entered unreachable code
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  ==48521== ERROR: libFuzzer: deadly signal
      #0 0x0001012893c4 in __sanitizer_print_stack_trace+0x28 (librustc-nightly_rt.asan.dylib:arm64+0x5d3c4)
      #1 0x0001007c8300 in fuzzer::PrintStackTrace()+0x30 (bitcoin_arbitrary_psbt:arm64+0x100354300)
      #2 0x0001007bc7e4 in fuzzer::Fuzzer::CrashCallback()+0x54 (bitcoin_arbitrary_psbt:arm64+0x1003487e4)
      #3 0x00019914f740 in _sigtramp+0x34 (libsystem_platform.dylib:arm64+0x3740)
      #4 0x000199145884 in pthread_kill+0x124 (libsystem_pthread.dylib:arm64+0x6884)
      #5 0x00019904a84c in abort+0x78 (libsystem_c.dylib:arm64+0x7984c)
      rust-bitcoin#6 0x0001008429c4 in _RNvNtNtNtCsk9AQ7OSayGk_3std3sys3pal4unix14abort_internal+0x8 (bitcoin_arbitrary_psbt:arm64+0x1003ce9c4)
      rust-bitcoin#7 0x000100842820 in _RNvNtCsk9AQ7OSayGk_3std7process5abort+0x8 (bitcoin_arbitrary_psbt:arm64+0x1003ce820)
      rust-bitcoin#8 0x00010083d9fc in _RNCNvCsaBYAWE6hvc2_13libfuzzer_sys10initialize0B3_+0xb8 (bitcoin_arbitrary_psbt:arm64+0x1003c99fc)
      rust-bitcoin#9 0x0001008174d4 in _RNvNtCsk9AQ7OSayGk_3std9panicking15panic_with_hook+0x264 (bitcoin_arbitrary_psbt:arm64+0x1003a34d4)
      rust-bitcoin#10 0x00010080b5b0 in _RNCNvNtCsk9AQ7OSayGk_3std9panicking13panic_handler0B5_+0x6c (bitcoin_arbitrary_psbt:arm64+0x1003975b0)
      rust-bitcoin#11 0x000100802f0c in _RINvNtNtCsk9AQ7OSayGk_3std3sys9backtrace26___rust_end_short_backtraceNCNvNtB6_9panicking13panic_handler0zEB6_+0x8 (bitcoin_arbitrary_psbt:arm64+0x10038ef0c)
      rust-bitcoin#12 0x00010080bb94 in _RNvCseYE12Li5r0M_7___rustc17rust_begin_unwind+0x1c (bitcoin_arbitrary_psbt:arm64+0x100397b94)
      rust-bitcoin#13 0x00010084311c in _RNvNtCsh0x4TIixgmZ_4core9panicking9panic_fmt+0x24 (bitcoin_arbitrary_psbt:arm64+0x1003cf11c)
      rust-bitcoin#14 0x0001008430f4 in _RNvNtCsh0x4TIixgmZ_4core9panicking5panic+0x10 (bitcoin_arbitrary_psbt:arm64+0x1003cf0f4)
      rust-bitcoin#15 0x00010056c670 in _RNvMNtCs9rLNVcx1A2L_7bitcoin4psbtNtB2_4Psbt39internal_extract_tx_with_fee_rate_limit+0x4e0 (bitcoin_arbitrary_psbt:arm64+0x1000f8670)
      rust-bitcoin#16 0x00010049ddd8 in _RNvNvCshHXwvrCOqYg_22bitcoin_arbitrary_psbt1__19___libfuzzer_sys_run arbitrary_psbt.rs:41
      rust-bitcoin#17 0x0001004a545c in rust_fuzzer_test_input lib.rs:276
      rust-bitcoin#18 0x0001007bad98 in _RINvNvNtCsk9AQ7OSayGk_3std9panicking12catch_unwind7do_callNCNvCsaBYAWE6hvc2_13libfuzzer_sys15test_input_wrap0lEBY_+0xc4 (bitcoin_arbitrary_psbt:arm64+0x100346d98)
      rust-bitcoin#19 0x0001007bba60 in __rust_try+0x18 (bitcoin_arbitrary_psbt:arm64+0x100347a60)
      rust-bitcoin#20 0x0001007ba698 in LLVMFuzzerTestOneInput+0x16c (bitcoin_arbitrary_psbt:arm64+0x100346698)
      rust-bitcoin#21 0x0001007be09c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long)+0x158 (bitcoin_arbitrary_psbt:arm64+0x10034a09c)
      rust-bitcoin#22 0x0001007d955c in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long)+0xd8 (bitcoin_arbitrary_psbt:arm64+0x10036555c)
      rust-bitcoin#23 0x0001007de1cc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long))+0x1b8c (bitcoin_arbitrary_psbt:arm64+0x10036a1cc)
      rust-bitcoin#24 0x0001007eab84 in main+0x24 (bitcoin_arbitrary_psbt:arm64+0x100376b84)
      rust-bitcoin#25 0x000198d7dd50  (<unknown module>)
  
  NOTE: libFuzzer has rudimentary signal handlers.
        Combine libFuzzer with AddressSanitizer or similar for better crash reports.
  SUMMARY: libFuzzer: deadly signal
  ────────────────────────────────────────────────────────────────────────────────
  ```
  
  I wasn't positive on if i should group it with `Error::MissingUtxo` and return `ExtractTxError::MissingInputAmount`


ACKs for top commit:
  tcharding:
    ACK a5bd502
  apoelstra:
    ACK a5bd502; successfully ran local tests


Tree-SHA512: 0fcc7663a5a3458f1eb5a968e200928c5476dfcce9a765437bab5987294373ba8e919d8e606de06ee69acda2100ffb348907173d8c9ce7a4cc62efb5ad108f8b
In some cases, we may have an Encoder instance, without a corresponding
Encodable. In these cases, having a way to flush the encoder to a vec
and/or a writer is extremely useful to avoid having to replicate
the logic of encode_to_* functions.

Add flush_to_vec and flush_to_writer functionality to flush Encoder
objects to a Vec or Write instance respectively.
Rejects transactions with total output value exceeds MAX_MONEY
See CVE-2010-5139
Add batched allocation for witness decoder (data area).
we allocate incrementally in ~1 MB batches

The current approach automatically addresses the concerns raised in
rust-bitcoin#5258 and
rust-bitcoin#5239 (comment)

we aslo add `reserve_batch` to Mutants exclusion list
Mutation testing in WitnessDecoder::reserve_batch changes the buffer
allocation logic and they cause infinite loop during decoding
In order to allow for Target to eventually be moved out from bitcoin,
it is necessary to decouple its dependency on Params. Since it is
necessary to maintain the difficulty calculations, a Params-less
variation is introduced that the original version can call through to.

Add difficulty_with_max and difficulty_float_with_max to Target.
In order to solve the issue of imprecise types for from_str in
XOnlyPublicKey, a wrapper type was implemented, alongside a
corresponding narrow error type. This solution provided a cleaner
interface for such keys, in place of directly working with secp256k1
XOnlyPublicKey types.

Add a wrapper type for secp256k1::Keypair to tighten the error type
for from_str.
…uts worst case scenario

bd8a422 benches: Add block decode and validate benchmarks (jrakibi)
5871fcb benches: Add benchmark to test duplicate-inputs worst case scenario (jrakibi)

Pull request description:

  Related to rust-bitcoin#5402 
  
  I tested the worst-case scenario by putting the duplicate at the very end.
  
  The 3-checks algorithm achieves the following performance for 1000 inputs:
  
  - BTreeSet (existing implementation):
`[47.464 µs 47.867 µs 48.289 µs]`
  
  - Sorted list:
`[14.585 µs 14.640 µs 14.705 µs]` (about 3.3× faster than BTreeSet)
  
  - Pairwise:
`[697.03 ns 707.24 ns 722.44 ns]`
  
  This is about 67× faster than BTreeSet.

  
  Weirdly enough, pairwise performed better than BTreeSet even for 10,000 inputs (see graph below). I was expecting it to be slower as the size increases.

  
  *I haven’t included the bucket-sort idea mentioned here rust-bitcoin#5402 (comment) because of the DoS risk, but if it’s worth adding to this benchmark, I can do it.*
  
  I also ran a benchmark with 10_000 inputs that I didn’t include in this code, and the result is that pairwise is always performing better. The graph below shows the result for 10,000 inputs.


  
  <img width="1024" height="532" alt="image" src="https://github.com/user-attachments/assets/a5610983-b59d-4e40-addb-45d5f3cfa3c0" />
  
  *I’m not very familiar with Criterion benchmarking, so if anything else is needed, let me know*
  
  Addresses rust-bitcoin#5410


ACKs for top commit:
  apoelstra:
    ACK bd8a422; successfully ran local tests
  tcharding:
    ACK bd8a422


Tree-SHA512: 4830de6553aa522d5df0e28f4a72910605154d6ca4ea48fbc48d995b6d7070620bfdb5998ae53b895a3d7f8a6b7616ff389e4b614263bbd8492debfd0e2edf0a
The docstring in Core outlines an algorithm from Core for computing
the inverse of a 256-bit integer, which is ultimately used to convert
Work to/from Target.

Introduce a permalink to the code in Core on Github.
The docstrings on the MAX_ATTAINABLE constants on Target differ from
one another. These should use the same wording to clarify that they
are they represent the same value on different networks.

Adjust docstring wording for Target::MAX_ATTAINABLE_* constants.
Since bitcoin-network-kind now exists, we can use its types in bitcoin.
However, some functionality on the current bitcoin Network type doesn't
(and can't) exist in the bitcoin-network-kind crate.

Split functionality of Network into NetworkExt extension trait.
With the introduction of bitcoin-network-kind, the network types can
all be removed from bitcoin in favour of re-exports from the network
crate.

Remove Network, NetworkKind, TestnetVersion and ParseNetworkError from
bitcoin::network, and re-export the types from bitcoin-network-kind.
The MAX_ATTAINABLE_* constants in Target represent compact lossy values
of the target limits in Bitcoin Core. In order to ensure that these are
correctly converted here, we should compare against the original
known-correct values from Bitcoin Core.

Introduce a test case to assert that converting to then from
CompactTarget yields the MAX_ATTAINABLE_* consts.
31ba7e7 units: Correctly group deps (Tobin C. Harding)

Pull request description:

  By convention optional dependencies are grouped separately to non-option ones.
  
  Fix: rust-bitcoin#5516


ACKs for top commit:
  apoelstra:
    ACK 31ba7e7; successfully ran local tests


Tree-SHA512: 983daf15802ee35cd505a1d3342fe283b1884aa6b840749881f254c3b5b1776ffd0d171d863a3ef7a46d8a65f3d90c695666bdeb8f0220333eb39b765d958c2f
349ca99 bitcoin: Replace Network types (Mitchell Bagot)
dd52896 Split Network functionality into extension trait (Mitchell Bagot)

Pull request description:

  https://crates.io/crates/bitcoin-network-kind is released now. Most of the code in bitcoin::network can now be deleted and replaced by re-exports of said crate.
  
  - Patch 1 splits Network to an extension trait for existing public logic not in the bitcoin-network-kind crate.
  - Patch 2 removes the types present in bitcoin-network-kind, re-exporting those types from the network crate.
  
  Closes rust-bitcoin#5519


ACKs for top commit:
  apoelstra:
    ACK 349ca99; successfully ran local tests


Tree-SHA512: 613640a7d205b3cb795cf5a5d26d3fd8465a1c353706937a873bb89499e42854e7fa7ff6d58e21fe73b91ec7b2ecba8da9a393375fbd87ad0399bd7f8f7284b7
…le LLMs

3d80a99 Fix rustdoc typos and grammar with three LLMs (Jamil Lambert, PhD)
8ff6130 Fix typos highlighted in closed LLM PRs (Jamil Lambert, PhD)
4ff621d Fix incorrect comments in units (Jamil Lambert, PhD)

Pull request description:

  There have been a few LLM generated typo PRs that were closed without merging due to the policy of this repo, but still had real typos that could be fixed.
  
  Fix the comments and typos highlighted in previously closed PRs. Including the incorrect calculation of `u16::MAX * 512` and a copy paste error referencing the wrong function.
  
  Run GPT-5.2, Claude Sonnet 4.5 and Gemini 3 Pro over the rustdocs and markdown files of the entire repo. Review what they changed and remove any incorrect or unnecessary changes. All three LLMs did find different things to fix.


ACKs for top commit:
  tcharding:
    ACK 3d80a99
  apoelstra:
    ACK 3d80a99; successfully ran local tests


Tree-SHA512: 02fe69fbd23bd2c1857cc1e91613278496f120b81ea4a40000f491e910b99ef518d3d7ec5300ff8fb80083f7dd68876f1b8262fdbe6d241f80d55cc09c64c12b
NumOpResult has a similar API to core's Result type, most of which is
untested. Other functionality, like the is_overflow() function are also
not tested by existing tests.

Implement tests for unwrap, expect, ok, map and other similar functions
in NumOpResult. Adjust tests to cover is_overflow and is_div_by_zero.
65fb769 Fix header hex test case comments (Mitchell Bagot)

Pull request description:

  The comments say 'transaction', when the test case only relates to functionality on the Header type.
  
  Replace 'transaction' with 'header' in header hex round trip test comments.


ACKs for top commit:
  jamillambert:
    ACK 65fb769
  shinghim:
    ACK 65fb769
  tcharding:
    ACK 65fb769
  apoelstra:
    ACK 65fb769; successfully ran local tests


Tree-SHA512: cca42dc29e2ceefa03a4cc2eac8ffeab395e17f70de75249a32ba0c95abcd96099692606a9a891282f8e9111f32a10dc0e339c6f478dbb2e3f4776cf4e010b4f
…Add`

aceb40f p2p: Implement `encoding` traits for `FilterAdd` (rustaceanrob)

Pull request description:

  Trying my hand at a pure byte vector en/decoder. I will hold off on pushing more until there is a review cycle on the other types.


ACKs for top commit:
  apoelstra:
    ACK aceb40f; successfully ran local tests
  nyonson:
    ACK aceb40f
  tcharding:
    ACK aceb40f


Tree-SHA512: 323cef6dd9ef469b27fc039f52722197682def3e8bcad3f7557025abe4b517ebad8f0f101e1080f2ebf327c87f9c72b05672d88067c79e54b560e05997d91fbd
Here is an example of a field with a single byte representation. Does it
make sense to use the `ArrayEncoder` here? I think so, unless there is
something I'm missing.

I also took the liberty of adding a variant to the unknown bloom flag
error that actually reports the unknown flag back. Not that it should
see any use.
Another low-sakes encoding implementation building on the previous
commit.
…ot export

825cdf2 primitives: Remove BlockTime decoder from root export (Mitchell Bagot)

Pull request description:

  Encoder/decoder types are not typically exported outside of the module they are defined in. The BlockTimeDecoder (and associated error) are.
  
  Remove BlockTimeDecoder and BlockTimeDecoderError from root level re-export in primitives.
  
  Closes rust-bitcoin#5522


ACKs for top commit:
  tcharding:
    ACK 825cdf2
  apoelstra:
    ACK 825cdf2; successfully ran local tests


Tree-SHA512: cae39cc7f96364b877ce37cbcb18f3e0b5a63379621a81e887d859b11dbce3c417ca65a44586e542a445b13a9861f530c35676f9fd8a986f960b191f9a100a66
Allow decoding a p2p network message header.

The header can then be read using the consensus_encoding crate:

```
let V1MessageHeader {command, ..} =
    decode_from_read_unbuffered::<V1MessageHeader, _>(&mut r).unwrap()
```

Update p2p/src/message.rs

Co-authored-by: Mitchell Bagot <[email protected]>
…olVersion`

5d0ae39 p2p: Implement `encoding` traits for `ProtocolVersion` (rustaceanrob)

Pull request description:

  Per rust-bitcoin#5452 it doesn't look like the `encoding` traits will be macro-ized anytime soon, so we might as well chip away with the types that comprise `NetworkMessage`


ACKs for top commit:
  nyonson:
    ACK 5d0ae39
  tcharding:
    ACK 5d0ae39
  apoelstra:
    ACK 5d0ae39; successfully ran local tests


Tree-SHA512: ace87a9491dca8273420f3dc745db931d80b9ae36971a0a9cb524f35981542444df0d36188b76255c4764fc51f96291c93059535c854072fa19cd6bc9f0bbf05
apoelstra and others added 28 commits February 20, 2026 00:28
7370bd7 Remove parity argument and return on add_tweak and tweak_add_check (Mitchell Bagot)
5724d3e Remove parity argument and rename public_key (Mitchell Bagot)
7d11f9b Return only XOnlyPublicKey from from_keypair (Mitchell Bagot)
b23e551 Return parity from serialize in XOnlyPublicKey (Mitchell Bagot)
34744da Change new constructor to from_secp (Mitchell Bagot)
dcd361c Introduce parity field on XOnlyPublicKey (Mitchell Bagot)
731cbac Replace serde derive with call-through impl (Mitchell Bagot)
583c168 Introduce as_inner on XOnlyPublicKey (Mitchell Bagot)

Pull request description:

  Currently our XOnlyPublicKey type copies rust-secp by having constructors that yield a key and parity as a tuple. Sometimes you're supposed to ignore the parity and sometimes not, which is indicated by some functions taking the parity and others not. By introducing a parity field on the key itself, the necessity to consider when to include parity can be reduced.
  
  - Patch 1 adds an as_inner accessor to XOnlyPublicKey and replaces uses of to_inner with it where appropriate.
  - Patch 2 replaces serde derived implementation with an explicit call-through implementation.
  - Patch 3 introduces a parity field in XOnlyPublicKey, alongside accessor and setter functions.
  - Patch 4 renames the new constructor to from_secp.
  - Patch 5 introduces a parity value to the return from serialize.
  - Patch 6 removes the parity return value from from_keypair.
  - Patch 7 renames public_key to to_public_key and removes the parity argument in favour of the internal parity field.
  - Patch 8 removes the parity argument and return values from add_tweak and tweak_add_check
  
  Based on discussions in rust-bitcoin#5575


ACKs for top commit:
  tcharding:
    ACK 7370bd7
  apoelstra:
    ACK 7370bd7; successfully ran local tests


Tree-SHA512: cb7d68f037f51558b6e75cfaaef68273ac90d710d71e78a21275d3bc80518eae7d5d77a033361cdc04a2721e6ba9cdde475410c5017d36071a662c0e40199476
The PublicKey and PrivateKey types rely on public access to the inner
fields in many places to instantiate the type. Since we wish to
encapsulate the type, this inner access should instead be wrapped
through constructors.

Introduce from_secp, and from_secp_uncompressed constructors and
replace all instantiation of PublicKey and PrivateKey with calls to
these.
While all construction of PublicKey and PublicKey now goes through the
from_secp constructors, read access to the inner fields are still
commonplace.

Introduce as_inner function for PrivateKey and to_inner for PublicKey
and remove all direct access to the inner fields.
As with the inner fields, the compressed and network fields of PublicKey
and PrivateKey allows public access for read/write. To allow for
encapsulation, read access should be limited to an accessor function.

Introduce compressed() accessor function for PublicKey and compressed()
and network() accessor functions for PrivateKey. Replace all direct
access to inner fields with use of the accessor functions.
With the previous changes to the PublicKey and PrivateKey types, both
can now be encapsulated to control the scope of access to the inner
fields.

Move PublicKey and PrivateKey to encapsulated module and add them to
the pub use.
0604e09 Clean up accidentally checked in files (Nick Johnson)

Pull request description:

  Oof, my bad here, I am not sure how these snuck in...think I was testing out some random embedded tests stuff and jj sucked these up. Silver-lining, they are pretty small files so maybe not super painful for the git history?


ACKs for top commit:
  tcharding:
    ACK 0604e09
  apoelstra:
    ACK 0604e09; successfully ran local tests


Tree-SHA512: d72a2573ed60c66009f95082185037f680a1f4efbc5888c52033a08196363235fcf8184aac1c828b49b405d1efc4f944ecce7c39429fbab8ade4d01b994479e5
be83540 update renamed clippy lints (Conger Rassen)

Pull request description:

  Update renamed clippy lint names
  
  empty_enum - empty_enums
  unchecked_duration_subtraction - unchecked_time_subtraction


ACKs for top commit:
  tcharding:
    ACK be83540
  apoelstra:
    ACK be83540; successfully ran local tests


Tree-SHA512: f63aa54dfcb55a289a2a73d12681024391e9c0c795fe52b7b79f4faff513249dfa18db4b17080cef1e61d96d1f0e179ea925fb11d0c59ced95ca6c3b0b6793ed
118b898 Encapsulate PublicKey and PrivateKey (Mitchell Bagot)
41d946f Remove public access to all fields of PublicKey and PrivateKey (Mitchell Bagot)
9506d45 Remove public access to inner field of PublicKey and PrivateKey (Mitchell Bagot)
2f74f3e Introduce from_secp constructors for PublicKey and PrivateKey (Mitchell Bagot)

Pull request description:

  Following patterns elsewhere in bitcoin, the wrapper types in the crypto module should be encapsulated to ensure a consistent interface for access and to prevent implementation/structure details from requiring substantial refactors.
  
  - Patch 1 introduces a set of from_secp constructors for both types.
  - Patch 2 removes public access to the inner field in both types. PublicKey uses a to_inner function, PrivateKey an as_inner.
  - Patch 3 removes public access to the remaining fields in both types, introducing accessors functions.
  - Patch 4 moves the PrivateKey and PublicKey types to the encapsulate submodule.
  
  Contributes to rust-bitcoin#5536


ACKs for top commit:
  tcharding:
    ACK 118b898
  apoelstra:
    ACK 118b898; successfully ran local tests


Tree-SHA512: bfa254802c8b7de1ecd9282c3e93f142c8643ee5dd4375af6d1c1a36e56adf02278828ae4c2f6cbe53355dd4c8b4b5ddee440b85d9d680dee929de7892dc2316
9a78efc bitcoin: Grab 0.32.8 changelog (Tobin C. Harding)

Pull request description:

  As is customary round here we forgot to merge the changelog back into master after releasing the latest `v0.32` point release.
  
  Grab the changelog from the `0.32.x` branch.
  
  Close rust-bitcoin#5663


ACKs for top commit:
  apoelstra:
    ACK 9a78efc; successfully ran local tests


Tree-SHA512: 0b12b25ac4da34357146a0aaae89a65034d947161dd84281341364f66f1bf959e240d3d26989b603f2633c0d6b5342731510872bd0dad0033520ea756b0ab7c2
ed19c45 p2p: Re-export hash types (Mitchell Bagot)

Pull request description:

  In bitcoin 0.32.8, the FilterHash and FilterHeader hash types were exported from the top level of the crate. Following the split of p2p, these types now need to be accessed inside of the module in p2p. To match the previous interface (albeit in the new crate), these should be re-exported from the top level of the p2p crate.
  
  Re-export FilterHash and FilterHeader from the top level of the p2p crate.
  
  Closes rust-bitcoin#5638


ACKs for top commit:
  tcharding:
    ACK ed19c45
  apoelstra:
    ACK ed19c45; successfully ran local tests


Tree-SHA512: d3640cfda0f38f8d4e78f35f8ddd19290544a09446a7142417345a3b96da8ad11a48875a2201f421c7efdaab5e30b5a69441236f6865ebd943d23d0b88ab0b08
6522927 Fix PSBT key deserialisation byte size (Mitchell Bagot)

Pull request description:

  The PSBT Key decoding makes an assumption that the key type will always encode in a single byte in it's compact form. While this is sometimes true, it is not correct according to the spec and may fail in cases where key type values are large.
  
  Fix the encode and decode implementations on Key to correctly calculate the type value size to add to the key length size.
  
  Closes rust-bitcoin#5622


ACKs for top commit:
  tcharding:
    ACK 6522927
  apoelstra:
    ACK 6522927; successfully ran local tests


Tree-SHA512: d69d5345feb57b4731d8f04ff1a264072077c18189b098c8d5bd74f05ae734e137b5855bad3e0e7bda7682e5d2533f0afa3d305a8f673ea4f272cd0dd0feee09
Turns out that the `-rc.0` suffix causes way more problems than it
solves because of how `cargo` resolves the version numbers and what we
intended on using the RC releases for.

In brief

- We wanted to be able to do breaking changes if required
- We wanted to signal that these releases were almost there (TM)
- We wanted to be able to do downstream testing including releasing
  downstream crates with the RC releases as part of their public API.

In hindsite we messed up and should have just kept iterating as normal
until we were ready.

Re-release the whole stack without any rc suffix's. However keep
`bitcoin 0.33.0-beta` because we want 0.32.0 to be the latest stable
release and its important that it shows as such on docs.rs

Also, for pre-1.0 crates that had an rc release just jump to the next
version i.e., `io 0.4.0-rc.0` goes to `io 0.5.0`. Just for good
measure.


crate           |  latest stable  |  latest RC  | with this applied
-----------------------------------------------------------
consensus_encoding    0.0.0         1.0.0-rc.3      0.1.0
units                 0.2.0         1.0.0-rc.4      0.3.0
primitives            0.101.0       1.0.0-rc.2      0.102.0
hashes                0.19.0          -             0.20.0
io                    0.3.0         0.4.0-rc.0      0.5.0
base58ck              0.3.0           -             0.4.0


bitcoin - 0.33.0-beta.0 to be yanked. Release as 0.33.0-beta

p2p - updated deps, unrelased so no other changes.
internals - not touched (currently 0.5.0)
chacha20_poly1305 - not touched
418685a Re-release without rc suffix (Tobin C. Harding)

Pull request description:

  Turns out that the `-rc.0` suffix causes way more problems than it solves because of how `cargo` resolves the version numbers and what we intended on using the RC releases for.
  
  In brief
  
  - We wanted to be able to do breaking changes if required
  - We wanted to signal that these releases were almost there (TM)
  - We wanted to be able to do downstream testing including releasing downstream crates with the RC releases as part of their public API.
  
  In hindsight we messed up and should have just kept iterating as normal until we were ready.
  
  Re-release the whole stack without any rc suffix's. However keep `bitcoin 0.33.0-beta` because we want 0.32.0 to be the latest stable release and its important that it shows as such on docs.rs
  
  Also, for pre-1.0 crates that had an rc release just jump to the next version i.e., `io 0.4.0-rc.0` goes to `io 0.5.0`. Just for good measure.
  
  
  crate           |  latest stable  |  latest RC  | with this applied    |
  ----------------|---------------------|-----------------|---------------------------|
  consensus_encoding | 0.0.0 | 1.0.0-rc.3 | 0.1.0
  units  | 0.2.0 | 1.0.0-rc.4  | 0.3.0
  primitives | 0.101.0 | 1.0.0-rc.2  | 0.102.0
  hashes  | 0.19.0 |  - | 0.20.0
  io | 0.3.0 | 0.4.0-rc.0 | 0.5.0
  base58ck | 0.3.0 | - |  0.4.0
  
  
  
  - bitcoin - 0.33.0-beta.0 to be yanked. Release as 0.33.0-beta
  - hashes 0.19.0 to be yanked.
  - p2p - updated deps, unrelased so no other changes. internals - not touched (currently 0.5.0)  
  - chacha20_poly1305 - not touched
  
  This PR fell out of a phone discussion between Andrew and myself where we discussed rust-bitcoin#5358.


ACKs for top commit:
  apoelstra:
    ACK 418685a; successfully ran local tests


Tree-SHA512: b4d9ad8364c969ec5344a0ece41629d5766c1348e211e0562fc15fd4c81674ba8cbcccda7b47ec861f069a28fbd7de52b9a8e6fe471a9e1ea639d78ae23f30ec
Defensively added to the Decoder trait itself since the performance
impact is negligible.
077c6bb api: Update sha3_256 hashing api (Liam Aharon)
1a15728 hashes: Fix sha3_256 incremental hashing (Liam Aharon)

Pull request description:

  The current sha3-256 implementation incorrectly applies padding at the end of every `input()` call, treating each data chunk as a standalone message. This resulted in hashing `Pad(a) || Pad(b)` instead of `Pad(a || b)` when input is called more than one time before finalizing.
  
  Refactor `HashEngine`'s `input()` to buffer partial blocks instead of padding and absorbing them immediately, using the internal `engine_input_impl!` macro to match similar hashing algos.
  
  Move padding logic into `finalize()`, so it is applied exactly once at the end of the stream.
  
  Extend the existing test to check incremental input.
  
  Closes rust-bitcoin#5601.


ACKs for top commit:
  rustaceanrob:
    Epic, I'll have to remember the `fill` method. ACK 077c6bb
  tcharding:
    ACK 077c6bb
  jrakibi:
    ACK 077c6bb
  apoelstra:
    ACK 077c6bb; successfully ran local tests


Tree-SHA512: 58695b31d5e4557c7e45a3382d7640ca1c74c01fe74ba979a7e08fa2f170ad9d8b0bc9e3e546fa3846012a4542b2e1814347a4142ecd0246bed1cb3db9f8e3a8
…c-able sites

0276325 consensus_encoding: add track_caller to panic-able sites (Nick Johnson)

Pull request description:

  The composite `Decoder*`'s panic if a caller calls push bytes again after receiving an error. This contract is already documented in the exposed docs for `push_bytes` and `end`, but adding `track_caller` will help the caller if they do break the contract. Adding to [the `Decoder` trait itself](https://rustc-dev-guide.rust-lang.org/backend/implicit-caller-location.html#traits) so that all `Decoder*`'s inherit it.
  
  Part of rust-bitcoin#5518


ACKs for top commit:
  apoelstra:
    ACK 0276325; successfully ran local tests; assuming this actually works on trait methods like this
  tcharding:
    ACK 0276325


Tree-SHA512: 6a973a6219c1f0e6da0599efbb39fe2a098f4ddddb592d19c0655241221063e33525ec75917fd455cd7dc4105a7df6275c9144aa4020b3a7e2d353c04e1a370d
…Block`

95d530f test(p2p): Migrate merkle block deser tests to `encoding` (rustaceanrob)
885bf39 p2p: Implement `encoding` traits for `MerkleBlock` (rustaceanrob)
1743aa7 p2p: Implement `encoding` traits for `PartialMerkleTree` (rustaceanrob)

Pull request description:

  `encoding` traits for `MerkleBlock` and updated unit tests to use `encoding`


ACKs for top commit:
  tcharding:
    ACK 95d530f
  apoelstra:
    ACK 95d530f; successfully ran local tests


Tree-SHA512: c16df9abdfd4620d717984910bcc6f1575b0ece3629f0b32df80a8c9e0a4a77a151f53a5f539aeea21c55dcfa9f11356c372561ebee8d7a9de27d17ea20b6d25
…NError`

42d9d43 Update API files (Mitchell Bagot)
6bec9c1 Replace DecoderNError implementations with macro (Mitchell Bagot)
07409b2 Replace EncoderN implementations with macro (Mitchell Bagot)

Pull request description:

  The EncoderN composite encoders currently rely on composition of Encoder2 instances to achieve N > 2. Since the basic structure lends itself to unrolling, we can introduce a macro to produce encoders for any N. The DecoderNError types similarly can be trivially unrolled for arbitrary N using a macro.
  
   - Patch 1 introduces the define_encoder_n macro to define an EncoderN type.
   - Patch 2 introduces the define_decoder_n_error macro to define a DecoderNError type.
   - Patch 3 updates the api files for consensus encoding.


ACKs for top commit:
  nyonson:
    ACK 42d9d43
  tcharding:
    ACK 42d9d43
  apoelstra:
    ACK 42d9d43; successfully ran local tests; nice


Tree-SHA512: e11d46fc4cdf385ae18591ac3d402da4ca234b34ae66a42b77019956e419d8687f137ba497864ebe7a6779af8b770b93b4c02906013a9056f59053ddd9ebe034
…oly1305 structures

0df1825 dev: implement standard traits for ChaCha20-Poly1305 data types (Abeeujah)

Pull request description:

  In `rust-lightning`, `ChaCha20-Poly1305` encryption is being refactored from the local `ChaCha20Poly1305RFC` to the `chacha20-poly1305` crate.
  
  Previous local implementation had support for streaming in `ChaCha20Poly1305RFC` implementations, but the `chacha20-poly1305` doesn't have implementations that supports streaming, this leads to using the `ChaCha20` and `Poly1305` primitives.
  
  To avoid computing `Poly1305` validation twice for input and additional authenticated data, it would be cool if `Poly1305` implements `Clone`, which saves computing the MAC twice.
  
  [Downstream PR](lightningdevkit/rust-lightning#4360 (comment))


ACKs for top commit:
  tcharding:
    ACK 0df1825
  apoelstra:
    ACK 0df1825; successfully ran local tests


Tree-SHA512: eae30d8f996d525a2891e0264fdb1996accaf3c57530f5d0134f63425d1bda82ecbd4112678d91892bd15079ae36db61109beccd7c93d5dc914b8284b30c968f
4b4053c refactor(fuzz): remove custom fuzz_utils module (Erick Cestari)

Pull request description:

  Remove the hand-rolled `consume_random_bytes`, `consume_u64`, and `consume_u32` helpers and the `bitcoin_fuzz` lib crate.
  
  - Use `<&[u8]>::arbitrary` to split fuzz input into borrowed slices
  - Flatten nested match blocks into early returns for readability


ACKs for top commit:
  luisschwab:
    ACK 4b4053c
  tcharding:
    ACK 4b4053c
  apoelstra:
    ACK 4b4053c; successfully ran local tests; yeah, good idea!


Tree-SHA512: 2893dfb67ec311075073db88a05ca4dde15c3f8bd1eb1feab022e17e2db620b9c9995e50f3534c96cd0b22819904bdee9837f79abad0f86d4968d99b47804b9f
8353c09 p2p: Rename `Raw` prefix to `V1` (rustaceanrob)

Pull request description:

  Closes rust-bitcoin#5661
  
  Maybe rust-bitcoin#3157 as well?


ACKs for top commit:
  luisschwab:
    re-ACK 8353c09
  tcharding:
    ACK 8353c09
  apoelstra:
    ACK 8353c09; successfully ran local tests


Tree-SHA512: 310702ecbc25b16af8688caf898bf7e242c0a09de77364df7cd109d25662becb696d94ce1a3597509ca4cb215f2ec904ac43166f4cedd4d2031425bf511e6630
…ounds

c9cdde0 Update api (Nick Johnson)
3ea5757 consensus_encoding: remove redundant trait bounds (Nick Johnson)

Pull request description:

  I didn't find any additions for the [C-GOOD-ERR](https://rust-lang.github.io/api-guidelines/interoperability.html#error-types-are-meaningful-and-well-behaved-c-good-err) convention, but think we can drop these redundant bounds. `Error` currently has `Debug` and `Display` as supertraits. And the current implementation makes no direct use of them so no risk to API forward compatibility.


ACKs for top commit:
  tcharding:
    ACK c9cdde0
  apoelstra:
    ACK c9cdde0; successfully ran local tests


Tree-SHA512: a8f5ebec751c0b8c850869a207f085a94f01e0a71b060656cf41b031149ec980092d49580f7f08c340e5f138889a5551735e76136ca1bee00854f6fee2eefa5a
943a786 Change pow_target_spacing to u32 (Mitchell Bagot)

Pull request description:

  The pow_target_spacing is only ever used as a divisor for the pow_target_timespan (a u32 type) or cast to a u32. The loss of precision from a u64 is acceptable for the simplicity of use that this change provides.
  
  Change pow_target_spacing to u32 from u64 in Params.
  
  Closes rust-bitcoin#5641


ACKs for top commit:
  tcharding:
    ACK 943a786
  apoelstra:
    ACK 943a786; successfully ran local tests


Tree-SHA512: 3f3d7c7fc085e15885c6139e3da04631ff97765440ff84bab2ae1eb0e40bb17a9a0ae68d0788b65a5fec3d203d05c4f0c6dee3e53f9bef132f451bc21ec0d3ed
…tection

5074a7d hashes: Add cpufeatures for no_std SIMD detection (jrakibi)

Pull request description:

  Currently SIMD requires `std` because we use `is_x86_feature_detected!` and `is_aarch64_feature_detected!` macros for runtime CPU feature detection. This means `no_std` users cannot benefit from the performance boost provided by hardware SHA extensions.
  
  This adds `cpufeatures` crate as an optional dependency. When enabled, it provides runtime CPU feature detection in `no_std` environments for both x86/x86_64 and aarch64.
  
  Discussed in rust-bitcoin#5568 (comment)


ACKs for top commit:
  tcharding:
    ACK 5074a7d
  apoelstra:
    ACK 5074a7d; successfully ran local tests


Tree-SHA512: 301c47eddcae32e5bac68365ce064184f83b66c75eae62baaabcda097c5da03a110e09874c1a6338844feb01454837d5875609fcfd6199b7f1b0c0f544b62b8d
Add cpunet prefix to PoW function and update CPUNET type in param.rs

Signed-off-by: Calisto Abel Mathias <[email protected]>

Add cpunet in log message

Use version number 0.32.4-cpunet

small-fix : BlockInterval path fix in bitcoin/src/network/params.rs

Bump version to 0.32.7-pre-cpunet
Copilot AI review requested due to automatic review settings February 27, 2026 12:01
@Sansh2356 Sansh2356 closed this Feb 27, 2026
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.