---
robots: noindex, nofollow
---

# Grants

---------------

## Monero CCS

https://ccs.getmonero.org/

## Norm Hardy (July 31)

https://foresight.org/norm-hardy-prize/

---

## Other New Stuff

https://github.blog/news-insights/company-news/announcing-github-secure-open-source-fund/

https://openssf.org/blog/2024/03/19/how-openssf-technical-initiatives-can-receive-strategic-funding/

There is also this list, which if you search for "secur" or "privacy" has quite a few: https://github.com/ralphtheninja/open-funding

Also, Protocol Labs has started funding non-filecoin projects again.

https://docs.opentech.fund/otf-application-guidebook/appendix-iv-alternative-sources-of-support#privacy-and-security

---

## GitHub

For: https://docs.google.com/forms/d/e/1FAIpQLScDBalom0XhmJrvyI3kwD7dZ-dD4_uhmLNysVXtA8fH_WUKoA/viewform

> Application Type

General Application []

> If Referred Application ...

N/A

> Email Address

[e-mail]

> First name

Christopher

> Last name

Allen

> City

Lafayette

> State or Province

California

> Country

United States of America

> What is your GitHub Handle? (e.g. @mona)

@ChristopherA

> What is your project? Please include the functionality the project provides and the type of project (application or library).

Open Integrity is a project meant to improve the security of GitHub itself. It does so by using scripts, aliases, and settings to create cryptographically strong commits that reveal the initial creator of a repo and that enable transition commits to then extend or modify that "inception" authority. Use of strong messaging furthers the security by easily and accessibly identifying trust issues for users. The ultimate goal is ensure that a Git repo can be trusted and will remain trusted over the lifetime of a project.

> What is the repository URL?

https://github.com/openintegrityproject

> What is the license for this project?

BSD-2-Clause Plus Patent License

> How large is the core team? [you could reasonably list this as 1, 2, or 3, your call, the grant calls fo 3 or less]

2 members

> What is your role in the project?

Architect & Engineer

