[MINUTES] CCG Weekly 2025-09-02

CCG Weekly Meeting Summary - 2025/09/02

*Topics Covered:*

   -

   *Introduction of DID Method BTC1:* A new Decentralized Identifier (DID)
   method using Bitcoin as a verifiable data registry was presented. This
   method addresses pain points in existing DID methods, including offline
   creation, aggregation, late publishing, privacy, resilience, resolution
   scope, and update delegation/attenuation.
   -

   *BTC1 Solutions:* Four solutions were detailed: BTC1 beacons (for
   announcing updates), Zcaps (for authorization), guaranteed invariant
   provenance (to prevent late publishing), and sidecar data (for privacy and
   offline creation). A demo showcasing the creation, update, and resolution
   of a BTC1 identifier was presented. Challenges with the demo's sidecar data
   construction were acknowledged.
   -

   *Standardization and Future Plans:* Discussion centered on the future
   standardization path for BTC1, with options within the W3C and other
   organizations considered. The focus is currently on implementation and
   community engagement through podcasts and conferences.
   -

   *Aggregation and Cost:* Questions were raised regarding the cost and
   potential for silencing users through aggregation mechanisms. The
   presenters emphasized the use of singleton beacons as a fallback and the
   ongoing research into scalable multi-party signature schemes for
   aggregation.
   -

   *ZCAP Usage and JSON-LD:* The use of Zcaps for authorization was
   discussed. The presenters indicated flexibility in potentially removing
   JSON-LD aspects of Zcaps, depending on future needs and use cases. The
   potential for future ZCAP standardization was also discussed.
   -

   *Resolution Time and Target Audience:* Questions were asked about the
   resolution time of BTC1 identifiers, with discussion around the use of
   blockchain indexers to optimize performance. The target audience was
   discussed, acknowledging the need for varying levels of instantaneity for
   different applications. Censorship resistance was highlighted as a key
   benefit.

*Key Points:*

   - BTC1 offers a novel approach to DID management leveraging Bitcoin's
   security and decentralization.
   - The method addresses several limitations of existing DID methods
   through innovative solutions like beacons, Zcaps, and sidecar data.
   - Future work includes further refinement of the specification, wider
   implementation, and exploration of scalable aggregation techniques.
   - The use of Zcaps and JSON-LD is flexible and may be adapted based on
   future requirements.
   - BTC1 aims to provide a censorship-resistant and secure DID solution.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-09-02.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-09-02.mp4
*CCG Weekly - 2025/09/02 11:54 EDT - Transcript* *Attendees*

Alex Higuera, Benjamin Young, Chandima Cumaranatunge, daniel pape, Erica
Connell, Fireflies.ai Notetaker Lina, Geun-Hyung Kim, Greg Bernstein,
Gregory Natran, Harrison Tang, Hiroyuki Sano, Ivan Dzheferov, Jay Oster,
Jennie Meier, Jesse Wright, Jintek, Joe Andrieu, Kaliya Identity Woman,
Kayode Ezike, Leo Sorokin, Lina Hadboun, Mahmoud Alkhraishi, Manu Sporny,
Phillip Long, Rob Padula, Ryan Grant, Ted Thibodeau Jr, wendy seltzer, Will
Abramson
*Transcript*

Will Abramson: Hey Joe.

Joe Andrieu: Are you ready?

Will Abramson: Yeah, I think so.

Joe Andrieu: I think so, too. I think these were pretty good yesterday, so
it'll just be better.

Will Abramson: Yeah, I got a slight tweet from Ryan. He didn't like the
motivation side, but it's fine. I think I just Yeah, whatever. So,…

Joe Andrieu: Okay.

Will Abramson: he just said to skip it that the motivations to him were the
pain points. So, we don't know. The teams here.

daniel pape: Hello. Is there an IRC channel for these meetings too?

Will Abramson:

Will Abramson: No, no. we just have a Google Gemini transcribes and…

daniel pape: Cool.

Will Abramson: records the call. And then I guess we do use Zoom call
messages a little bit. Not really. I think generally you just put your hand
up like that. Got to get on the queue.

daniel pape: Hey, I haven't really noticed your new avatar with the hat and
sunglasses. Looks like you're on holiday.

daniel pape: Or is that how you look every day? Nice.

Will Abramson: Yeah, I guess it's actually me coming home from Glastonbury
8 in the

Will Abramson: Here I'm good.

Harrison Tang: Hey, Will. How's it going?

Will Abramson: Yeah. How you Heat.

Harrison Tang: Same old. All right, I'll play the host today and you'll be
the presenter. we'll start in about a minute.

Harrison Tang: All right, we'll start now. So, welcome everyone to today in
this week's W3C CCCG meeting. today we're very excited to have Will our
co-chair and Ryan here to talk about the BTC1 101. So going to be a
exciting topic. I actually heard Will's talk at IW earlier. So this is
going to be a good one. Now before we start, just want to quickly do some
administrative stuff. So first of all just a quick reminder on the code of
ethics and professional conduct. Just want to make sure we have and
continue to have respectful and constructive conversations. a quick note
about the intellectual property. Anyone can participate in these calls.

Harrison Tang: However, all substitive contributions to the CCG work items
must be the member of the CCG with full IPR agreements so if you have
troubles with getting a free W3C account or the contributor license
agreement, feel free to reach out to any of the coaches. these calls are
automatically recorded and transcribed and it will be automatically The
transcriptions and video and audio recordings will be automatically sent
out within the next 24 hours. All right, I just want to take a quick moment
for the introductions and reintroductions. So, if you're new to the
community or you haven't been active and want to engage, feel free to just
use the raise hand features in Google Meet or just unmute and introduce
yourself a little bit.
00:05:00

