Summary of Gordian Developer Meeting @ November 1, 2023

[shannona]

This month's meeting occurred on November 1, in an early timeslot to make it available to Europe.

Output Descriptors

The main topic of the day was output descriptors. They're the future of wallet interoperability
because of their ability to contain keys, scripts, and derivation paths. They're what you need to find your keys!

But, there are currently a number of different proposals for how to transmit and store them.

Blockchain Commons' Original Proposal for Descriptors

Blockcain Commons' original proposal for descriptors, which has been used by Sparrow and Seedhammer, was UR-based. It can be found in BCR-2020-10. It defined a binary format for descriptors and stored
them as URs. This depended on the use of mid-level CBOR tags that Blockchain Commons thought would be available if they presented a specification.

Unfortunately, the actual allocation of those mid-level tags proved to be more difficult that suggested, requiring the approval of CBOR experts, which was limited because they're only willing to allocate a few of those tags a year, to ensure they remain available over the lifetime of CBOR.

This suggested one of three ways forward:

1. Keep using BCR-2020-10 as is, but in doing so potentially bump heads with the IETF and/or IANA.
2. Change the tags within BCR-2020-10 to be high-level tags, which do not require the same approval. This would still be a breaking change.
3. Produce a new proposal which sidestepped the tag issue through the usage of Gordian Envelope.

Unfortunately deprecating the existing specifications may also cause people such as Sparrow, who are
currently using them, problems, particularly if users feel uncomfortable with their coin data being stored in a "deprecated" format.

A potential solution that the community suggested was UPDATING the existing specs rather than DEPRECATING them.

Take Away:

• Produce a v2 of BCR-2020-10 (and probably the linked BCR-2020-15) that uses Gordian Envelope or some other updated format. It would serve the same purpose of doing the necessary updates to the spec, but would do it in a way that feels more like an upgrade path, and that would leave end-users more comfortable.

BCRs and BCPs

The issues with changing a BCR that was in use by at least two community members led Blockchain Commons to update its specification path. All specifications have traditionally been labeled BCRs, but Blockchain Commons is now introducing a new category called BCPs.

When a BCR/Research format comes into use by at least two parties, it will be upgraded to BCP/Proposal status, with the goal of moving it onto a standards track. BCPs are intended to be less fluid than BCRs (with the understanding that standardization might require changes) and changes will be discussed with the community, especially those people who are implementing the spec.

Take Aways:

• BCPs should list upfront who is implementing them and how they're doing so.
• Blockchain Commons still needs to move current BCRs that are foundational and/or in strong usage to BCPs. Bytewords and the UR fundamentals are examples of BCRs that should probably be upgraded.

Blockchain Commons' New Envelope Proposal for Descriptors

Blockchain Commons' new suggested format for output descriptors is a simple usage of Envelope to encode the text representation of the descriptor, plus a label and potentially a name and note.

Envelope is designed to make simple things simple and hard things possible, so a minimal output of a descriptor has very little additional data: 12 bytes of overhead!

Take Aways:

• For Bitcoin wallet people, one of the most things is ultimately advancing BCRs/BCPs to BIPs, to get them traction in the Bitcoin community.
• There was some concern with regard to using CBOR in BIPs, but it was also pointed out that we can just list out the magic numbers that go at the front and end of an encoding (basically, the CBOR formatting). Yes, those numbers will be compatible with CBOR, but we don't need to fully describe CBOR. That's essentially what the PSBT BIP does too, albeit without the CBOR backend.

SeedHammer's Envelope Proposal for Descriptors

SeedHammer offered a presentation of their own proposal for an output descriptor format, which uses the format currently used for PSBTs.

Discussion of Output Descriptors

With all the possibilities in hand, there was a general discussion of the requirements of these various formats.

In particular, there's still a desire for binary encoding of text because of its compactness

• But we'd have to require that changes to output descriptors go through us to keep that from getting outdated.
• Perhaps we should shoot for the moon and try for this? There wasn't consensus.

