-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update to bitcoin 0.30.0 #537
Conversation
PR title has typo mate, 10.0 should be 0.30.0, right? |
Hey @sanket1729, I pushed a branch of the same name to my tree with additional changes to get green in CI (I think). Feel free to grab them and squash it down into this. No need for attribution. |
Thanks, will take a look shortly. Waiting for |
@sanket1729 bitcoind is blocked on rust-bitcoincore-rpc which is blocked on Steven's availability. Can't we figure out some other solution? |
@apoelstra, is this not already updated here? rust-bitcoin/rust-bitcoincore-rpc@6746011 |
Perhaps, you don't have publish priviledges? |
@sanket1729 correct, I do not have publish privileges. |
|
956d332
to
ca305c8
Compare
This is also ready for review @apoelstra |
Looks good. I think we need to revisit the |
There are also several clippy failures on this, but I am also willing to slip those to a followup PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor suggestions, I mainly mention them because I think people will look at miniscript to see how to best use rust-bitcoin
so we should use it in the best/easiest manner.
Thanks!
Cargo.toml
Outdated
hashbrown = { version = "0.11", optional = true } | ||
bitcoin-private = { version = "0.1.0", default-features = false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In rust-bitcoin
we found it more ergonomic to write use internals::write_err
. To do so set the dependency as such
internals = { package = "bitcoin-private", version = "0.1.0" }
bitcoind-tests/tests/test_cpp.rs
Outdated
@@ -10,11 +10,11 @@ use std::io::{self, BufRead}; | |||
use std::path::Path; | |||
|
|||
use bitcoin::hashes::{sha256d, Hash}; | |||
use bitcoin::psbt::PartiallySignedTransaction as Psbt; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use bitcoin::psbt::PartiallySignedTransaction as Psbt; | |
use bitcoin::psbt::Psbt; |
bitcoind-tests/tests/test_cpp.rs
Outdated
use bitcoind::bitcoincore_rpc::{json, Client, RpcApi}; | ||
use miniscript::bitcoin::absolute::LockTime; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps import absolute
and use absolute::LockTime
use miniscript::bitcoin::absolute::LockTime; | |
use miniscript::bitcoin::absolute; |
bitcoind-tests/tests/test_desc.rs
Outdated
@@ -8,19 +8,19 @@ use std::collections::BTreeMap; | |||
use std::{error, fmt}; | |||
|
|||
use actual_rand as rand; | |||
use bitcoin::absolute::LockTime; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment here.
bitcoind-tests/tests/test_desc.rs
Outdated
use bitcoin::util::sighash::SighashCache; | ||
use bitcoin::util::taproot::{LeafVersion, TapLeafHash}; | ||
use bitcoin::util::{psbt, sighash}; | ||
use bitcoin::psbt::PartiallySignedTransaction as Psbt; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment here.
} | ||
|
||
/// An absolute locktime that implements `Ord`. | ||
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to use
#[allow(clippy::derive_ord_xor_partial_ord)]
Perhaps with a comment (currently missing from rust-bitcoin
) that its ok to derive eq and implement ord because the enum variants hold the same u32 as returned by to_u32()
so the impls match as required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we added clippy in CI in rust-bitcoin? Perhaps, that gives a green light to add it here too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep sure have, its in contrib/test.sh
. Done for bitcoin
, hashes
, secp256k1
, internals
, and bech32
.
Note, you have to lint the examples explicitly (see rust-bitcon/bitcoin/contrib/test.sh
)
src/util.rs
Outdated
// FIXME: There has to be a better way than this. | ||
let push = PushBytesBuf::try_from(wit.clone()).expect("FIXME: Handle error"); | ||
b = b.push_slice(&push) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Kixunil can you take a look at this please. I cannot work out how to get something that implements AsRef<PushBytes>
from a &Vec<u8>
to pass to push_slice
? Only using a reference and checking that the vec is a valid length before passing it to push_slice
is exactly what PushBytes
is for right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Firstly, I don't understand why this function even exists - witnesses and scripts are different.
The only way is to return Option
or Result
from the function or document that it panics if a witness
with too large element is passed in.
Also to avoid allocation:
let push: &PushBytes = wit.try_into()?; // or expect
b = b.push_slice(&push);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an internal to how rust-miniscript works. We have a function that constructs a Vec<Vec<u8>>
type for all types of scripts. If the script is legacy p2sh or bare script pubkey, we need to convert this to ScriptBuf
converting each Vec<u8>
into a scriptPush.
The only way is to return Option or Result from the function or document that it panics if a witness with too large element is passed in.
This is one of the selling points of miniscript. Miniscripts are statically analyzed to make sure that all valid spend paths constructed at spend time are within bounds and spendable on bitcoin network. In other words, this function is only called on satisfactions generated from miniscript satisfier which guarantees the resource bounds enforced by bitcoin consensus rules.
It does context based checks that total witness length cannot be more than 3600 for segwitv0 and so on.
What KixUnil is saying is correct.
The allocation should be avoided. I don't remember how I did this :( . This was a month gap when I relooked at this PR. I only made sure the compiler did not complain and opened the PR for review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to pass in something like &[WitnessElement]
where WitnessElement
is a type that guarantees length at most 3600? You could then safely implement AsRef<PushBytes>
for it. Or if it's not that important for miniscript to carry the precise bound just use &[PushBytesBuf]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Firstly, I don't understand why this function even exists - witnesses and scripts are different.
Prior to segwit they are not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prior to segwit witness doesn't exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use &[PushBytesBuf]
, since all witnesses we push are either signatures, hash preimages, or constants like 1 or 0.
But for the final push, we have to push the script itself. Which is almost 3600 in segwit and implicit block size bound in transaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 60943aa
a700935
to
d5a564c
Compare
Re-reviewed the PR again. And force pushed removing all PushBytesBuf related allocations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK d5a564c
src/util.rs
Outdated
|
||
/// All pushes in miniscript script construction will never exceed 2**32 bytes. | ||
/// We only push slice of hashes outputs (32 bytes), and keys (33/65 bytes). | ||
fn push_ms_slice(self, data: &[u8]) -> Self; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this being called anywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. This is a remanent of previous design where I thought I could hide all unwraps\expects
for miniscript library. But later on decided to have explicit unwraps at call site to avoid future errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK d5a564c
Can re-ack after push_ms_slice
is removed but feel free to merge without me :)
I think we should remove |
On further thought let's just merge this and delete the funciton in a followup. |
Force pushed. I wonder why it did not show unused warning? |
The trait is pub(crate). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 1c0c78e
I think the analysis is harder for traits. Especially if it's used as |
No description provided.