Harrison Tang: Reina, please.

Lina Hadboun: Hi everyone. Nice to meet you. I was introduced by Will to
this group. we met in Geneva last month the conference and I'm from the
center for digital public infrastructure. So we'll be presenting in two
weeks I think and I'd suggested that I join a meeting before. So I'm
delighted to be here and looking forward to learning a bit more.

Harrison Tang: Glad you're here, too, Lena. Anyone else?

Will Abramson: Thanks.

Harrison Tang: Don't be All quick announcements reminders. Onion place.

Manu Sporny: Thanks Harris there was an email that we just sent out to the
mailing list yesterday. it's a poll on the things that we should
standardize next in the verifiable credentials working group. so as many of
we incubate technology and specifications in this group, the credentials
community group. and once they're ready to be promoted, we promote them to
the global standards track at the worldwide web consortium. we have a set
of things that we're trying to gather feedback from the community so let me
put the link into the chat channel here.

Manu Sporny: this is a link to the email which will link you to the poll.
but basically we're trying to figure out, we're trying to find, we've got
multiple market verticals here. We're trying to get feedback from everyone
on what they think the priorities should be for the next verifiable
credential working group charter. we are going to probably create that
charter and potentially vote on it by W3C the technical plenary we have a
lot of things in flight right now and so we need to understand priorities
which one of these items is going to impact the ecosystem the most
positively who's willing to help move the things forward things like that
so if you have an opinion please fill out the form

Manu Sporny: form. we really need help prioritizing the work items for
global standards track. that's it.

Harrison Tang: Thanks Manu

Will Abramson: So I have a couple of things.

Will Abramson: First is kind of related to this talk today. I think we have
a work item that DCD and Legendary proposed called BIP 340 a data integrity
crypto suite using signatures. I'm pretty sure this is adopted and so
please jump on the call if you guys have any concerns about this. But I
think there's just the final step like I need to send out an email saying
that we've adopted it and then I think Ryan we need to transfer the repo
across to the CCG which I think we can just execute a repo transfer, That's
probably the best way to do it and bring it under CCG control. That's just
the flag that I will probably try and do.

Will Abramson: I think I just dropped the ball and didn't send out the
final email. and then the other thing is tomorrow we'll be having the APAC
coordination call. So just to decide what are we going to do in October
around a series of APAC events. So that is at 10:00 a.m. UK time. So
probably all US folks can't join but that's fine. So if you're kind of
joining, you are in the UK or APAC regions, we'd love to have you and help
us shape this agenda for October.

Harrison Tang: Thanks, Yeah, I sent out the meeting time and details for
the APAC call in the chat. All right. Any other announcements and the word
so you can see all the W3C CCG related meetings in the W3C calendar in the
link that I just shared. There's a lot of meetings now. There's the regular
Tuesday calls and then there's the APAC call, there's incubations and
pullotions, data integrity, VCEDU. So a lot of great events.
00:10:00

Harrison Tang: but then it could be a little bit confusing So that you can
just refer to the W3C calendars to see which ones interest you and if you
have any questions feel free to reach out to me and any of the cultures.
All right. Next work item updates or related things. Will you just mention
one? I think there's no objections. I support it. if people have comments
feel free to comment on GitHub. Yeah. M please.

Manu Sporny: I guess it's worth mentioning we are getting ready to publish
final community group specifications for render method and confidence
method. those are within the current BCWG charter. There's just some
process we have to do to get them published and transferred over to the
BCWG.

Will Abramson: Peace.

Manu Sporny: One of the final reports was accepted for publication today.
the W3C staff deal with it and then another one hopefully will come
tomorrow or the day after. so just a heads up usually what we do once the
chairs have to make a determination to publish as a FCGS and then we will
ask people that have contributed to these documents to make the
intellectual property commitments. there' once the final one is published
then the people that worked on it will make intellectual property
commitments basically saying we know this is going global standards track
we're not withholding any patents or don't know of any patents or any of
that stuff. So just noting that we are going to probably be doing that
ceremony over the next couple of weeks. That's it.

Harrison Tang: Sounds good. Thanks for the heads up, Money. All right,…

Harrison Tang: last calls for introductions, announcements, reminders, or
work item related questions or updates. All right, let's get to the main
agenda. So again, very excited here to have Will and Ryan to talk about did
BTC won. So well are the four shirts.

Will Abramson: Great. Thanks.

Will Abramson: Yeah, I'll keep my camera off for most of this. I'll just
say hi. Yeah. So, I mean, everyone knows me, Most people, I guess. I'm one
of the chairs of this group, but today I'm representing some work that
legendary requirements have done for Ry DCD digital contract design. And a
bunch of us are on the call today. So, Ryan's on the call and lots of
others who have worked on this presentation and this work. Right. So, let's
get into it. I'm going to turn my camera off again. Nice to see you all.
Okay.

Will Abramson: So should be able to see my screen. can you still see my
screen?

Harrison Tang: Yep.

Will Abramson: So, Yeah. Okay. So, today I'm going to introduce to you a
new DID method that we've been developing called This is a DID method that
uses Bitcoin as its verifiable data registry. so I'm just going to
introduce it to you guys and would love to hear what you think. So first
I'm going to just review the timeline. I think it's interesting to put this
into perspective both on the work of this community, the work of Bitcoin
and just the time and effort that has gone into developing this DID method.
Second, we talk about the pain points. So what has motivated us to create
yet another DID method? what are we trying to address with this D method?
And then the solution.

