Summary of Gordian Developer Meeting @ December 6th

[shannona]

December's Gordian meeting focused on discussions of a new output descriptor format and implementation of URs, and also featured a full demo of the Gordian Depo server.

• DEVELOPER MEETING VIDEO: https://www.youtube.com/watch?v=Z8zHew8fhT0&t=2s
• GORDIAN DEPO DEMO: https://www.youtube.com/watch?v=7uW6xlT4hTk

Some major comments:

• The v3 Output Descriptor format seemed to have rough consensus.
• The fountain codes in the UR specification need to have a proper specification themselves rather than depending on code.

Here's a summary of all the major discussions & demos.

Repo Overview

Blockchain Common's repos are primarily written in three languages: Swift, C/C++, Rust. Swift have dependencies on C/C++, but Rust is standalone.

C depends on a number of Blockchain Commons libraries in C/C++ for Lifehash, SSKR, URs, etc. Keytool, Seedtool, and Bytewords CLIs also built on these libraries.

Swift uses a number of a Swift libraries, including things like NFC libraries and URUI, plus has shims for some of Blockchcain Commons' C libraries. The output includes our Gordian Seed Tool app, plus some demos.

Rust stack is a set of crates that is all standalone/pure Rust. SSKR, Shamir, UR, dCBOR, Envelope, etc. A few command line tools have been written in Rust for dCBOR and Envelope. (Rust will grab anything you need, and also has feature gates, so that you can comment things out and it won't get compiled in.)

Some of the C/C++ libraries have been deeply reviewed (Shamir + SSKR), but not most, and not our Rust libraries (though they ought to be the same). We expect them to become more stable over time.

Blockchain Commons has heard comments about "too many dependencies", and believes that's a mischaracterization. The system has been carefully layered so that it can be used piecemeal and in particular if technology advances a particular section can be replaced. For example, it would be trivial to switch over to a color QR standard. Nonetheless, Blockchain Commons is working carefully to ensure there are not many security dependencies, to keep it easy to review.

Compare this to hodge-podge that resulted in Bitcoin from mixing policy with the actual address, which caused xpubs, ypubs, zpubs, etc. to emerge.

Output Descriptors

Had a previous version that ran into challenges. See discussions for some of these challenges and other suggestions.

So Blockchain Commons has a new PROPOSAL, UR definition for Output Descriptors Version 3. It's only a proposal until people start using it. BCR-2023-010.

A native CBOR encoding for an output-descriptor.

• CBOR tag # 6.40308

The proposal focused on:

• pure CBOR
• compact encoding of keys
• represent all output descriptors
• adaptable for future
• support metadata such as name and note

Also demonstrates new v2 tags needed generally for URs:

• Plan to register them
• These new "version 2" tags are in first come, first serve range at IANA.
• Recorded in BCR-2020-006, everything is old tag + 40000

Goal is compact, but expressive and future-proofed and fitting into a larger context.

Result is dCBOR encoding of text format with keys replaced with indexed placeholders (with indexing being optional for writing).

• Uses v2 UR definitions of URs for hdkey, eckey, and address.

Metadata is important because keys are growing more complex with multisigs, FROST, adapter sigs. Flexibility is needed to future-proof this!

• Community should share what other things they'd like to see, but which aren't part of our Bitcoin output descriptor description.

The result compacts down as shown in example if key is separated for compacting.

• Can also be converted into a UR for efficient QR encoding.

Why did we chose CBOR?

• Many reasons, including the fact that there's a whole ecosystem about it.
• And has a basis in the standards community.
• Tight, compact embedders & decoders, and because dCBOR is deterministic, can write really simple stub decoders & encoders.

Though PSBT is deeply embedded in Bitcoin community, we don't support it as a generic format for other usage.

Ultimately, however, Blockchain Commons will adapt to whatever the community wants.

We do believe in advancing the new crypto-output v3 to BIP, but we want to see people using it.

URs

CoinKite recently introduced BBQr. Why? Are there improvements that should be made to UR?

• They say it's because of dependencies
• We invited them to talk, but they didn't attend
• One of the problems might be that they have withdrawn from open source

Do we need to do more?

• Unified BIP-style docs?
• Something else?

Ultimately, our goal is to serve the Wallet community, and thus the user.

We want community to be the 600-lb gorilla, not a single company!

The fountain codes are a big value of URs, because they allow you to jump in the middle or miss fragments and it's still very efficient.

Currently, BCR description of URs links to implementation code that demonstrates how fountain codes work, and that's how other developers have implemented. Blockchain Commons should have a full IETF description of URs + fountain codes, but that's a time issue.

Community thinks that single document would be helpful, and not having to go to code, would be useful.

• There's belief that UR could also be written out in isolated specifications (such as just encoding fragments) without referencing CBOR.

GOAL: write a standalone spec without code (and possibly without CBOR) only about UR/fountain codes. Can the community help support this? We estimate this would be a couple of weeks / half-a-month.

Gordian Depository Demo

Depository is a server for storing and retrieving binary objects. Use case is shares of digital objects.

Uses MariaDB (MySQL) for backend

Protocol is set up to be as anonymous and generic as possible.

TOFU. No account creation. (Happens automatically when a client stores a BLOB.) Everyone is identified by public key, signed by private key.

Get back a receipt, but if you don't have it you can retrieve everything with your public + private key.

Account maintenance allows rotating of public key. Also allows the creation of a 2FA method (fallback method) for updating a new public key.

Two crates, one for depo server, one for an API talking to depo server.

Sealed format talking to server is signed + encrypted with server's public key, making sure that very little information can get out. Sent as Gordian Envelopes.

DEMO showed that it's actually functional!

Gordian Sealed Transport Protocol (GSTP)

• Every message is an Envelope with a single sealed message
• Spec will follow after community feedback
• But can run now, and test code

We want to see Depo servers run!
We want to see depo-compatible wallets!

Blockchain Commons is focused on USER-CHOICE

• Some users will be totally self-sovereign, printing out things, using Seedhammer, storing on different devices, etc.
• But can also use something like Gordian Seed Tool, using QR codes to store shares for friends
• But then can do things with partners, using hosted servers. This is what the depo server enables.
• Maybe privacy-protected Onion/TOR servers in future

We don't think wallet makers making that user choice is what we want in a self-sovereign world.

Also want to make sure things are future-proofed, for example to use VSS instead of classic Shamir's Secret Sharing.

Demoed three things: server, general (GSTP) protocol, specific (Depo) protocol. They're each useful!

Next Meeting

May push back to January 10th because otherwise it'll be very close to the New Year.