Skip to content
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

Merged
merged 1 commit into from
May 4, 2023

Conversation

sanket1729
Copy link
Member

No description provided.

@tcharding
Copy link
Member

tcharding commented Mar 27, 2023

PR title has typo mate, 10.0 should be 0.30.0, right?

@sanket1729 sanket1729 changed the title update to bitcoin 10.0 update to bitcoin 0.30.0 Mar 28, 2023
@tcharding
Copy link
Member

tcharding commented Mar 28, 2023

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.

@sanket1729
Copy link
Member Author

Thanks, will take a look shortly. Waiting for bitcoind release before making any progress here.

@apoelstra
Copy link
Member

@sanket1729 bitcoind is blocked on rust-bitcoincore-rpc which is blocked on Steven's availability. Can't we figure out some other solution?

@sanket1729
Copy link
Member Author

@apoelstra, is this not already updated here? rust-bitcoin/rust-bitcoincore-rpc@6746011

@sanket1729
Copy link
Member Author

Perhaps, you don't have publish priviledges?

@apoelstra
Copy link
Member

@sanket1729 correct, I do not have publish privileges.

@romanz
Copy link

romanz commented Apr 21, 2023

Thanks, will take a look shortly. Waiting for bitcoind release before making any progress here.

bitcoind 0.30 is now released :)

@sanket1729 sanket1729 force-pushed the release_10.0.0 branch 2 times, most recently from 956d332 to ca305c8 Compare May 2, 2023 19:47
@sanket1729 sanket1729 marked this pull request as ready for review May 2, 2023 19:48
@sanket1729
Copy link
Member Author

This is also ready for review @apoelstra

@apoelstra
Copy link
Member

Looks good. I think we need to revisit the assume_unchecked address crap in bitcoin. I'd also like to iterate a bit on the src/util.rs stuff (which has a FIXME and some allocations that shouldn't be necessary) but we can do that in a followup since this PR is so massive and these things are a small part of it.

@apoelstra
Copy link
Member

There are also several clippy failures on this, but I am also willing to slip those to a followup PR.

Copy link
Member

@tcharding tcharding left a 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 }
Copy link
Member

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" }

@@ -10,11 +10,11 @@ use std::io::{self, BufRead};
use std::path::Path;

use bitcoin::hashes::{sha256d, Hash};
use bitcoin::psbt::PartiallySignedTransaction as Psbt;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
use bitcoin::psbt::PartiallySignedTransaction as Psbt;
use bitcoin::psbt::Psbt;

use bitcoind::bitcoincore_rpc::{json, Client, RpcApi};
use miniscript::bitcoin::absolute::LockTime;
Copy link
Member

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

Suggested change
use miniscript::bitcoin::absolute::LockTime;
use miniscript::bitcoin::absolute;

@@ -8,19 +8,19 @@ use std::collections::BTreeMap;
use std::{error, fmt};

use actual_rand as rand;
use bitcoin::absolute::LockTime;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here.

use bitcoin::util::sighash::SighashCache;
use bitcoin::util::taproot::{LeafVersion, TapLeafHash};
use bitcoin::util::{psbt, sighash};
use bitcoin::psbt::PartiallySignedTransaction as Psbt;
Copy link
Member

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)]
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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
Comment on lines 27 to 29
// 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)
Copy link
Member

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?

Copy link

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);

Copy link
Member Author

@sanket1729 sanket1729 May 3, 2023

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.

Copy link

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].

Copy link
Member

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.

Copy link

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.

Copy link
Member Author

@sanket1729 sanket1729 May 3, 2023

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.

apoelstra
apoelstra previously approved these changes May 2, 2023
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 60943aa

@sanket1729 sanket1729 force-pushed the release_10.0.0 branch 2 times, most recently from a700935 to d5a564c Compare May 3, 2023 17:57
@sanket1729
Copy link
Member Author

Re-reviewed the PR again. And force pushed removing all PushBytesBuf related allocations.

apoelstra
apoelstra previously approved these changes May 3, 2023
Copy link
Member

@apoelstra apoelstra left a 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;
Copy link

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.

Copy link
Member Author

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.

tcharding
tcharding previously approved these changes May 3, 2023
Copy link
Member

@tcharding tcharding left a 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 :)

@apoelstra
Copy link
Member

I think we should remove push_ms_slice. I'm also happy to re-ack quickly.

@apoelstra
Copy link
Member

On further thought let's just merge this and delete the funciton in a followup.

@sanket1729 sanket1729 dismissed stale reviews from tcharding and apoelstra via 1c0c78e May 4, 2023 14:42
@sanket1729
Copy link
Member Author

Force pushed. I wonder why it did not show unused warning?

@sanket1729
Copy link
Member Author

The trait is pub(crate).

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 1c0c78e

@sanket1729 sanket1729 merged commit 7c28bd3 into rust-bitcoin:master May 4, 2023
@Kixunil
Copy link

Kixunil commented May 4, 2023

I wonder why it did not show unused warning?

I think the analysis is harder for traits. Especially if it's used as dyn anywhere.

gruve-p pushed a commit to Groestlcoin/rust-miniscript that referenced this pull request Aug 28, 2023
1c0c78e update to bitcoin 0.30.0 (Tobin C. Harding)

Pull request description:

ACKs for top commit:
  apoelstra:
    ACK 1c0c78e

Tree-SHA512: 4ab6d41200a030526107cc9a5c1c7451483b1e0d9bcc813cb19f8336a5289ba6197dfc049dc0c3426afd3ddbf85dc055469213c329a3fc71a30238cab909fe96
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.

5 participants