Will Abramson: So the BTC1 introduces four solutions that address different
aspects of these point pain points. So I'll walk through each one of those
and then we'll do a demo. So I have a dup set of Jupyter notebooks or one
Jupyter notebook really that just walks through the flow of creating,
updating and resolving a DIB BTC1 identifier. Finally some next steps and
hopefully have time for Q\&A. So yeah, the timeline of this work. So this
has origins in rebrooting the web of trust and really IW2 but rebooting the
web of trust. I think in 2018 we saw the first R design decisions paper So
BTCR is a Bitcoin reference did method that showed how you can create a DID
method using the Bitcoin blockchain. And then in 2019 we had did BTCR
published as a specification of the DID method.

Will Abramson: But then 2020 to 2022, we have a bunch of things happening
throughout the ecosystem. Importantly for us, Taproot and Schnore were
activated. So this is a new type of signature scheme and a new address
format in the Bitcoin ecosystem. It was adopted and included into Bitcoin
core. And then for us in the credential community group, right, it core was
adopted as a W3C recommendation in 2022. And also this work has started
from at least 2022, right?
00:15:00

Will Abramson: We started researching and developing what's next after BGCR
and this work did BGTC1 in 2023 we started drafting this specification so
it's been going on for a long time it's been interesting to see it evolve
2024 right we have the first proof of concept develop we actually turn this
spec into code or some code that shows how you can do it and we started
working on the crypto suite because we recognized that we needed a data
integrity crypto suite using signs and then today 2025 we now have
implementations being developed in Python, TypeScript, Rust and Java. And I
guess as we just discussed right, this bit 340 crypto has been adopted as
the CCG works. okay. Yeah. So the pain points that we're trying to address
in the DID space I suppose that we noticed from a number of different DID
methods u being developed. The first one is offline creation.

Will Abramson: in the BTCR to create a identifier you had to broadcast and
have a Bitcoin transaction included in the blockchain and this gives a time
delay on creating your identifier maybe it's 10 minutes maybe it's a whole
hour depending on your security concerns so we wanted to be able to create
as many did BTC1 identifiers as a did control wishes without having to
interact with any external parties. The second is aggregation. So, we
wanted to support aggregation because we wanted this DID message to be
scalable to, thousands of bids. And in particular, instead of DID document
in BTCR, a update requires a spend on the Bitcoin blockchain. In DIB BTC1,
we wanted to enable updates to be announced on the Bitcoin blockchain.

Will Abramson: But with one transaction, you could announce tens of
thousands of updates. So aggregate multiple updates together and broadcast
those to the public in a single bitcoin transaction. Third, we wanted to
avoid late publishing. So did ion and some other did methods, they have
this concept where there can be a fork in the history. And by selectively
revealing different data at different points in time, the history can
change from one fork to another such that at one point in time, this fork
looks valid, but in the future, that fork looked like it was never valid.
And the reason we wanted to avoid late publishing in this manner is to
enable non-reputable digital receipts.

Will Abramson: So, you could take back a receipt to a shop and guarantee
that they're going to honor that. Whereas with Slate Publishing, there
could be a way that the shop say, "No, that was never a valid receipt. we
never issued that." Basically, fourth, privacy, we wanted to enable div
documents that were more private. So, often typically in the ecosystem, if
you did you can resolve that identifier to the current DID document. We've
enabled a way that you can only resolve DPTC1 identifiers if you have
certain extra information. Fifth is resilience. We wanted to prevent there
being a single point of failure. So updated DID documents can be announced
and broadcast through multiple avenues. Then resolution scope.

Will Abramson: So resolution scope is limiting the amount of information
that did resolvers need to process such that resolvers only need to see and
process data for the DIDs that they care about rather than in did ion for
example resolver needs to have awareness of every single did ion
transaction. and seven is update delegation and attenuation. We wanted to
explore more flexible ways to exercise control over a div document
throughout time through delegation and attenuation. So s yeah we have four
different solutions. These address different aspects of those pain points
we just discussed. The first is DTC1 beacons. Then we use Zcaps. we
guarantee invariant provenence and we introduce this concept of sidecard
data. I'll talk through each one of these in turn.

Will Abramson: So the first solution is BTP1 beacons and this is a new
construct that we've defined. So a beacon is identified by a bit Bitcoin
address and we include the beacon within the DID document and through these
beacons we can announce updates and anchor these updates in resolvers scan
the Bitcoin blockchain and they look for spends from these Bitcoin
addresses that have been identified within the DID document that they are
resolving. Spends from these Bitcoin addresses are called beacon signals.
And beacon signals announce, commit to and anchor in Bitcoin block time one
or more BTC1 updates. yeah, and these onchain commitments, right?
00:20:00

Will Abramson: is anchoring in a block in bitcoin ensures this invariant
provenence of the entire bid history. So yeah, a bit more about beacons. We
have different beacon types define a mechanism for announcing updates and a
mechanism that a resolver can validate a BTC1 update against the beacon
signal. So there's three types, a singleton beacon, a map beacon, and a SMT
beacon. The singleton beacon just announces one. That's the simple version,
right? we're just announcing a single update. Map beacon and sparse noy
beacons support aggregation and map beacon is committing to a document that
maps from BTC1 identifiers to the updates for that identifier.