Much of the discussion focused on how a CBOR format could be easy to read without actually requiring an understanding of CBOR. (Writing was considered not an issue, because any app can choose to write a very constrained version of a format.)

Wolf pointed toward his description of how to read a simple version of an Envelope output descriptor that contains only the label and the descriptor:

* The header bytes MUST be d8 c8 82 d8 18,
* If the length of the output descriptor string is:
   * < 24 bytes, the next byte is 60 + length
   * < 256 bytes, the next bytes are 78 NN where NN is a 1 byte length
   * < 65536 bytes, the next bytes are 79 HH LL where HH LL are a 2-byte length (big endian),
* The encoded length is followed by the output descriptor string with no terminator,
* The suffix bytes MUST be a1 01 19 01 fb.

--
Basically, it's very easy to write a reader that just looks for these magic numbers and follows a few rules. But what if it has more metadata added on? A reader can just iterate through the array of data, and skip other assertions! You don't have to support all of Envelope if you support some of it!

If Blockchain Commons BIPs an Envelope descriptor, it will probably be a minimal format. We just need to be able to create a BIP that allows for the creation of a simple decoder from scratch.

• So likely limit # of possible contents of array!
• Which BCR-2023-007 does already

There was some consensus that this might work, but SeedHammer noted that they'd like to see
a version of spec that also includes two other data elements:

• block #
• compact (binary) xpub instead of text xpub

Wolf suggested that we could even put forth a new specification that was dCBOR instead of Envelope. It would be built to work with Envelope, but wouldn't be Envelope itself, which would make it easier to specify as a BIP.

The community generally thought it worthwhile for Blockchain Commons to put together this new descriptor output format in CBOR and to code examples. They suggested it be prioritized.

Take Aways:

• Consider revising the Envelope output descriptor format into a slightly simpler dCBOR output descriptor format.
• Offer it as a BIP by eliding most CBOR functionality and replacing it with the "magic numbers" needed to make things work, while noting it is CBOR-compatible.
• Add block # to the metadata per [SeedHammer's proposal](Consider a compact PSBT based encoding for wallet descriptors Research#135 (DESC_BIRTHDATE: The wallet birthdate in blocks, encoded as a compact integer.)
• Consider replacing xpubs with xpubs in a better binary format, rather than base58.
• We should do this quickly.

Also see SeedHammer's summary.

Envelope CLI

A new Rust version of the Envelope CLI is available at bc-envelope-cli-rust.

Blockchain Commons had planned a demo for today, but after the long discussion of output descriptors decided to skip it. Basically, it works the same as the existing Swift version, but in Rust instead of Swift, with a few syntax changes.

(They may demo next meeting if there's a request for that.)

CSR Depository

Blockchain Commons also announced their work on CSR Depository, a share server for CSR. It's still in process, but they hope to have a full demo at the next meeting.

This is all in service to the goals of maintaining user independence and privacy. Users should be able to make the choice about how their secret shares are stored, which is not the case currently in Ledger Recover.

Recent Musings

A lot of Blockchain Commons' big-picture architectural thoughts can be found in Christopher Allen's Musings from a Trust Architect articles. They can be found at Blockchain Commons or in Christopher's recently updated blog Life with Alacrity.

Recent discussions covered self-sovereign computing, methodologies for minimizing data access, and an introduction to Schnorr.

Thanks to everyone for great feedback and discussion at a great meeting.

[henkvancann]

Thanks, the links in the text are very handy. Will there a recording link become available some time?
Extra links:
CSR
dCBOR
Envelope

[shannona]

Thanks, the links in the text are very handy. Will there a recording link become available some time? Extra links: CSR dCBOR Envelope

Took a while to run a transcript and upload the video, but the video is now here:
https://www.youtube.com/watch?v=gid528Ivxww

(Still in SD, will be in HD within a couple of hours.)