Conversation
Cargo.toml
Outdated
There was a problem hiding this comment.
I am a little puzzled why it's needed now or how it was working without this?
There was a problem hiding this comment.
It worked because we are not creating contexts in bitcoin itself via Secp256k1::new.
However, since we are re-exporting secp256k1, and depending crates (such as lightning) do want to create contexts, it's much nicer to pull this feature in, so they don't have to declare the dependency on secp256k1 themselves, just in order to add the feature.
|
Apologies, this makes the embedded test fail. Will look into it tomorrow. |
004fe49 to
849ec3f
Compare
|
Actually, the embedded test is fixed now, please take another look. |
dr-orlovsky
left a comment
There was a problem hiding this comment.
utACK
Actually there is a companion PR in secp256k1 rust-bitcoin/rust-secp256k1#314 which also fixes bug related to the feature use - no idea how we got no_std working without it
|
utACK 849ec3f |
|
Why does this have label Minor API change? I don't see any API change. |
|
It was probably my mistake (I thought that it is either major or minor API change, it can't be none) |
ac16e05 Add no_std support (mcroad) Pull request description: Closes #201. Related to bitcoindevkit/bdk#205 Not ready. - [x] `no_std` example - [x] updated readme with instructions - [x] tests pass - [x] rust-bitcoin/rust-bitcoin#637 includes `secp256k1/alloc` feature in `bitcoin/no-std`. Released on `0.28.0` - [x] rust-bitcoin/rust-bitcoin#690 Rust `1.47` set as `no_std` MSRV. Released in `0.28.1`. Maintains backward compatibility. To use it in a `no_std` context set `default-features = false` and enable the `no-std` feature. ~~To the maintainers: I added the `no-std-compat` crate. It wraps `core` and `hashbrown` and makes them look like `std`. This is a different than what `rust-bitcoin` did. They use `core` and `hashbrown` directly. I believe using `no-std-compat` makes the code more readable. I'd like to hear your thoughts on this.~~ Now using `hashbrown` and `core` directly. ACKs for top commit: sanket1729: ACK ac16e05 Tree-SHA512: 5c26cb50374b7844acbcc5a7607f5710ce19ec0aff4caed1346ed4a2fb708a909205a7d87cc27a773624f43b2a99a71c3ba4bb1cdf2dfec0584833df00b9f032
Adds a `since=10.0.0` to all `max_satisfaction_weight` deprecations. Adds a note telling users to check rust-bitcoin#476 for more details. Closes rust-bitcoin#637.
…ax_satisfaction_weight` 7fc7661 Deprecate across the board max_satisfaction_weight (Jose Storopoli) Pull request description: Adds a `since=10.0.0` to all `max_satisfaction_weight` deprecations. Adds a note telling users to check rust-bitcoin#476 for more details. Closes rust-bitcoin#637. ACKs for top commit: apoelstra: ACK 7fc7661 tcharding: ACK 7fc7661 Tree-SHA512: 90a75bd44d5b0bec5044fc58186323f6c992e43958a912d9d36a1bda411ef6156076ac2125ee6dc8806a742b0aef046ae1f540911301972c8c2f95bb02ec8980
ac16e05aa9943152e4235b490fd4ad03a496a7c1 Add no_std support (mcroad) Pull request description: Closes #201. Related to bitcoindevkit/bdk#205 Not ready. - [x] `no_std` example - [x] updated readme with instructions - [x] tests pass - [x] rust-bitcoin/rust-bitcoin#637 includes `secp256k1/alloc` feature in `bitcoin/no-std`. Released on `0.28.0` - [x] rust-bitcoin/rust-bitcoin#690 Rust `1.47` set as `no_std` MSRV. Released in `0.28.1`. Maintains backward compatibility. To use it in a `no_std` context set `default-features = false` and enable the `no-std` feature. ~~To the maintainers: I added the `no-std-compat` crate. It wraps `core` and `hashbrown` and makes them look like `std`. This is a different than what `rust-bitcoin` did. They use `core` and `hashbrown` directly. I believe using `no-std-compat` makes the code more readable. I'd like to hear your thoughts on this.~~ Now using `hashbrown` and `core` directly. ACKs for top commit: sanket1729: ACK ac16e05aa9943152e4235b490fd4ad03a496a7c1 Tree-SHA512: 5c26cb50374b7844acbcc5a7607f5710ce19ec0aff4caed1346ed4a2fb708a909205a7d87cc27a773624f43b2a99a71c3ba4bb1cdf2dfec0584833df00b9f032
secp256k1/allocfor no-std use