Will Abramson: And this is similar to how did ion works and it's designed
for content arrestful storage systems like IPFS. The sparse Merkel tree
beacon the beacon signal is committing to a root of a sparse Merkel tree
and in that sparse Merkel tree there are paths the leaves of the sparse
Merkel tree are indexed by the BTC1 identifier and those leaves either
contain an update to that identifier or an announcement of an update to
that identifier or they're empty. So in a sparse local tree approach you
need sidecar data which we'll get to in a moment but essentially you have
to prove that your update in this route is in this tree as attested to by
the route that is included in the on the next solution we'll talk about is
authorization capability. So this is using the CCG zcapd. So it's a JSON LD
based object capability for authorization management.

Will Abramson: so the BTC1 the update that defines the mutation to a DID
document is a ZCAP right and it's authorized through the capability
invocation relationship in that is being updated in the DID doument DID
being updated. So by invoking capability over the update data you are
securing that data meaning can't change and make sure it's authorized by
the data controller in some yeah and then resolvers are evaluating these
zcaps so they can verify that the proofs attached to these updates about we
use JSON patch so that allows arbitrary changes to a div document. We
noticed that in some situations did methods have defined precise mutations
like add remove verification method as specific operations that are just
custom to that spec.

Will Abramson: that's quite limiting and prevents some of the benefits of a
DID document which can have any information in that a DI controller wishes.
JSON patch is much more flexible in that way and also in the future we're
hoping that by using decaps we can support delegation and attenuation of
capabilities such that you can delegate to a specific key to only be able
to add services to your DI document for example. the next solution is
guaranteed invariant provenence and this is really to address late
publishing. we want to make sure that there is a single history of the DID
document throughout time. So two to version three. There should never be
able to be two version 3es that are different. At the same time, we wanted
to enable there there to be redundant publishing of updates.

Will Abramson: multiple different beacons can publish and announce So the
same for example if you see here right there are two updates update two
that go from two to version three. We wanted to enable that so that you
don't have this single point of failure where you have a single beacon can
only broadcast one update. and as long as these updates both get to the
three of the DI document then that's fine. But if they were to create a
fork then this would be a fail and we call this a late publishing error and
throw an error. also we have a rule or this requirement or at least a
strong recommendation that all beacons beacon spends so beacon signals must
be authorized by every single controller that is part of that beacon cohort.

Will Abramson: So if this is a beacon that is announcing updates for a
thousand bid controllers then we would have an N ofn signature authority
over that beacon signal using music 2. yes and resolvers must be able to
process every single beacon signal that they identify from beacons within
the div document that they are resolving. the last solution is sidecar data
and this is what enables private DID documents and really offline creation
with arbitrary complex DID documents. So sidecar data is a way to provide
the resolver with additional information that the resolver requires to be
able to resolve a BTC1 identifier to its current DI document. And if it
can't get this sidecar data then it is unable to find and validate the
current DI document for that identifier.
00:25:00

Will Abramson: So yeah, this is just way to provide this outbound service.
Right now I'm going to walk through a demo. How are we doing for time? I
think we're okay. Yeah, so this is the Jupiter notebook and that link there
which I guess we'll share the slides. you'll be able to run through this
yourself if you're interested. There is also a PDF version of this demo. So
how I will outline, we're going to do some key management, This is
decentralized identifiers require public key cryptography. We're going to
create some keys and manage those keys over time. And using those keys,
we're going to construct a DBTC1 identifier. We're going to then resolve
that DBTC1 identifier using sidecar. we're going to construct an update for
that initial DID document to move it from version one to version two. And
then we're going to announce that update using a beacon that is in the
version one document.

Will Abramson: And then hopefully we're going to resolve this again showing
you how you can resolve to version two using the site card data. So first
to config right we're just defining the network that we're going to anchor
our data in this case using mutiny net which is a type of signet it just
has faster box and it's useful the test network basically. Okay, so key
management, right? We need to create some keys because keys are going to be
used for things like verification methods and beacons, keys control bitcoin
addresses. So they control bitcoin spends which are beacon signals. So the
first thing we do is we generate a hardware route. This is like your ledger
for example, but in this case just in Python, we have some speed phrase. We
generate a root key and then we can derive keys from that root key. So
we're going to derive two key pairs. One for a verification method, one for
our singleton beacon service.

Will Abramson: So we've got our keys. we want to construct the DIB BTC1
identifier. And in this case we're doing the external mode which is
basically we construct some initial DID document. We call it the
intermediate DID document and then we use that DID document to generate
some bytes and those bytes are what goes If you see here, the identifier
construction is a beex 32 encoding of the SHA 256 hasht of this external
intermediate document that we're going to construct. Plus, a bite for the
version, which is one, and a bite to the network. So, the reason it's an
intermediate did document is because we don't know the identifier yet. we
have this placeholder value and we put that placeholder value in everywhere
we want the identifier to be once we construct the identifier.

Will Abramson: So we just build up this did document, right? We're adding a
multi key verification method. We're saying we can use that verification
method to the assertion method and the capability invocation adding a
singleton beacon service. So this is a beacon service that says okay it's
going to be of the type singleton beacon and it's going to have spend from
this address should be considered as beacon signals. Then we construct the
DID. So this has this initial intermediate did document. We basically
canonicalize and hash the document to get the genesis bytes and then we be
exerted to encode those genesis byes to create the identifier and then we
just replace that identifier in the divid document. So you'll see this is
the placeholder this is the intermediate divid document with the
placeholder values. the genesis bytes and those genesis bytes are then
encoded into here.

Will Abramson: So the divid itself is attesting to the initial state of the
divid document and then this is the initial divid document which is just as
the placeholder values replace the identi Now resol we're going to resolve
just the initial state. So there's no data on chain but we need sidecar
data in this case because we need to provide the resolver with the initial
bid document. we got to construct some sidecar data. and the sidecar data
is saying this is my initial DID document and then we pass that sidecar
data to the resolver using resolution options and this is defined by the
divided resolution spec so yeah we're going to use the universal resolver
and basically we copy this is the div that we just created and then these
are the options I can
00:30:00

