Summary of the Gordian Developer Meeting 2023-06-07

[shannona]

Gordian Developer Meeting: June 7th, 2023

Introduction

We are Gordian Developers, sponsored by Blockchain Commons

Goals for this year:

• dCBOR
• Gordian Envelope
• Collaborative Seed Recovery
• Collaborative Key Management Beginning

Last Meeting

Held on conjunction with Silicon Salon 4.

Shamir Updates

More companies are talking about sharding, more multisigs, more threshold quorums.

Recent Ledger controversy was based on the fact that they issued a Ledger Recovery firmware update which allowed sharding of keys, even though they had said previously that there was no way to remove keys from the Ledger. This misunderstanding is a common one: current silicon has to take seeds and keys out of their secure vaults for usage.

They also chose two other companies to store shards rather than giving users the opportunity to make their own decisions.

They've since withdrawn proposal as a result of controversy.

We see it as a cautionary tale of communication: simplifying things can create misunderstanding.

We also believe users should be able to choose how to do their seed storage & sharding.

Generally, the controversy reveals a whole swath of problems that all point to security issues with even a secure piece of hardware. It's hard. It's complex. We're all looking at different parts of the elephant.

We hope in a few years thanks to Silicon Salon that we'll have more secure chips and ones they can talk to each other, so that we can use new threshold crypto, such as CKM. But that's a few years out, so we need to be pragmatic about helping to protect peoples' assets now.

from SSKR to CSR

We have SSKR now, and it's great for seed & high-entropy data. But it's not great for other data, and there's no metadata capability.

But we need to protect other things, like descriptors for Bitcoin, pre-signed transactions for Lightning, and identifiable data from wallet — all stuff that people will want to restore.

For that we need CSR, which leverages SSKR to also protect metadata.

AirGap Wallet is working on implementing SSKR, because people are looking more standardization after the Ledger issues.

We definitely want to focus on interoperability as a major element.

Our CSR overview: https://github.com/BlockchainCommons/Gordian/tree/master/CSR#collaborative-seed-recovery-csr-overview

SeedHammer

Overview

Seedhammer is a back-up-to-steel company, but they're a seed PRINTER.

There are lots of physical methods already, but Seed Hammer sells a MACHINE that creates the seeds, and so it can so much more: not just seed words, but also seed phrases, and QR codes(!). C

It can also backup all info needed to restore a wallet, even a multisig wallet.

It uses UR codes containing the complete output descriptor, using fountain code for Animated QRs. Half of descriptor goes onto each of two plates! Can do 2 of 3 or 3 of 5 via an XOR scheme. So this MULTISIGNATURE COMPLETE BACKUP is a unique element for SeedHammer (even beyond the fact that it's a printer).

Data it stores should be recoverable in the future because it uses UR and fountain code specifications created by Blockchain Commons.

Compares this to Ledger controversy: SeedHammer is allowing you to decide where you to put seeds, and it leverage offline storage. We'd love to see Ledger and others adopting independent methodologies of this sort!

This really shows us a lot of opportunities for compact storage of output descriptors.

• SeedHammer
• SeedHammer Video

Fountain Code Standard

There were discussions about the fountain code specifications used in Blockchain Commons' animate QRs.

Some discussion of other wallets that have Animated QRs without fountain codes.

• This was based on a pre-release version

There are also questions about floating point usage in animated QR fountain codes.

• We feel it's standardized now, bit for bit
• Even rounding errors are universal
• IEEE 754
• And so remains deterministic

Would love to talk more if there's a real issue with it not being deterministic.

There are some issues with arithmetic fusion, which can lead to different results.

We consider this a compiler bug, but we may need to figure out a way to tell compilers not to use these additional functions.

But there's a wider question of trying to maintain simplicity in standards/specifications.

• We hope we're doing better than the standards organizations!
• Our role is different because we're coordinating things, so we need multiple parties to say they need a function (or a revision, such as UR 3.0 that could drop floating functionality).

Rust

Porting the Gordian ecosystem over to Rust

• Swift had been our original deployment environment
• But we're expanded to Rust

dcbor, UR, Shamir, SSKR, and Envelope all being converted!

• looking at no-standard version too

It's a hierarchy of libraries

This is not reviewed code yet.

We're still prior to "community review" stage

• But we're looking for people to bring this to other environments and trying it out.
• And we're looking for people who can suggest idiomatic changes

This is the pre-community-review stage

We're hoping community review by end of month, which will be a formal release

But will still not be ready for production at that point.

At least September before we have that 1.0, depending on support for a security review.

Future

We'd love to see someone produce a GST-equivalent for Android

And we're returning to Swift to work on CSR stack. We'd love to get this going outside of just our reference apps!