`v0` is dead long live `v0`

[tcharding]

The v0 module was created so that downstream users of rust-bitcoin and rust-miniscript could have the same API by using this crate. Furthermore I imported the files frorm bitcoin and miniscript with minimal changes so devs could diff them and see what was different. This was all released as v0.2.

Over here we have reached consensus to rip out PSBT stuff from bitcoin and miniscript and have it all live in this crate. The open quesiton is do we track bitcoin v0.32 or bitcoin 0.33.0-beta?

My proposal is to track the beta releases (this will include miniscript beta releases). The reason is that if users want bitcoin v0.32 (and the original PSBT code) they can depend on that version (and the stable current latest miniscript version). Even if downstream at some stage wants to use beta releases (and later stable once beta becomes stable) they can still have two bitcoin deps if desired.

Furthermore I think we should:

• Delete the v0 module (and remove the v2 module abstraction).
• Document that v0.2 has bitcoin v0.32 and v0.3 onwards depends on later version of bitcoin.
• Depend on bitcoin v0.33 soon as we can (needs corpec and miniscript upgrade PRs to be done still).
• Go absolutely wild on the API with no thought of backwards API compatibility.
• Provide a serialize_as_v0 function alongsid serialize() that does v2 (example names only).

[tcharding]

This begs the question: will there be a user of psbt v0.2.0 (using PSTBT v2) that does not want to use bitcoin v0.33? We could do the whole beta / stable release dance described here but I don't think its worth the effort for this crate.

Related: rust-bitcoin/rust-bitcoin#5672

[nyonson]

Nice, this sounds good to me.

This begs the question: will there be a user of psbt v0.2.0 (using PSTBT v2) that does not want to use bitcoin v0.33?

Maybe similar to this thought, I was wondering if it would be worth maintaining a v0.2.x branch as the bitcoin v0.32.* psbt crate. We don't have to make a call on that now though, could just pick a hash in the future to branch off from.

Given the state of this crate, I'd vote to just march forward with v0.*.0 releases when we bump the miniscript dep (which I think will dictate the bitcoin version). And while we wait for the miniscriptforbitcoin v0.33.*, I don't think we are blocked from pulling in the underlying consensus_encoding` (stuff @nymius is already hacking on a bit).

[tcharding]

Maybe similar to this thought, I was wondering if it would be worth maintaining a v0.2.x branch as the bitcoin v0.32.*

That is what I meant by the beta / stable release dance. Its described here: rust-bitcoin/rust-bitcoin#5648 (TL;DR jump to Andrew's post at the bottom).

I guess all releases of psbt should have -beta in the name? At first I don't think we should bother working on stable releases (bitcoin 0.32). If it turns out its needed we can always fork of 0.2. Or do a minor release as 0.2.1. How about we punt on that decision until the need turns up?

I'd vote to just march forward with v0.*.0 releases when we bump the miniscript dep

I'm working on at least getting draft PRs up so we can start hacking on this. Have corepc todo then rebase/redo rust-bitcoin/rust-miniscript#874

[nymius]

About releases and general changes

• Delete the v0 module (and remove the v2 module abstraction).

So do you prefer to begin with a flattened structure?

• Document that v0.2 has bitcoin v0.32 and v0.3 onwards depends on later version of bitcoin.

I think here you're referring to the tagged releases: yes, I agree with this. I think the beta/stable release dance will only make sense once we have something to release, and I will stick to it in that case. And answering your later commented questions:

I guess all releases of psbt should have -beta in the name?

Agree, I will stick to the beta/stable release dance.

How about we punt on that decision until the need turns up?

Agree, I would fork and do a minor release only if we have to.

• Depend on bitcoin v0.33 soon as we can (needs corpec and miniscript upgrade PRs to be done still).

Absolutely, free QA.

• Go absolutely wild on the API with no thought of backwards API compatibility.
  Agree, although I've some bias in favor of the current API and arch, because is the one that has been working so far.

• Provide a serialize_as_v0 function alongside serialize() that does v2 (example names only).

Is this related to #33?

---

About encoding

I don't think we are blocked from pulling in the underlying consensus_encoding (stuff @nymius is already hacking on a bit).

I don't think this either, but if we go wild with the API, some things may change greatly from the code I'm building on. I think we don't have to worry, just have in mind to not be "wild" for free.

From rust-bitcoin/rust-bitcoin#5611 I understood the main problem behind the use Encodable/Decodable in PSBT is one is consensus, the other is not, and in practice, both use consensus. But as there is no "contract" for the second, is better to keep them separated.
At the end, I would implement PsbtEncodable/PsbtDecodable following Encodable/Decodable and the Consensus Encoding ADR, so will still be the same: one is consensus, the other is not, and in practice, both use consensus.

---

About protocols like MuSig and Silent Payments

I think while going "wild" with the API, we still should consider what to do with later PSBT role modifications, like special logic for MuSig or BIP 352. I think the idea of not implementing the logic in this crate has been mentioned before, and I think it's reasonable, but are we going to provide an extendable API? Has that been implemented before? Any ideas of how to do it?

[tcharding]

So do you prefer to begin with a flattened structure?

Yep, that is what I meant.

• Provide a serialize_as_v0 function alongside serialize() that does v2 (example names only).

Is this related to #33?

No. There will be no v0::Psbt and v2::Psbt. What I meant was just a single Psbt type that has both these methods.