Will Abramson: And you see this small box here is where you put in the
resolution options. And if we click resolve. So there we go. Have it. This
is Daniel Pek and Marcus' implementation of the universal resolver. They
have adopted the BTC1 specification. And what it's doing is basically
validating that the initial document we provided is the initial document
that is attested to by the DID BTC1 identifier. You can see this divid
document here is the same did document as the one that we just created.
Okay, so that's pretty cool, but we haven't actually done an update, So
next we're going to create an update to add a new verification method to
our DID document. So first thing we need to do is generate a key pair. So
we just derive a new key. we create the multi key verification method for
that key and then we construct the patch.

Will Abramson: So the patch is basically saying okay let's add that
verification method to the end of the set of verific verification methods
in the document and we're going to add that verification method allow that
verification method to be used for the verification relationship. That's
what the patch looks like. This is Jon patch which is an ITF spec. then
we're going to apply that patch to the documents to do that mutation and
we're just really validating that we've done it correctly essentially. And
you can see look here's the new verification method and there's the new
verification relationship. So next we construct source and target hashes
and this is just to kind of create a hash chain from one version to the
next. So that the source h is saying okay this update should be applied to
this source and the target is once you've applied that update this should
be the target of DID document and we also increment the target version ID
which is just saying okay this is the second DID document. Okay.

Will Abramson: And then we construct this unsecured BTC1 update which just
putting all that information together into a SON object JSON LD object.
Next, we're going to secure and invoke this update. So this is attaching a
proof to the update we just created. so yeah, we want to get the signing
key. So we can use this key because it's the key that is authorized for
capability invocation. So we get that key and we generate this multi key
which is the signing key essentially for this proof. We instantiate our
crypto suite so this is an interesting part that is slightly complicated
but essentially our spec defines a way to generate a root capability for
every DIBTC1 identifier.

Will Abramson: There's a deterministic generation and this is what the root
capability looks like and we say that the invocation target is the
identifier itself and our spec understands to mean that this is the
capability to update this DI document. so these are the options for the
proof. You can see this is the crypto suite bit 340. we identify the
verification method we're used to signing and we specify the invocation
target and the capability and then we add that proof to the document. We're
just attaching it. And you can see here we've added this proof object with
the proof value to the signature. So it just secures the integrity of this
proof BTC1 update. So that's good. But nobody knows about that update yet
or there's no way for us to announce that update to the world. What we want
to do is use our broadcast that update in a beacon signal and anchor it in
the Bitcoin block time. So that's what we'll do next.

Will Abramson: yeah. So, basically what we're trying to do is construct A
Bitcoin transaction has transaction inputs and Transaction inputs are
basically spends of unspent transaction outputs from earlier in the
blockchain. And a beacon signal must spend at least one transaction input
that spends a UTXO controlled by the beacon address. And also, it must
include in the last index of a transaction output that looks like this.
basically just anchors or commits some 32 bytes of data that we call signal
bytes into the Bitcoin blockchain using op return. so we're going to
identify the beacon that we want to use. our document only has one beacon
has a singleton beacon. It looks like this in DID document. It is type
singleton beacon.

Will Abramson: has a specific Bitcoin address and as we're managing our
keys, right, we know the secret key that can spend from that address. And
then we got to identify some UTXO that we're going to spend in our beacon
signal on this UTXO needs to be controlled by the beacon address. So I've
already funded this address on the muting network. This is the transaction
here. and we're just going to check, okay, yes, you see what we're finding
the UTXO index. So this is the zero transaction output, and we're checking
that index is controlled by the address that is our beacon address. So the
UTXO has this transaction ID, which we could look at on the mutet, but I'm
not going to do that right now. Then we construct what we call a 1 update
announcement. And this is just the hash of the canonicalized 32 bytes of
data.
00:35:00

Will Abramson: And then we construct the unsigned singleton beacon signal.
And this is just as I said, we're basically taking that BTC1 update, we're
cononicalizing it and hashing it, getting 32 bytes. And in this case for a
singleton beacon, those 32 bytes are the 32 bytes that go in the last
output of the Bitcoin transaction that we're going to construct. So here
you can see we're creating some The transaction input is for the
transaction that we just fetched the UTXO and we identify the index zero.
So that is the UTXO that we're spending. We fetch some fee. This is just to
make sure that the transaction gets mined. And then we're going to have two
transaction outputs. The first is a refund amount. So we're just making
sure we're saving the money that we have in that UTXO apart from the fee.
And then the second is the important one where we commit to these beacon
the signal bytes, right?

Will Abramson: we commit to the announcement. So you can see this this is
the op code for op return and then this is the update announcement the 32
bytes that is the hash of the BTC1 update. Then we construct that signal.
So that's all good. And then what we need to do is we need to authorize
that signal. So we're going to sign it using the secret key that controls
the address. So we sign it and then we can serialize it and hex it. And so
I haven't done this bit yet because I'm hoping it's going to work. I think
it Let's see. we can announce this right so even in this case until I press
this button nobody knows and can find this update if I broadcast it right
so we've just spent a transaction and broadcasted this transaction on the
Bitcoin in on the mutet blockchain I should say so that's pretty cool yeah
so we just got confirmed I don't know is Marcus are you on the call I don't
know if

Will Abramson: how many confirmations we need…

Ryan Grant: Man, go ahead.

