Should we have CompressedPublicKey type?

[Kixunil]

PublicKey tracks whether it's compressed dynamically which leads to error checking when creating wpubkey_hash.
Having a separate type for it would push the responsibility to the caller which might be able to statically guarantee compressed key.
However it's quite a bit of added API surface just to remove a few error paths. Is it worth it?

[Kixunil]

Note that we could easily support both in relevant functions:

#[non_exhaustive]
struct UncompressedPublicKey;

impl TryFrom<PublicKey> for CompressedPublicKey { 
    type error = UncompressedPublicKey;
    ...
}

pub fn p2wpkh<Pk: TryInto<CompressedPublicKey>>(pk: Pk, network: Network) -> Result<Address, Pk::Error> {
...
}

[apoelstra]

It would remove more than a few error paths in rust-miniscript.

I'm in favor of this in principle. I think we've tried it in the past and it was hard to make workable. Maybe with 1.41.0 and TryFrom/TryInto it'll be more ergonomic.

[dr-orlovsky]

We have a lot of previous discussions on the topic. Just for the reference few of them:

• Taproot keys implementation strategy #588 (comment) (where there was already a proposal for "do a newtype ec::CompressedPubkey over secp256k1::PublicKey for SegWit v0 contexts (like in miniscript)"
• Solve PublicKey ambiguity #382

[Kixunil]

@dr-orlovsky thanks for references! After reading them I think people are worried about type blow up. I think a good compromise would be having CompressedPublicKey and PublicKey, no UncompressedPublicKey. AFAIK uncomressed keys are only used in contexts where both are usable but there are places where only compressed is accepted.

[tcharding]

What is the intended meaning of the 'help wanted' label @Kixunil? (In general I mean, not just for this issue.)

[Kixunil]

AFAIK it's asking for outside help (in this case feedback on API).

However maybe we should have a special label for requesting API feedback. Maybe even some event source for API consumers to subscribe to.

[tcharding]

However maybe we should have a special label for requesting API feedback. Maybe even some event source for API consumers to subscribe to.

Sounds like another useful thing to do on a mailing list, any project maintainer of a crate that depends on rust-bitcoin stack can then subscribe and share feedback/ideas.

[dr-orlovsky]

@tcharding can't this be done with GitHub discussions? Just worried about multiplying communication channels

[tcharding]

AFAICT GitHub discussions is per repository, I think a communication channel that is for all Bitcoin projects that are written in Rust (specifically all the ones that depend on crates in this organisation) would be useful. I'm pushing for a rust-bitcoin-dev mailing list.

[Kixunil]

I don't see a big problem with (ab)using the bitcoin crate for all of them.

[tcharding]

Fair point, and I suppose I can get notifications from github discussions via email.

[dr-orlovsky]

BTW it seems I have seen discussions at the org level

[tcharding]

I don't see it, I looked at an organisation of which I'm the 'owner' (or creator or whatever) and I couldn't see it either? Are you sure of this?

[dr-orlovsky]

[tcharding]

Yeah I saw teams but thought that wasn't suitable to us because its by definition exclusive, we want to include random contributors. Feels like teams is aimed at private, corporate, dev teams.

[dr-orlovsky]

@tcharding actually discussions on the org level are already in beta: community/community#13192

This is not the same as a team discussions. I think it could be a nice replacement for a mail list.

[Kixunil]

We should also have CompressedPrivateKey (naming is not great since it's actually public key compresed but can't think of better) that should be produced by BIP32 APIs.

[tcharding]

Done in #2277