Depend on bitcoin v0.32.0-rc

[tcharding]

Test the latest bitcoin release candidate. Includes bumping the version numbers so we can use this branch to test crates further up the stack.

Requires the rc-fixes branch.

[tcharding]

Have you got more changes to miniscript queued up @apoelstra, as we get closer to releasing rust-bitcoin there is not enough to fill my day. I'm hesitant to go down the stack so as not to clog up reviewers - I could throw some time into miniscript? Don't hold you breath that its productive though :)

[apoelstra]

Have you got more changes to miniscript queued up @apoelstra

Yes :P my development branch currently has a 3000-line patch.

But don't worry about me, I don't mind rebasing on changes for a new rust-bitcoin.

[tcharding]

The new CompressedPublicKey type makes this upgrade hard, I think this may be a case of us introducing something new that causes a bunch of upgrade pain - perhaps we should solve it fully here before doing the rust-bitcoin release to iron out some of the issues, or at least so we have a concrete suggestion for how to do the upgrade.

[tcharding]

I.e. the CompressedPublicKey is objectively better and exposes an abstraction problem, but its a PITA if your software has been ignoring that abstraction problem until now ... f**king rust-bitcoin devs.

[apoelstra]

I think changing the pubkey type is going to be a mess in rust-miniscript no matter what. This crate uses public keys way heavier than pretty much anything else.

One way you can make the update simpler though is to add a bitcoin 0.32 dep under a different name, start switching public key types over (possibly across multiple commits), and then doing the rest of the updates and cutting over to bitcoin 0.32 in a final, smaller commit.

[tcharding]

Cool, I'll do the bdk upgrade then before getting too much more worried about CompressedPublicKey.

[apoelstra]

I might give it a shot as well.

[tcharding]

Madness, I got the bdk upgrade done with trivial changes to their whole stack of crates and about 500 lines each of red and green for the bdk repository. Of note:

• The CompressedPublicKey didn't even come up.
• The sighash error split was the hardest part because we added a bunch of new error types in there its hard to know quickly which one to use
• the key::Error change is hard for same reason
• txid() to compute_txid() is possible with sed and a few manual fixes
• The sig to signature and hash_ty to sighash_type change is mechanical but kind of annoying

Reflecting, the hardest part was bumping the version number of every crate in the stack, and remembering what order to do them in, once that was done I did the actual bdk patch in about 20 minutes. It was quicker because I did miniscript yesterday though.

cc @notmandatory in case you are interested Steve. We are gearing up to do another rust-bitcoin release but since its taken six months to get [almost] upgraded to the last version I doubt you guys have the stomach to start all over straight away :)

I'll push up branches once we drop the first RC version.

[notmandatory]

Thanks for the headsup @tcharding, as you mentioned getting all ecosystem crates updated is a big job so it's unlikely we'll be updating to rust-bitcoin 0.32 for our 1.0.0 milestone unless we absolutely have to.

Glad to hear the 0.31 update wasn't too much work, I'll see if I can help with the CI issue on bitcoindevkit/bdk#1177, it's on the top of my priority list.

[tcharding]

Fair. In 0.33 we will hopefully deliver a primitives crate, that will be a much more interesting upgrade.

[apoelstra]

Needs rebase now after #676.

[tcharding]

Note I've removed the TODOs and used the original expect calls - don't know how I missed those yesterday.

[apoelstra]

@tcharding wanna bump this and undraft it?

I went over the diff. utACK 1846584 once it's updated to the final version of 0.32.

[apoelstra]

Though reading this did make me notice rust-bitcoin/rust-bitcoin#2728

[tcharding]

We need rust-bitcoin/rust-bitcoincore-rpc#337 before we can do this one.

[apoelstra]

Ugh. Let's just fork it for now.

[tcharding]

ha, I woke up thinking the same thing.

EDIT: Hold the phone, I'm a crate owner now. I can publish a new version. Can you review these two PRs please and I'll merge them and do a release PR.

• Re-write CI rust-bitcoincore-rpc#338
• Depend on bitcoin v0.32.0 rust-bitcoincore-rpc#337

EDIT again hours later: I'm going to fork. Please see the new fork at https://github.com/tcharding/rust-bitcoincore-rpc

I have emailed @RCasatta to ask for perms to publish to crates.io under the same name he did last time we did this (core-rpc and core-rpc-json).

I've talked to @stevenroose on Signal but he is keen to push forward with async so I don't see a way to keep using bitcoincore-rpc here.

[apoelstra]

EDIT again hours later: I'm going to fork. Please see the new fork at https://github.com/tcharding/rust-bitcoincore-rpc

Sounds good. What then is your intention for all the PRs you've opened? I will test/merge the ones that are undrafted and seem simple/uncontroversial at least.

[tcharding]

I got myself in a state yesterday, swung wildly from super excited to have something useful to work on (bitcoincore-rpc) to rather depressed at the prospect of arguing with Steven over the direction of the crate. Points in note:

• I have publish perms to crates.io but that doesn't alleviate me from the social problem of pushing the crate in a different direction to what Steven wants
• @RCasatta has write perms to the repo
• Steven wants to get async into bitcoincore-rpc, but Andrew does not want async in jsonrpc (I believe) and I don't care about async, and the work to get it in is non-trivial, also no one else appears to want to review it.

Riccardo has given me publish perms on core-rpc so if all fails I'll publish my fork. But for the next week or so I'll try to work on the github.com/rust-bitcoin/bitcoincore-rpc and see if we can all get on. If you are ok to review/merge Andrew then I think we can push forward, for some reason I had it in my head yesterday that you didn't like reviewing that crate. I guess I got mixed up with bip39.

[apoelstra]

I wouldn't mind async in jsonrpc if it were possible to isolate and feature-gate it. But if the result is to essentially create a whole nother crate that is embedded by feature-gate inside rust-jsonrpc, then we ought to just make a whole nother crate.

[dpc]

👍 for another crate, inside same repo . IIRC the most gnarly part is the json rpc schema types which are already in a separate crate and can be shared. Rest are largely the methods doing the actual calls, which will need to be duplicated anyway.

[storopoli]

We can support both blocking/async variants.
It is a little tricky¹, but I think that something like synca (which only depends on syn, quote and proc-macro2) might be interesting.

Footnotes

1. https://nullderef.com/blog/rust-async-sync/ ↩

[apoelstra]

syn and quote have broken our codebase over and over. I do not want to add them anywhere that they aren't already (and the one place they still are pulled in from, serde-derive, I want to drop).

[tcharding]

Was only for testing.