Will Abramson: but my plan is so maybe we can pause and take questions if
there are any and then I'm going to try and also resolve that do the
resolution flow again using the universal resolver to resolve this
transaction to resolve this data right with the updated div document yeah
go for Adam I'm not watching

Manu Sporny: Yeah, this is awesome awesome stuff, really deeply impressive
stuff here. and really love how you've kind of put together Jupyter
Notebook to kind of walk people through it. It's so much easier to
understand what's going on here. so this is awesome. I have multiple
questions. I'll try to just ask one of them. what are the plans for this?
It feels very wellformed at this stage. What are you thinking for kind of
standardization track here?

Will Abramson: Yeah, that's a great question. I wonder if maybe I mean we
certainly want this not to be just a DCD thing, but maybe Ryan can speak
more to that.

Ryan Grant: I think we have options within the Bitcoin space and…

Will Abramson: We're thinking about it. I don't know if we have exact
answers yet, but maybe Ryan can

Ryan Grant: we have options within the W3C and other standards
organizations and it's really a matter of interest. I don't think that the
spec really needs one standards body over another and it's really just who
wants to host it. So, we're focusing on implementation, writing lots of
code that people can use so that other people can understand…

Ryan Grant: why they want it. and then we'll find the right match. Thanks

Will Abramson: So yeah,…

Will Abramson: that did just remind me there's a couple more slides which
maybe I'll just just whiz through because I don't know if we speak to that
exactly. yeah, I mean I have published version one, So the next steps, I
mean, this is the start, right, of I guess DCDS and legendaries, like we
call it a publicity push. we've been working on this for a long time and we
think we're ready to start talking about it. That's why we're on the CCG
today. We are going to be doing a Rubric podcast. We're open to other
podcastes. We're going to go to the Atlanta Bitcoin conference and talk
about it there in the Bitcoin community to see what they think.
00:40:00

Will Abramson: and some of us will be at IW and a few of us will be at TAC
too. So in fall we're trying to start talking more publicly about this
thing that we think is pretty cool and is what as you said manu had a lot
of work and it's not quite version one but we're close to there. so we want
to start publish talking about it. but certainly I think there is some path
where we go okay this needs to not live under DCD it needs to live out
somewhere somewhere else so other people feel more able to contribute to it
and it has IPR around it I think my last slide is just we'll share these
slides so this is just really for people who are interested to explore at
their leisure some of the implementations that we have developed I guess
the only caveat I will say is the spec is still under some iterations so
some of what I have walked

Will Abramson: talk through today may be subject to change and in the
comments in the text I have tried to flag that I mean I didn't go over it
in the chat but I have tried to flag where changes are okay let's see how
many combinations I'm going to try it so if there are questions please jump
on the queue I'm just going to so what we're doing now is we're just
constructing the sidecar data for this beacon signal so we're saying okay
this is the signal

Will Abramson: signal that we just created. But to validate this signal, a
resolver is going to scan the Bitcoin blockchain using that Bitcoin address
and they're going to find the signal. But the signal only contains 32 bytes
of data that commits to the update. We need to provide the resolver with
the actual update that they can then validate against the beacon. And if
they can't find this update, then they have to throw an error because they
need to be able to process beacon signals for all updates. So that's all
we're doing. We're just priving the update payload. In some cases like the
sparse Merkel tree, we'd have to provide a proof pass too. so this is
something that is subject to change probably how we construct the signal
the sidecar data but that's not that relevant for now. We're just
constructing some payload that is going to be defined by the spec. and then
this is our resolution options. Right? So we're just defining this new
property sidecar data.

Will Abramson: We have the initial document which we already had and then
we have the signals metadata which is just providing the metadata required
for each signal. And again we are just going to resolve this. Is it still
in there? no. Hang I'm on my laptop. I'm not such a good Mac user these
days. So, hang on.

Will Abramson: there an error. All right. So, it didn't work. It's probably
my construction of this sidecard data object. In some ways, I think I've
constructed the sidecard data wrong and it's basically saying we're
expecting IPFS. So if the resolver thinks it doesn't have the sidecard data
necessary for some object, right, like some beacon signal for example, it
can try to convert that hash into an IPFSC and query IPFS to retrieve that
data. So we support both modes.

Will Abramson: But obviously Marxus' implementation does not have guard
data I mean IPFS running. So it's just saying we can't do that. so yeah I
didn't get to test this because I didn't want to publish the transaction
first. I probably just constructed this object wrong. So let's just leave
it there. I feel someone here.

Will Abramson: I'm going to stop sharing unless anyone wants to Yeah.

Harrison Tang: Ana, you can go first.

Manu Sporny: No, go ahead, Trison.

Harrison Tang: Yeah. I'm just curious as well where does the IPFS fit in?
is it where the bit document is hosted or something? why do you need IPFS?

Will Abramson: It's exactly so IPFS fits in for when you don't want to use
sidecar is useful, but there are some situations where you want DID to be
able to be resolvable DID document without any additional information.
00:45:00

Will Abramson: So in that case you can host the information that the
resolver needs to get on IPFS and then as part of the resolution the
resolver can query IPFS to retrieve the updates and…

Will Abramson: then validate them against the beacon signals instead of
retrieving those updates from the resolution options on the side data.

Harrison Tang: Got it.

Harrison Tang: So is IPFS an option or is like you have to preset it
beforehand whether you want to put it into site or IPFS

Will Abramson: It's an option for controller and every DID document to
decide do you want to host your updates on IPFS or…

Will Abramson: do you want to keep them private to yourself and provide
them as needed? I saw Joe on maybe Joe has some more context.