> Are there other maintainers or contributors to this project who want to join the GitHub Secure Open Source Fund and Program with you? What are their GitHub handles? [this is listed as no because I don't think you want to pay for me to attend the classes that come as part of this grant]

No

> Are you, or others, working in open source full-time on this project?

Yes

> Does your project have a Security Lead or Committee?

Yes []

> Have your or the core team participated in any security training? If so, please describe.

I've attended dozens of sessions, workshops, and other events on cryptography, and cryptographic security protections are the heart of the project.

My technical writing lead has attended some of those same sessions and has also received training as a Security Systems Administrator.

Our training is sufficient that we authored #SmartCustody, a book focused on maintaining the security of digital assets, while my technical writing lead has also written security manuals for financial companies.

> What is the level security understanding for the applying team?

High []

> What would be the external impact if this project had a security issue? Please describe.

The entire focus on Open Integrity is improving the security and trust in GitHub repos.

If there were a flaw in the fundamental cryptographic protocols or their usage, that would be catastrophic, because it would eliminate users' ability to trust the chain of trust revealed by the Open Integrity tools.

A security issue with the Open Integrity repo itself might be less problematic, if it was correctable and didn't affect the scripts that people were using.

But fundamentally, security is the heart of Open Integrity, so a security issue would have a high impact.

> Has your project had any reported security issues (CVEs, other security vulnerabilities)? Please share.

I'm aware of deficiencies in Git's SHA-1 algorithm, which has seen successful collision attacks. Much of my initial work was spent minimizing an "inception commit" to make the possibility of collisions extremely remote.

Other than that, I'm not aware of security issues.

> What in your opinion would be the positive impact of security improvements of your project on the broader ecosystem?

The goal of Open Integrity is to improve the trust in GitHub repos by more clearly designating who the authorities for a repo are and by allowing for transitions of authority. The security of the software and cryptography used is therefore fundamental to the project.

When people use Open Integrity, they will be able to better and more meaningfully trust software repos, which is a critical security need, especially as repos are increasingly used for the deployment of fundamental software infrastructure. That trust will only be engendered if the security is there as well.

So: security in Open Integrity will increase the level of trust for repos that use it.

> Do you have an existing sponsorship or funding strategy?

The Open Integrity Project is unfunded. I have begun seeking grants to pay for its continued development.

(More broadly, Blockchain Commons has received funding, but none of that is from patrons who are focused on the Open Integrity Project; it's been a more speculative & personal experiment.)

> How will the funding help you and your project achieve better security outcomes?

What exists is a first draft of Open Integrity. A roadmap (https://github.com/OpenIntegrityProject/core/blob/main/ROADMAP.md) lays out intended future development. Many of the open issues for development are security related, starting with simple questions such as how to better secure inception commits. They continue on to extended security models, such as the use of other signing key types, the creation of key custody and mangement tools, and of course security-related documentation. These next steps will be enabled by additional funding.

> How much funding have you received to date?

None ($0) []

> Do you self-identify as an underrepresented person in tech? Please share.

No.

> Were you referred by an organization or individual? If so, can you provide their name or the organizations name?

No.

> Please enter any URLs of websites or social media accounts associated with your project (if applicable).

https://www.blockchaincommons.com/musings/open-integrity/

> By checking this box you agree that you must:

[]

---

## Next Zcash

1. HowTo/Examples of Using Envelope Tool with ZeWIF
2. Meetings
3. Walk Through of Someone Who Implemented

## Opensats

Sent: Nov 19

## Learning MuSig2 from the Command Line

Main Focus: Education

Project Name: Learning MuSig from the Command Line

Project Description:

Schnorr-based signing systems offer notable improvements over traditional signing systems because of their ability to aggregate signatures, creating small, scalable multisigs. Now that they are becoming mature, as seen by the recent merge of MuSig2 into libsecp256k1, we need to ensure that developers are educated in their use and given the tools that they need to develop their own Schnorr-based signature systems. That's the intent of this project: by building on the same model as our popular & successful Learning Bitcoin from the Command Line course, we want to produce the foundational tools needed to get developers working with MuSig2.

The "Learning MuSig2 from the Command Line" project has three fundamental parts:

1. Release an open-source MuSig2 `signtool` as a best-practices reference app demonstrating how MuSig2 creation can be simple and accessible for users. The default mechanism will ensure simple sharing of keys, nonces, and signatures. If possible, we will also enhance that with Gordian Sealed Transport Protocol (GSTP) to improve automation of the process.
2. Write an introduction to Schnorr-based signatures and discuss the differences between FROST and MuSig2.
3. Write a short course on using and testing MuSig2, in the same style as "Learning Bitcoin from the Command Line", with command-line usage and/or programming usage used as a framework to teach the concepts.

A tentative table of contents for the course, including both the introduction and the command line and/or programming content follows. It will definitely include command line usage of `signtool` and may also include use of `bitcoin-cli`, `munstr` or just `libsecp256k1`, depending on availability at project's start.

* 1.0: Introduction to MuSig2
* 1.1: Introducing MuSig2
* 1.2: The MuSig2 Signature Process
* 1.3: The Power of Schnorr
* 1.4: MuSig vs FROST
* 2.0: Signing with MuSig2
* 2.1: Using `signtool`
* 2.2: Creating a MuSig2 Public Key
* 2.3: Creating a MuSig2 Signature
* 2.4: Check a MuSig2 Signature
* 3.0: Using MuSig with Bitcoin
* [tentative based on availability]
* 4.0: Programming with MuSig
* [if insufficient command-line options exist]
* [starting with use of `libsecp256k1`]

Final deliverables are planned to be the `signtool` app, available as open source through GitHub, and a 7,500-15,000 word course, expected to run 3 or 4 chapters, licensed under cc-by.

A next step for this project, after this Learning MuSig project, is to incorporate FROST to have a more mature and multi-layered course covering a variety of Schnorr signature schemes ("Learning Schnorr from the Command Line"), but that goes beyond the scope of this initial work.

Potential Impact:

The goal of "Learning MuSig from the Command Line" is to demystify and popularize MuSig2. We want developers to understand what MuSig is and to see why it's superior to traditional multisigs. We then want to demonstrate how easy it is to create MuSigs in two different ways: through the creation of a best-practices reference app (`signtool`) and through the development of a hands-on course that shows how to create MuSigs with command-line apps and/or programming.

The ultimate goal, and the biggest impact is to improve the security and resilience of digital assets including Bitcoin. Traditional multisig methods are complex and they create big multisigs that are expensive to send. MuSigs, especially if built with proper tools that automate the back-and-forth of signature creation, can be much simpler and they are definitely much smaller (and therefore cheaper) due to signature aggregation.

We've picked the Learning Bitcoin from the Command Line model because it's been very successful. The course has been widely used, with 3,200 stars and 750 forks demonstrating its impact. Its hands-on approach to learning Bitcoin through command-line interactions has proven much more effective than a traditional pedalogical approach that teaches without hands-on exercises. As a result, Learning Bitcoin has brought new developers into the industry. Some of the interns that we've worked with first learned about Bitcoin through the Learning Bitcoin program. "Graduates" from the program have led efforts to completely translate the book-length course into Spanish and Portuguese (with an Italian effort ongoing).

Project Timelines & Potential Milestones:

The project is laid out as follows:

1. Develop & Release Signtool (4 weeks).
2. Write Intro (1 week).
3. Write Course Contents (4 weeks).
4. Get Feedback & Edit (1 week).

Project Website (if applicable):

Project GitHub (if applicable)

Open-Source License:

CC-By-4.0

Costs & Proposed Budget:

4 weeks programmer time * $150 = $24,000
6 weeks tech writer time * $125 = $30,000

Total proposed budget: $54,000

Prior Funding:

This is a new project, though it builds on prior FROST work, which was sponsored by the HRF, and a bit of introductory work on MuSig, which was sponsored by individual patrons.

Name: Christopher Allen
Email: xxx
Project Lead: Yes
Personal Github:
Other Contact Details:

References:

Jonas Nick (xxx)
Tim Ruffing (xxx)

Prior Contributions:

This project builds on the model that we developed for LEARNING BITCOIN FROM THE COMMAND LINE (https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line), albeit in a shorter, simpler form. Learning Bitcoin is a book-length course that uses command-line bitcoin-cli usage as a framework to demonstrate what Bitcoin is and how it works. We expect Learning MuSig to do the same, and to evolve over time into a full Learning Schnorr course.

We've already done some exploratory work on MuSig, including writing an introduction to Schnorr (https://www.blockchaincommons.com/musings/Schnorr-Intro/) and overviewing the sequence of Schnorr signature creation and usage (https://developer.blockchaincommons.com/musig/sequence/), with a focus on how it can be integrated with our extant GSTP system to make signature creation simpler and more accessible (which is why we are hoping to incorporate GSTP into a more advanced form of seedtool).

Gordian Sealed Transcation Protocol (GSTP) is a secure, distributed method for for transmitting sensitive data using unreliable and insecure data protocol (https://developer.blockchaincommons.com/envelope/gstp/). It's exactly what's needed to ensure the two-round signature creation of MuSig is secure, and will be a part of a best-practices reference app.

Beyond these contributions that specifically apply to this project, the principals for this project have all been working in the Bitcoin and blockchain space for a decade. Christopher Allen founded the Rebooting the Web of Trust design workshop, popularized the concept of self-sovereign identity, and has co-authored significant security protocols through the IETF, including TLS and Decentralized Identifiers (DIDs).

The principals have also advanced numerous reference apps and protocols through Blockchain Commons, including Uniform Resources, the Animated GIF specification built atop them, the Gordian Seedtool reference app for iOS, and much more.

Anything Else We Should Know:

The development phases of this project will be undertaken by Wolf McNally, who has already authored a number of CLI apps for Blockchain Commons, including keytool, seedtool, and envelope (as well as Gordian Seedtool for iOS). The writing phases of this project will be undertaken by Christopher Allen and Shannon Appelcline, the authors of Learning Bitcoin from the Command Line and the #SmartCustody book.

--

(notes)

LEARNING MUSIG & FROST FROM THE CL [NOT CL] **JUST MUSIG**
- Basic Code
- Practical Examples
- not CL
- Produce CL capable apps
- tests, harnesses, how to use them, how to code
[DOCS: SO TAKE LIBRARY, AND IMPLEMENT SOME CODE ON HOW TO USE IT]
[MUSIG IN BITCOIN-CORE]
- Add capabilities for MuSig2 & FROST coordination
- using GSTP

- Since MuSig2 looks like it is going to be in a release version soon (end of the month or early November?), we are investigating creating support for it using GSTP (Gordian Sealed Transaction Protocol), which also supports airgapped animated QRs (the same tech that many Bitcoin Wallets use for PSBT).

[later: add FROST]

To include:

EVALUATIONS OF ALTERNATIVES
- WHEN TO USE MUSIG, WHEN TO USE FROST
- WHAT ARE THE DIFFERENCES
- Can't use MuSig for threshold changes
- WHAT'S AVAILABLE
- ADVANCED THINGS EMERGING
- OUR PROFESSIONAL EVALUATION
- When available for prime time
- What signals?
- TKG vs DKG
- When use or not use DKG

Lots of general stuff, and some specific coding

## Zcash

- GST Interop

- meeting to explain benefits of interop
- Animated QR, etc [higher level, not BTC specific]

Applicant name:(required)
Write your name as you would like it to be displayed publicly: pseudonyms, including forum usernames or your organization name can be used

Do you have additional team members/collaborators?(required)

Yes

No
Please upload an image for your public facing profile and proposal to be shown on the pubic gallery.(required)

Choose File
Upload a file. No files have been attached yet.

Acceptable file types: .pdf, .gif, .jpg, .jpeg, .png, .svg, .tif, .tiff

Once you submit your application, the photo you upload will be shown publicly here.
Pitch: A one-liner elevator pitch version of your proposal(required)
Limit: 140 characters
Total Request (USD): (required)
$
USD
(You will be paid out in ZEC based on USD market price at payout time.)

Have you previously received a grant from Zcash Community Grants (formerly called ZOMG) or ZF?(required)

Yes

No

Are you seeking or have you received funding from other sources for this proposed project?(required)

Yes

No
DETAILS
If you have any questions please contact [e-mail].

Upload any relevant documentation regarding this project.

Choose File
Select up to 10 files to attach. No files have been attached yet. You may add 10 more files.

Acceptable file types: .csv, .doc, .docx, .odt, .pdf, .rtf, .txt, .wpd, .wpf, .jpg, .jpeg, .png, .svg, .tif, .tiff

Applicant background:(required)

Provide you and/or your team’s detailed background and experience. Demonstrate that you have the skills and expertise necessary for the project that you’re proposing. Institutional bona fides are not required, but we want to hear about your track record and/or see your portfolio of past work.
Description of Problem or Opportunity:(required)

What problem or opportunity will your project address or solve? Provide context for the problem or opportunity and clearly present how your project will add value to the Zcash ecosystem.
Proposed Solution: Describe the solution at a high level.(required)

Please be specific about who the users and stakeholders are and how they would interact with your solution. E.g. retail ZEC holders, Zcash core devs, wallet devs, DeFi users, potential Zcash community participants.
Solution Format: What is the exact form of the final deliverable you’re creating? (required)

E.g. code shipped within the zcashd and zebra code bases, a website, a feature within a wallet, a text/markdown file, user manuals, etc.
Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!(required)

Collaboration and Upstream Dependencies: Describe any dependencies or collaborations with other individuals, teams, or organizations that are required to successfully integrate, maintain, or upstream your changes.(required)

Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?(required)

Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.(required)

Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?(required)

Budget
Please provide the total amount of funding requested for each major heading (Hardware/Software, Services, Compensation) with a detailed explanation regarding how that budget was determined. The total of these three sections should add up to the total funding request amount. The clarity of this section will enable the review committee to quickly understand your reasoning for the funding requested.
The “Compensation” explanation should include who is being paid, how much they’re being paid (hourly, monthly, full project, etc.), and how each compensation figure was determined.
Hardware/Software total budget:(required)
$
USD
Please write "N/A" if not applicable.
Please provide justification for the total hardware/software budget: (required)

Please write "N/A" if not applicable.
Services total budget (cloud, hosting, etc.):(required)
$
USD
Please write "N/A" if not applicable.
Please provide justification for the total services budget: (required)

Please write "N/A" if not applicable.
Compensation total budget:(required)
$
USD
Please write "N/A" if not applicable.
Please provide justification for the total compensation budget: (required)

The “Compensation” explanation should include who is being paid, how much they’re being paid (hourly, monthly, full project, etc.), and how each compensation figure was determined.
Please write "N/A" if not applicable.
Schedule and Milestones: What is your timeline for the project? Include concrete milestones and the major tasks required to complete each milestone.
Milestones, and the deliverables associated with each milestone, are required for every project. Completed milestones trigger a review of all the deliverables associated with that milestone which leads to a release of funds. Please note that payment will only be made upon successful completion of all the deliverables associated with each milestone, not prior to the milestone being completed. Deliverables show progress toward grant completion and must be verifiable.
Each milestone may have multiple deliverables. A deliverable describes the specific outcome that will be evaluated by ZF/Zcash Community Grants committee when determining if a milestone has been achieved. Deliverables must be specific and verifiable. When writing deliverables ask yourself, “How will ZF/the committee evaluate the success or failure of this deliverable?”
Example Scenario:
Your project is requesting no upfront payment and two milestones (Milestone 1 and 2) with three deliverables (Deliverables 1.1, 1.2, 1.3, 2.1, 2.2, 2.3) under each milestone. You are estimating that it will take three months to complete the deliverables under each milestone. Three months pass and you’ve successfully completed the three deliverables under milestone 1. You are then eligible to request review and payment for Milestone 1. The same applies for Milestone 2, etc.
A lack of deliverables in your proposal, or vaguely written deliverables, will cause your proposal to be rejected. Please direct any questions regarding milestones and deliverables to [e-mail].

Do you require startup funding? (required)

Yes

No
Requests for start-up funding (funding provided prior to Milestone 1 being completed) must be supported by a justified need for this funding. If you are requesting startup funding you will be prompted to provide a detailed explanation for why this funding is required for the successful launch and completion of your project.
Milestone 1 - estimated completion date:(required)
Milestone 1 - estimated completion date:
Enter estimated completion date in the following format: xx/xx/xxxx You can type in a date MM/DD/YYYY or navigate forward to interact with the calendar and select a date. Press the question mark key to get the keyboard shortcuts for changing dates.
Enter estimated completion date in the following format: xx/xx/xxxx
Milestone 1 - USD value of payout upon completion of deliverables:(required)
$
Deliverable 1.1(required)

Enter additional deliverables for Milestone 1?(required)

Yes

No

Enter additional Milestones? (required)

Yes

No
Total proposed USD value of grant: (required)
$
USD
The total proposed value of your grant should equal the sum of all milestones.
How was the project timeline determined? (required)

How did you learn about Zcash Community Grants?(required)
Application submission date:(required)

## nlnet
## Gordian Envelope Playground

### Notes

* Deadline: December 1 (noon CET/8am Hawaii)
* Sent: November 6

### Content

* Name: Christopher Allen
* Email Address: [e-mail]
* Phone Number: 510-908-1066
* Organization: Blockchain Commons
* Country: United States

* Project Name: Gordian Envelope Playground
* Website/Wiki: https://developer.blockchaincommons.com/envelope/

#### Abstract: Can you explain the whole project and its expected outcome(s). [1173/1200c]

Gordian Envelope is a privacy-preserving data format that allows the structured storage of data that can be cryptographically verified through digital signatures. This data can be redacted by any data holder without impacting the data's verification. Inclusion proofs can then be used to prove the existence of redacted data. It's intended to improve privacy and protect human rights.

This project will encourage developers to adopt Envelope by creating a "playground" where they can create simple Gordian Envelopes containing data that can be wrapped and signed. It will allow the redaction of any data elements, including both nodes and branches of the Merkle-like tree. The Playground will also generate inclusion proofs for redacted content. Envelopes and inclusion proofs will all be outputtable. They can also be re-input to examine the validity of those proofs.

This will create a testbed that developers can use to examine Gordian Envelopes and to test their own implementations. A similar Playground was created for Verifiable Credentials, and it helped to bootstrap VC's deployment. The goal here is similarly to support the Envelope open standard among developers.

#### Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions? [2291/2500c]

Gordian Envelope is an open standard that I've been trailblazing for the last few years at Blockchain Commons. I architected the design of the specification and worked with my Lead Researcher Wolf McNally to turn it into a reality. Together we've produced a specification for Envelope as well as two command-line reference apps (envelope-cli for both Swift and Rust) that demonstrate the technology, as well as an iOS app (Gordian Seed Tool) that uses Envelope to secure digital assets.

I have been working with a number of standards groups on Envelope. Wolf and I have published eight iterations of Gordian Envelope with the IETF, which has resulted in improvement of the open standard. We use CBOR as our underlying binary storage technology, and so we've also worked with the IETF on improving the specifications for deterministic CBOR. This is a crucial element for Envelope because we hash data to support our inclusion proofs; this requires that data be inherently canonical. Our work on CBOR determinism encouraged the creation of the CBOR Common Deterministic Encoding (CDE) specification and we've written our own deterministic CBOR (dCBOR) application profile atop that.

I have strong experience in doing this sort of work before: both creating open & interoperable standards and pushing them to become worldwide standards.

I am the co-author of the IETF TLS standard, which ensures the privacy of banking, shopping, and almost all other interactions on the internet. I am also the co-author of the W3C Decentralized Identifier (DID) standard, which allows for personal control of identity. Today, I'm an invited expert to the new W3C DID working group, an editor for the DID resolution spec, and an invited expert to the W3C Verifiable Credentials 1.1 working group. As a successful member of the internet-standards community, I've seen what's required to get a specification up to the next level, and that's why I'm pursuing the development of a Playground for Gordian Envelope.

My work is done through Blockchain Commons, a not-for-profit company that focuses on the creation of open & interoperable, secure & compassionate digital infrastructure. We've already been successful in deploying new specifications such as animated QRs and a Shamir's Secret Sharing library called SSKR.

# Explain what the requested budget will be used for? Does the project have other funding sources, both past and present? (If you want, you can in addition attach a budget at the bottom of the form) [1515/2500w]

Blockchain Commons is a virtual company that employs contractors. As such, it has minimal overhead. This project is specced out at 10 weeks of time for our lead researcher, at $125 USD/hr ($125*40*10=$50k USD), plus 10% overhead to support my oversight of the project.

Initial research and work on Gordian Envelope was paid for by patronage from a number of sponsors, a few of them paying $5000/mo to support Blockchain Commons' work. Unfortunately, financial instability in recent years, including the advent of high interest rates, have turned investors away from digital-asset and identity work of this sort. This has resulted in funding drying up for our sponsors, several of who have been absorbed or changed their focus as a result. Blockchain Commons' current income is a meager $2,950 a month, from three major sponsors (Foundation Devices, Keystone Hardware Wallet, Unchained Capital) and a number of individual patrons.

We hope to further expand this project in the future, after a successful nlnet grant, by extending the simple Envelope Playground funded by this grant into a more extensive set of domain-focused websites that support the usage of Envelope to create credentials, to sign software, to validate AI training provenance, and to show off the possibilities of herd privacy. We are pursuing an NSF grant to support these extensions. In the meantime, however, this nlnet proposal is a clear, independent project with a well-defined goal of publishing a first-cut of a Gordian Envelope playground.

# Compare your own project with existing or historical efforts. [3196/4000w]

The data storage mechanism most similar to Envelope is clearly JSON, the JavaScript Object Notation, which has been widely accepted as a language-independent open standard for data storage and interchange.

Unfortunately, JSON has serious problems with both canonicalization and interoperability, challenging its open usage. Methods have been written for JSON canonicalization such as RFC 8785, but even if they were widely accepted, they remain an additional step. Envelope was instead written to be innately canonicalized from the start: canonicalization is an implicit part of the specification.

JSON is also rife with interoperability issues. Ordering, naming collision, numerical uncertainty, unicode-encoding issues, and inconsistent vocabulary (the last partly solved by JSON-LD) have all caused problems with truly open usage. Envelope already resolves some or all of those issues, many of them at the foundational dCBOR level. This creates a data format that is free of the considerable technical debt that is implicit in JSON.

However, the biggest difference between Envelope and JSON is the fact that JSON is not a privacy-focused data format and Envelope is. Obviously, data could be redacted from JSON, but Envelope does so in standardized, interoperable way that maintains a hash of the data after it's been removed. This hash is consistent thanks to the innate canonicalization of Envelope's deterministic foundation. That allows for redacted data to be provable (because the data can be checked against the hash that remains in the Envelope) and for signatures made for the data prior to redaction to remain valid (beause the signatures are made across the hashes rather than the underlying data). These capabilities are simply not available in JSON.

This data elision is not just Envelope's biggest difference, but also its biggest advance. Parts of a credential could be elided to protect a user's name, address, age, or other info that's not relevant for a specific situation. For a decentralized identifier, a key or an endpoint could be hidden. Two entities both knowing the same data might not even have to pass it in a transmission. In all cases, data is protected and privacy is preserved, yet the data can later be proven.

Considerable extensions further improve the capabilities of Envelope, including compression, encryption, and a secure data transmission format.

CBOR-LD has more recently appeared as a supplement to JSON-LD that compresses its content. This is certainly a strong advantage, but one that is matched by Envelope both in its ability to entirely redact data or alternatively to compress it, also using the CBOR format.

This project focuses not just on Envelope, but on creating a developer's playground that will allow programmers to experiment with Envelope and test their own deployments. This is a proven methodology for supporting a specification. CBOR has its own playground (https://cbor.me/) that we sometimes use to check our own work. Similarly, the VC Playground (https://vcplayground.org/) demonstrated the capabilities of Verifiable Credentials and aided in their adoption. Other playgrounds exist for OAuth, Passkeys, and many other specifications.

# What are significant technical challenges you expect to solve during the project, if any? [3244/5000w]

I feel like Blockchain Commons has already worked through many of the technical challenges of the Envelope format. For example, in our latest iteration of the dCBOR specification with the IETF, we incorporated Unicode Normalization Form C (NFC) to resolve an issue related to the canonicalization of Unicode streams. There still could be additional issues like this, and that's why we're continuing to work with the experts at the IETF. However, after a year and a half, 11 iterations of our dCBOR spec, and 8 iterations of our Envelope spec, we hope that we've resolved most of them.

We also don't expect any significant technical challenges from the production of a web-based Playground. We're already built command-line interface (CLI) programs in both Rust and Swift that successfully create and display Gordian Envelopes, so we know that Envelope provably works in the real world. The production of web-based Playgrounds is also a well-understood task. We've created our own very simple Playground that produces LifeHashes (visual hashses) from either UTF-8 text strings or SHA-256 hashes (lifehash.info). An Envelope Playground will be much more complex, but built upon the same fundamentals.

What remains instead is a _significant social challenge_. We know that privacy-preserving data formats offer huge advantages to society as a whole, and that in particular they benefit individuals. The April 2024 breach of National Public Data that revealed almost 3 billion records, including social security numbers and dates of birth, showed just how devastating the revelation of poorly protected data can be. (We're likely to see the repercussions of that for years as billions of individuals have been exposed to identity theft by poor privacy practices.) However, we also know that privacy is a hard sell: even in the face of data breaches like that at NPD, it's hard to contextualize privacy's importance to the average consumer.

That's why we've chosen a developer's playground as the end-product of this project. Developers are more likely to understand the needs of privacy. They'll see the power of redacting data and then proving its existence with inclusion proofs. And, if not (because honestly, privacy is a hard sell even to developers) they may appreciate some of the other advantages of Gordian Envelope, such as the integrated capability to encrypt data or even to lock data with multiple, sharded keys and then restore it with a threshold of those keys using Shamir's Secret Sharing.

We just need to get Envelope in front of those developers and we need to make it easy for them to create Envelopes, to send Envelopes around, to test their own Envelopes, and ultimately to test both redacted Envelopes and the inclusion proofs that verify the existence of redacted content. That's what the playground is intended to support.

Will we ultimately succeed? That's the social challenge, but we have strong experience working with the developer community through our monthly Developer Meetings and through special workshops such as our Silicon Salons and FROST Workshops. We intend to continue meetings and workshops of this type, so that we can really hear what the developer community wants and move the Playground in that direction.

# Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes? [2484/2500w]

As a fundamental data-storage and transmission mechanism, Envelope can span numerous ecosystems. We feel that the entry point to most of them is developers, which is why we are creating a Playground for their usage. This is an expansion of our monthly Blockchain Commons meetings with developers and our work with IETF developers (primarily through the CBOR working group). We expect to continue that, as well as potentially working with the IRTF on supporting elision as a standard.

However, we believe that we simultaneously need to work with the leaders of specific, identified ecosystems who might use Envelope, and that's what we've done to date.

Most of our specific ecosystem work has been with the digital-assets community. Our own developer meetings focus on wallet manufacturers (resulting in changes to our digital-asset extensions to better meet their needs). A partnership with Foundation Devices, the maker of a high-quality hardware wallet, has been another major connection in this area and has driven Envelope work for both of us. Our other major partnerships, with companies such as Bitmark, Chia, Keystone, and Unchained Capital, have all been in the digital-asset area. We expect these to multiply through our creation of a playground and our capability to store, shard, and recover digital-asset seeds.

We've also worked on Envelope with the verifiable credentials ecosystem, primarily through the W3C Credentials Community Group (CCG). But, we have an even longer experience with this ecosystem: DIDs and VCs were both incubated and matured in the Rebooting the Web of Trust that I founded, which produced more than 50 papers across 11 workshops. I was also the co-chair of CCG for 5 years. Because of Envelope's strong ability to create, store, and redact credentials, we expect to use this decades' worth of experience and connections with the credentials and identity community to Envelope's benefit.

We have made connections to other ecosystems where we think Envelope will be particularly impactful. That included a long-term relationship with Proxy, the creator of a smart ring that store wellness information. Unfortunately, economic conditions forced Proxy to accept a buy-out from OURA. We are waiting for OURA to begin working on the privacy issues that Envelope can support.

Our next-generation work after creating a foundational Playground will be to develop overlays for specific industries, which we hope will improve our integration with those sectors.

## Attachments

* PDF of dCBOR RFC
* PDF of IETF RFC
* Intro to Envelope Video?
* Intro to Extensions Video?

---

- open with a subset of NSF (Envelope)
- privacy-centric format
- W3C, IWF
- Presenting credentials community 22nd
- presenting at IETF, dCBOR has traction
- PLAYGROUND

open, resilient, trustworthy, sustainable and human-centered internet. Are you working on open hardware, open software, open data or open standards? We financially support organisations and people who are developing open solutions that empower users on all layers of technology.

- 50k euro max
- ??

NGI Zero Commons Fund
Reclaim the public nature of the internet
The commons model works. Free and open source software and hardware, open standards, open data & AI, open science and creative commons benefit everyone instead of a few. The goal of the NGI0 Commons Fund is to help deliver, mature and scale new internet commons across the whole technology spectrum, from libre silicon to middleware, from P2P infrastructure to convenient end user applications.

## New One to Consider

https://www.okx.com/learn/okx-bitcoin-developer-grant

## ??

- 2025 FROST Workshops
- 2025 FROST Work

## HRF

- ??
- Maybe FROST after Dec 4 meeting?

[inquiry: update old proposal]

## Tezos

See: https://x.com/tezosfoundation/status/1848676402603626659?s=46&t=ePUcgPP2MpmlY7AiPMPAZg

Idea: Maybe we should point out we already support Tezos addresses, and offer to do L0 developer education like we plan to propose to Zcash

## Geyser Funds

### Notes

- https://about.geyser.fund/
- educational grants
- Learning Bitcoin
- so mention foreign language versions

- Small grants
- No open funding
- Also Kickstarting
- But small successes

ALSO SEE: Funding Bitcoin

## Sovereign

1. Not funded by any other public entity
2. Prevelance is a criteria

I was thinking focus would be Airgap for more wallets, including seeds, qr, keys, signing requests, portability (since it is mandated now by EU law).

https://www.sovereign.tech/programs/fund

## NSF: Experiential Learning

https://new.nsf.gov/funding/opportunities/exlent-experiential-learning-emerging-novel-technologies/nsf25-511/solicitation

DL: February 25, 2025

My notes:

This does sound to me like LBTCftCL++

It looks like it'd need four major parts:

1) Learning experiences
2) Organization of learners into cohorts with community & mentors
3) Partnerships with companies in the space seeking interns
4) Some way to suggest sustainability after we close out our active work

I can vaguely envision a nice hub site with video and command-line learning and community features. But there's still a few steps beyond that. If we feel good about brainstorming a slightly larger model, it seems like a good fit and that we'd have somewhat of an in with our smaller-scale LBTCftCL work.

Other Thoughts:

There also may be teaching opportunity given the intersection of progressive trust elision, multisig, edge, cliques, cryptographic selective disclosure, and other proofs.

At the command-line level