Joe Andrieu: Yeah, my nuance was the IPFS or…

Joe Andrieu: the sparse Merkel tree options are going to be bundled into
your particular aggregation for a particular set of updates. So you might
join an aggregator for a month, you might join them for a long period of
time, however many updates they do. That particular approach will be of a
type. and so you can as a controller say hey I want to store this on IPFS
and you find an aggregator who is supporting that. so it's both the
controller and the aggregator sort of need to agree and…

Will Abramson: yeah, man.

Joe Andrieu: then the resolver will be able to get the data because of that
agreement.

Harrison Tang: valid thing. I'm on you.

Manu Sporny: Yeah. the question I have is coming from kind of a can you
create issues where someone can be silenced like their dead can be
silenced. So I think you've mentioned that there can be multiple entities
involved in the creation of a beacon like an N byN signature scheme that
creates a beacon.

Manu Sporny: And I've heard, mention of aggregation. I'm guessing the
reason for aggregation is to kind of lower costs.

Will Abramson: Mhm. Yeah.

Manu Sporny: So the general question is I'm pretty sure this will work on
the Bitcoin mainet, I'm presuming that's true. when that's the case, I
think you're saying you'll have just this wonderful open choice of, who you
want your aggregator to be. you don't have to go with one. it's your
choice. and I'm wondering if, those aggregators, they basically roll up a
bunch of, transactions or if you're saying an aggregator is just for a
single bitcoin, just for a single did document. So, I guess the question is
kind of like is there what is the cost? It does aggregation mean you can
actually actually aggregate 50 different DID documents together or is the
aggregation more of the versioning?

Will Abramson: Yeah, those are great. I mean, because I didn't explain this
story. the first thing I would say about being able to silence it is
strongly recommended that you have a singleton beacon in your DI document
so that if the aggregation fails the aggregation beacon or you can have
multiple aggregation beacons but if they're all failing you can always go
to the one of one spend right there's always a back door to change and then
through that spend you can change your aggregators. the second thing is
aggregation. So we have this concept of A beacon cohort is all of the DID
controllers who are using that beacon to aggregate updates. So that beacon
cohort we haven't fully tested and demonstrated but we would like that
beacon cohort to be tens of thousands ideally of d controllers but that
does require coordinating a multi-party cryptographic operation across
those tens of thousands of participants.

Ryan Grant: Okay.

Will Abramson: The aggregator itself is an untrusted party who's just there
for coordination purposes. they are going to, be the coordinator that each
did controller, each beacon participant is sending messages to and
receiving messages But because in the participants in the cohort, right,
they have what they have to partially sign and authorize the beacon signal
before it can be broadcast onto the network. So they get to see okay this
is the beacon signal the aggregator is proposing and it contains the update
that I'm expecting it to update for me.

Will Abramson: Okay, that's great. I'm gonna partially sign that, mucus 2
thing and send it back. And so, how that works at scale, we need to do some
more tests and experiments. But we believe it could be possible, It's just
software and software is going to do these checks manually and coordinate
them as Ryan.
00:50:00

Ryan Grant: Yeah, I think that it's definitely an area of open research and
it's the area of research that we wanted to get to and we're very close to
having enough software that we can show people that this is the area of
open research.

Joe Andrieu: Excellent.

Ryan Grant: There's several techniques that we can use. one we could
complicate our signal update mechanism to be multi-transaction. We can
delegate with some zero knowledge proofs various capabilities regarding the
transaction. So you could delegate maybe your part of the proof to a
guardian that is you believe is going to be more reliably live and
available online than you are. And there are possibly other techniques as
well. And then there's the fourth category of research is changes to
Bitcoin's op codes that would blow this wide open. So there's lots to do
there. Thanks,

Will Abramson: Yeah, I guess I would just add where we're at is for these
aggregation protocols, we have figured out the messages that need to go
backwards and forwards, right? we have an understanding of that to
coordinate these protocols. I have spent on Signet like an N ofn I think
with five participants but it's certainly just creating the sort of
software that is going to be able enable that to be coordinated at Harrison

Harrison Tang: Manu, you go first. I have a different question.

Manu Sporny: No, my m's different as so, this question has more to do with
the usage of Zcaps. I noted one of the things we're trying to consider is
whether or not we need JSLD at all for Zcaps. usually when you have some
kind of serverbased scheme, JSLD doesn't really make a lot of sense
because, the place that you go to invoke the authorization capability is
the same entity that gave it to you, So you go to a server, you're like,
"Hey, I want to be able to do, something on your server." And the server
says, Here's a capability that you can do it with and then you can delegate
and invoke and whatever, right?" So in that case, JSON LD doesn't make a
lot of sense because the only language you have to speak is that of the
server.

Manu Sporny: You have the original reason I think we decided to go with
JSONLDD which is when you have a decentralized system and there is no
central server you need to be able to signal…

Will Abramson: All right.

Manu Sporny: which language you're using right the extensions the things
that you allow to be delegated and all that kind of stuff kind of you need
to signal that in the cryptographic object itself but I don't know if
that's true I'm guessing if we removed the JSONLDLD bits of Zcaps would it
harm your usage of it or would you just kind of be like doesn't really
matter all that much to us.

Ryan Grant: Can I? Yeah. manu and will I just want to reframe a tiny bit
and then hand it back to Will. But we have been considering some of these
same idea questions looking at where JSON LD is getting used and kind of
what the attack surface cost of is in having JSONLDLD and really RDF code
sitting around…

Will Abramson: Ryan.

Phillip Long: Okay.

Ryan Grant: if it's not critical

Ryan Grant: for some part of an algorithm. And the thing that comes up
again and again is we are defining our did method and…

Joe Andrieu: I think in this context at the start we have the did BTC-1
spec as sort of defining this universe of…

Ryan Grant: it's kind of up to us to find the next capability that could
make it work.

Ryan Grant: And so now I'll hand it back to Will and I think Joe might have
some thoughts on this too.

Will Abramson: Yeah,…

Will Abramson: I'll let you go. That's fine.

Joe Andrieu: what a beacon is and what a beacon could be. So it in fact
defines our first couple of beacons. we expect that in the fullness of time
there will be other aggregation protocols. maybe they're postquantum or
maybe they're in a quantum computer.

Joe Andrieu: there's just a whole world of opportunity about how we might
change that aggregator algorithm and if we change that algorithm that may
suggest that we update the ZCAP representation using JSONLDD so that sort
of extensibility is still possibly there right now we aren't really using
it…
00:55:00

Joe Andrieu: because we're just starting with the 1.0 the spec.

Will Abramson: Yeah, the only thing I wanted to add is,…

Will Abramson: I think you make a good point or you highlight a good point.
I think it's interesting about how we're using Zcaps, right? We kind of
define this abstract server that is just every resolver is the server that
is evaluating whether this actually is an invocation of a capability to
update the DIB BTC1 identifier that is resolving and in that way we're
anchoring the authority to update that identifier to the DI document of the
identifier.

Will Abramson: that's

Manu Sporny: Yeah. Yeah. Yeah. all that makes sense. I guess the general
question is we've seen the ZCAP stuff. be of interest to the folks working
on kind of AI and AI systems and AI delegation. you guys are using it for a
really interesting use case here. I know Dimmitri also wanted to kind of
move it forward on the standards track. It doesn't have a home yet at, W3.
We don't know quite where it would go. And I'm wondering how willing to
change or how updatable it might be if you guys bake it into BTC1. this is
more me just kind of like openly ringing my hands about what we should do.

Manu Sporny: it sounds like there use cases where you don't really need the
JSONLDD extensibility and then in that case minimize just use JCS for
canonicalization. you use a spec to define a very static set of operations
and attenuations and things like that. and that would work a minimal
version of it. And then there's this maybe remaining 10 or 20% of use cases
where you want the expression language to be a bit more decentralized than
being at a particular server or in a particular spec. so I'm trying to
figure out is there enough momentum for us to start ZCAP global
standardization.

Manu Sporny: I don't think that's quite true today, but it might be true in
6 months to a year. And then I'm wondering, of the design space, how can we
simplify it to increase the chances of, interop and simplicity to implement
and as Ryan mentioned, tighten up some of the attack surface and things
like that. So just openly wondering and was just really interested in your
experiences with it and…

Manu Sporny: and how that might impact the future of the ZCAP spec. Thanks.

Will Abramson: Do you want to go around?

Ryan Grant: Yeah. I would say the very short answer is we are not strongly
committed to it right now and…

Ryan Grant: we don't have a very clear use case that is going to require it
in the future. So we have more flexibility than not.

Will Abramson: Yeah, I think I would add that the key use case that we
wanted to explore, the thing that we want to explore is this, delegation
and attenuation, but currently we haven't really explored that deeply,
right? We don't have a language by which we would define, this is me
delegating and attenuating this capability so that, Ryan can add a service
to my document.

Will Abramson: But we think that is a really nice feature to have more
flexible control over a div document but we haven't fully t what that means
and how we use the caps to do that.

Harrison Tang: All I'll end it with one last question since we only have
three minutes. so I'm just curious about the resolution time. because I'm
not familiar whether sidecar is fast or…

Harrison Tang: not, but IPFS is quite slow, So what's the speed performance
for the resolutions?

Will Abramson: know I don't have numbers for you…

Will Abramson: but I don't think it should be slow right the slow part
would be if you had to scan the Bitcoin blockchain from the start but what
we recommend is that you use a blockchain indexer so you can just query
that indexer to

Will Abramson: find okay I'm looking for this address spends from this
address find sign all the spends from this address put them in order start
processing them and as you're processing them you're basically checking
this 32 byt and finding the update which either is in your sidecar data
provided through resolution option or you're querying IPFS I don't think
that should be
01:00:00

Ryan Grant: And maybe to add on that Harrison, we have not done speed tests
on IPFS yet for the amount of data that we're carrying around. There are
two things we should do those speed tests and we are honing in on the
simulations required to understand exactly how many bytes are being
transmitted by sidecar and in a worst case scenario if you're on a slow
IPFS node or something you can choose yourself to hand it over to the
resolver in sidecar and that may be a faster data transfer option for

Harrison Tang: Got it. So what's the target audience? Is it mostly for kind
of users? Is the did BTC1 mostly used for basically real users or is it for
other things? Because for example, if you're dealing with devices and
systems, I mean you need instant resolution, right? So I'm just curious.
Yeah.

Ryan Grant: I mean I think the answer is going to be what the data allows.
Each of those devices is going to understand their own requirements for
instantaneousity whatever.

Will Abramson: Yep. Cool. Just

Ryan Grant: And in the meantime, it's for people who want censorship
resistance.

Harrison Tang: Thanks, Ryan. And thank you, Will, for a great presentation.
Yeah, this is a very good presentation as well as a great demo. I love
demos. And then lastly, a discussion, too. So, big thanks.

Ryan Grant: Thanks everyone.

Harrison Tang: right, this concludes this week's CCG call.

Phillip Long: That's it.

Harrison Tang: Have a good one. See you next week.
Meeting ended after 01:02:16 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*