Speaker 0 00:00:00 <inaudible> welcome to the rubric. I'm your host, Joe Andrew I'm Erica Connell. Speaker 1 00:00:12 And I'm Eric shoe Speaker 2 00:00:14 Today on the rubric we interviewed the creators of did BTCR Kim Duffy, Christopher Allen, Ryan Grant, and Dan Pape. Speaker 0 00:00:23 The only other question anyone might ask themselves is why would I not use BTCR didn't Speaker 2 00:00:32 The rubric helps you understand the technologies behind decentralized identity, including decentralized identifiers, also known as did or did, did documents and did methods decentralize identity enables robust identity-based services without dependency on a trusted third party. Instead of being tied to a central service like Facebook or Google, or the department of motor vehicles, DIDs can be created by anyone anywhere and be used for any purpose. Did methods are the magic ingredient that gives DIDs their flexibility before creating any specific? Did you first choose a did method, which determines how you create, read, update, and deactivate a date of that method once created each day, it includes the name of its method in the identifier itself, so that when you use the, did others know how to retrieve the associated did document that contains the cryptographic material for secure interactions, different did methods use different underlying mechanisms for different performance, security and privacy? Trade-offs this show, the rubric reviews different did methods using a common set of criteria, comparing apples to apples. So you can make better decisions about which did method is appropriate for your needs. Speaker 2 00:01:46 On the show. Today are the creators of did BTCR, which uses the Bitcoin ledger to create DIDs without requiring any changes to Bitcoin. We'll talk with them about the latest on BTCR and what's next first up we have Kim Hamilton, Duffy, the architects of the digital credentials consortium and our role at MIT open learning. Her focus is on interoperable standards-based credentials and decentralized identity solutions. She's a former co-chair of the W3C credentials community group, which helped create both the verifiable credentials and decentralized identifier specifications. Kim also drove the initial implementation of the BTCR did method. Next, we have Christopher Allen, a pioneer in internet cryptography. He's the coauthor of the TLS security standard that secures most of the Internet's traffic today. He authored the 10 principles of self sovereign identity. Given that name to the SSI movement is also the founder of rebooting. The web of trust. Speaker 2 00:02:46 Christopher is principal architect of blockchain commons working on open infrastructure for digital assets and identity wallets. Next Ryan Grant, a computer scientist and philosopher who decided that freedom was critically urgent in the world today. And it was fortunate enough, thanks to preparation while following that calling to discover the further critical dependency of self sovereignty with respect to internet native digital identity, his main focus is on making sure that the best decentralized solutions available for self sovereign identity are available for Bitcoin holders. Finally, Dan Pape, a software engineer who's been working on identity systems for more than 10 years and has spent the last three years working on decentralized identity projects with Ryan, with Kim and with Christopher. Dan is also a co-author of the TX ref specification, which is a data and coding scheme. It used by the BTCR did method. Welcome to the show. Thank you. Hello. Thank you. Let's start with the fundamentals. What exactly is BTCR Speaker 3 00:03:51 BTCR is the Bitcoin reference did method, which means it is the first did method that is custom built for the, for the Bitcoin blockchain it's goals. There are to be really simple and really censorship resistant Speaker 4 00:04:13 For me BTCR was the first did method that exemplified a particular approach to did methods that was a much more oriented to taking advantage of the cryptographic properties of the blockchain that it was running on. Speaker 5 00:04:37 And for me, I'll add that it's a very transparent and open demonstration of a decentralized identity methods. It, it adheres to the principles and goals of decentralized identity. And, and I think the area that I've been most excited about is I think it's a very useful introduction to the mechanics of decentralized identifiers. And for that reason, um, it's useful for educational purposes about decentralized identifiers, how they work. Speaker 2 00:05:07 So BTCR is based on the Bitcoin blockchain. Um, how does it actually do that? How does it work? Speaker 3 00:05:16 Well, let me go back Speaker 4 00:05:17 A step, which is in 2014, I became aware of Bitcoin in particular. I had seen it, but hadn't, um, uh, trusted or bought into it. And then, uh, I learned about one particular feature and I went, wow, this is powerful. I need to get involved. Uh, I I've missed out for the last, uh, few years. Uh, and one of the very first things was that I was trying to solve two old problems. I'm the, the, uh, coauthor of the TLS standard and revocation has been a disaster, uh, uh, SSL and TLS for, uh, you know, almost 20 years now. And here was this very early blockchain. And, uh, they basically could, uh, in effect revoke UTX. So in less than 10 minutes worldwide. And that just kind of got me really excited. And, uh, so I did this little hack called the revokable self signed TLS certificate hack, where you put a Bitcoin address UTX in a, in a TLS certificate. Speaker 4 00:06:31 And, uh, you know, every time you use that TLS certificate, you would check to see if that was a valid UTX and every Bitcoin node in the world has, uh, an up-to-date version of that. And as soon as it's spent, you assume that the certificate is invalid. And, uh, as a, you know, just as a proof of concept of how to solve revocation, uh, better than had ever been done before and using an independent channel and whatever, uh, said to me, there's some role other possibilities in the Bitcoin space other than money. Um, so later when we did the Oasis SDI strongman and which was a predecessor to the, uh, did, uh, requirements, and then also, uh, the D PKI paper that from the first Arwan, I really kept that particular trick in mind. And it became real evident that, um, that could be a key part of an architecture for a did method that uses Bitcoin. So for me, the, you know, the root feature was the ability to, uh, do revoke, uh, a did, and then we figured out a variety of other methods, so that, that revocation could alternatively be a rotation to a new key. Uh, and that's when we started the zero.one version. Speaker 1 00:07:56 So before we move on, cause I have a feeling this will come up again. Uh, could one of you give a brief overview of what a UTX is in the Bitcoin world? Speaker 3 00:08:08 Sure. UTX, that means unsigned transaction output, and the elements in a block in the blockchain are transactions. Each transaction has various outputs, uh, often one, and these are collected in a database, uh, that the Bitcoin program knows how to find easily. So these are almost instantly available. Speaker 4 00:08:40 Yes. So a UTX, so is an unspent transaction output. Uh, and what's really significant on Bitcoin is that in effect it's an unsolved puzzle. You don't know exactly, uh, you know, what it is solve that puzzle. And once it's been solved, it's now been spent, Bitcoin has to track lots and lots of these, uh, out there. So every time you have a full node, a full node has a complete list of every puzzle that is still pending in Bitcoin. It also in order to do that, it has to have all the transaction history and, and blocks of transaction history. But in the end, what, you know, Bitcoin core and the other apps care about are these, uh, unspent puzzles, uh, that hold coins. Uh, so, you know, UTX is a very different architecture from, uh, the sort of the <inaudible> style, uh, transaction, uh, model where, uh, you actually have every transaction. It just basically moves something from one account to another, you know, they're not puzzles on, uh, on an area. So it's a, it's a very different approach. Speaker 5 00:09:52 So to tie it back to the original question, um, in terms of how BTCR works in decentralized identifiers, it's decentralized identifiers, uh, there's uh, two entities that, uh, that you think of there's the identifier. So the string is, did Colin method, colon, you know, detailed identifier, um, and then there's the dig documents. So with BTCR that identifier actually encodes the transaction position. So, so that identifier, uh, did colon BTCR colon, blah, that blah part encodes a transaction as a position in a blockchain index, within a block. And then some point we may, uh, bring in the actual transaction out point index. So in, in BTCR V 0.1, and we'll get into our weird numbering schemes in a bit, but 0.1, the did document could actually be generated entirely from that Bitcoin transaction. So you use the identifier to look up the transaction from that transaction. Uh, you could, uh, generate this did document, including things like what are the expected signing keys and things like that. But we also supported another mode or support another mode, which is that in the opera return or the output, um, you know, data position of the Bitcoin transaction, it could point to a did documents. So that's describing how it is in a V 0.1 in, um, we'll, we'll talk about some other versions later. Speaker 4 00:11:39 Yeah. Another way to, to, to, uh, break it apart. Is there are a number of different things that make, uh, did you know, how do you create, uh, did, um, once you've created it, how do you, the public mucky material that is associated with that did so that you can basically bind the did to, uh, other things, uh, and then ideally you want to be able to, uh, at minimum delete it to say that it's revoked. Uh, and of course, uh, because some, the IDs are more expensive than others to, to do. Uh, it's also really nice to be able to update them. So that's what is called crud for BTCR zero.one. You basically are taking an old transaction that's on Bitcoin of a particular type of legacy type. And one of the fortunate things about this, like a legacy type is that the, the public key is already in the transaction. Speaker 4 00:12:40 This is a pay to a public key hash. When you, when you actually spend one of those UTX owes, the resulting record on Bitcoin has nice and conveniently a public key that we can use to basically show, Hey, the, the, a holder of the private key that made that public key still has that private key and consign other documents. So that was the basic create operation was we could, uh, go to any full node, uh, that was out there and provided that it had an index of all the spent transactions. Then we could basically recover this key from there. We wanted to be able to delete it. We use that revokable, uh, uh, hack from before. So we basically said if the zero, uh, output from that transaction is a, uh, spent UTX, XO disregard this, and it would be assumed to be revoked in less. It had an opera turn. And in the case of the opera return, the opera return could point to either a small URL or an IPFS hash that could say, well, wait a second. We didn't really mean to revoke it. We're wanting to update it. We're wanting to use new keys, uh, et cetera, et cetera. And that basically allowed you to do all the crud operations forward. Speaker 2 00:14:08 So I want to walk through a little bit of the flow. I heard some elements of it from both Kim and Chris. Could someone walk me through how one creates a BTCR did, and then later after some updates to it did document, how do we get to the current date document by things like following the tip, uh, which we, you know, no one's used that term here, although you just talked about it a little bit, Chris, I've just, if we could get a nice walkthrough of, while you look up the original, original UTX, so you follow the tip and then you go, dereference reference your Opry turn to get your IPFS file, whatever the correct sequence is. Can someone take a stab at that? Speaker 4 00:14:53 I'll take a quick stab, although I think, you know, uh, Kim also might have some, some good, uh, subtleties, so you, you need to have an initial transaction now in my preference, that initial transaction should be a completely stock standard, Hey, to a public key hash, because that just looks like any other Bitcoin transaction. It can't be censored. Um, and if you're lucky, you may actually have a lot of old UTX sows in the form of dust. So Bitcoin basically will ignore UTX sows that are below a certain value. So if you've got a really old Bitcoin wallet, which I have, you know, some dating back to 2014, uh, there might be some dust that was never spent there that is conveniently already, uh, got an, uh, a, uh, transaction and an unspent UTX. So in the form of dust, that's, you know, you know, four or five, six, uh, years old ever since the, uh, pay to public key hash was out there. Speaker 4 00:15:57 So that's the ideal was an uncensorable transaction that doesn't have a spent that, you know, one of the outputs is not, uh, been spent once you spend, uh, that UTX. So you're creating a second transaction that spends it. And if it has certain properties in the case of BTCR one, a zero.one, it was an opportunity. It must have an operator that operators can give additional information to allow for further following the tip. Most typically that transactions key is now available as a new key for future usage in this did. And you would then look at once again, the, the zero with a UTX for it and see if it has been spent. Uh, and basically you would subsequently walk through, uh, every transaction forward in time following the tip, uh, until you reached a point where the tip is unspent, and then you can presume that the, uh, transaction key that, uh, was used in the last published transaction is the one that is the most current for the did, and that the OPR return points to the most current did document. So that was that's the basic process there. Speaker 2 00:17:19 Cool. Thank you, Christopher. Dan, do you want to take a go with the same, uh, same flow Speaker 3 00:17:24 I'd like to hear Dan's perspective yeah. Using the libraries that digital contract design without there. Sure. Speaker 2 00:17:33 So over the last couple of years, we have created a few reference implementations of the technology needed to run. BTCR did, uh, one of the libraries we created was for the X 32, uh, data and coding specification that was actually created for, I believe Bitcoin SegWit addresses and transactions. Um, we use that in, uh, another library we call, uh, for TX ref C x-ref is a way of encoding the position of a transaction on the blockchain. As Kim described earlier, where we take the, where we take the block that the transaction is contained in, plus the index of the transaction itself, plus an optional UTX fill out point for that transaction and using those three numbers, we encode them in such a way using the back 32 encoding. And that's where we get the TX rep string, which is the major identify identification part of the dead spring or the BTCR did. Speaker 2 00:18:50 Now using all of this software together. We have another implementation, uh, called create BTCR did a little library. You can get a forget hub or a little application or the did method. And using this CA all you need is a few other bits of data in order to create, uh, did, uh, let's see, you need some sort of reference to your input transaction, as Christopher mentioned, you know, you need a ideally a legacy transaction, but I believe others will work and you need an output address where you want, uh, some of your change to go to, because what you're doing as explained before is you're, you know, we're creating a new, uh, Bitcoin payment transaction. And so you want to take a little bit of Bitcoin from your original input transaction and a little bit of it, of course, but the bulk of it's still your change to go to an output address. Speaker 2 00:19:46 So, given the input transaction and the output address, you just need to extract a few other things from, you know, at least in this implementation, you know, you're using the Bitcoin core wallet, you got to get your private key out for the transaction. And finally, the last bit of data you need is, you know, uh, a reference to something you want as your dead document. Uh, in our tests, we've usually been using a URL to a small document, you know, usually on GitHub that you are all has to be small enough to fit within the 80 characters that you can have in the op return. And so then you run the app and it processes all this data together, and it talks new, uh, it point core, they have running somewhere that you have access to. And as long as everything is okay, it will deposit that transaction into the blockchain. And once it gets confirmed, then it tells you what your new dead spring is. And you can use it from there. Speaker 5 00:20:52 I'd like to add, um, the Bitcoin Testnet mode was absolutely critical for this, because as Dan was saying, when you're experimenting and running directly with Bitcoin script, it's easy to get that wrong. So we, uh, fortunately only lost a lot of, uh, oh yeah. Yeah. Speaker 4 00:21:14 I think as, uh, as again yep. Recognize that the only other sort of did method that was in existence when this started was on a very, very simple non proof of work blockchain that had very few cryptographic features and was in effect just a, uh, you know, a federated, uh, chain. So it was really the, you know, early, early, and it did all the things that we wanted to do it did, you know, all of the crud operations and it did them cryptographically, and it was able to take advantage of some of the strengths of the Bitcoin blockchain at that particular point. Uh, but it also had some of the weaknesses, some of which were not obvious back then. Speaker 2 00:22:00 Thank you, Christopher. And how did you get involved with this project, Kim? Let's start with you. Speaker 5 00:22:06 Yeah. So how I got involved, um, I was working on block certs at the time. So, um, that is a, uh, basically an open badges schema credential, like, so for certificates of completion course completion, et cetera. And what we wanted to do was improve some of the, some of the verification aspects of open badges. So we wanted to make it more decentralized. We did that by anchoring to the Bitcoin blockchain, and that was to address some aspects of centralization during verification. One thing I wanted to add is that in that we were already using something that Christopher alluded to, you know, as part of BTCR, which is using revocation semantics for spending, uh, transactions. So, um, that was a really unique thing about BPCR and the approach. And so we were also using that pattern in block certs. So opening badges used email to identify a recipient, which had some problems in terms of, you know, you may not necessarily have access to that email account. Speaker 5 00:23:15 And one thing we wanted to do was make sure credentials could really be tied to a person. And so that in fact, you could sign a statement, proven control over something embedded in the credentials. So with block certs, we extended the schema to add a public key, or in fact, a Bitcoin address so that the recipient can prove control over that identifier. However, we all know that with public key cryptography, you know, you to practice good key hygiene, you want to be able to update the key for longevity of credentials. That was really where I was thinking heavily about this problem. And so I realized in that I stumbled into this cast of characters at a rebooting web of trust in Paris, which all sounds very romantic right now, but so they were talking about the great thing would answer all of my problems. So it was about four years ago, they were talking about the central identifiers and it just sounded too magical for me. Speaker 5 00:24:17 So it was this magic that you could prove control over, and it was really hard to separate what was going on. So to Christopher's point, all of the implementations that people were talking about at the time, it was really hard to figure out what role the blockchain played, um, because they were using maybe fit for purpose blockchains. And so it was just hard to detangle. And so that furthermore, there were magical people like guardians and stewards, making decisions about, you know, what it's added and updated. And so it also did very inscrutable and not transparent at all. So, um, uh, at rebooting web of trust Paris, I heard Christopher and Ryan talking about BPCR and that was the first one where I heard it and I thought, oh, that makes sense. And it wasn't tied to a fit for purpose ledger. It was a public ledger, you know, one with, um, that's been very battle tested. Speaker 5 00:25:14 And I think the other thing was that it was very demonstrably under control of the individual and it minimized the bloat or extra infrastructure that all these other methods, um, uh, were using. And then, so finally, you know, still being afraid to trust something that I couldn't see, I wanted to get really heavily involved in the development to actually prove it out because I realized that it could be really informative for the emerging did, uh, specifications, including things like did resolution. So I think that what was really important with having a nice, simple, um, very approachable implementation, like this is, we really helped inform other people about how does work and how every aspect of it, where, you know, how did resolution works? Um, so yeah, Speaker 2 00:26:06 Ryan, how did you get pulled into the BTCR work? Christopher invited Speaker 3 00:26:10 Me to a recruiting web of trust. And when I showed up, there was this group over in the corner that needed a scribe, and I had no clue what they were talking about, but I was capable of scribing and like writing stuff on the whiteboard for them pointing, saying what you mean this or that. And, uh, this turned out to be the decentralized identifier group that, uh, for this new idea called decentralized identifiers. And, um, because of my skills, writing things, which are not very special, I got the opportunity to learn what was going on. And I thought it was cool enough to keep contributing, Speaker 2 00:26:58 Uh, the Boston rebooting. Speaker 3 00:27:00 No, that was, Speaker 5 00:27:04 Yeah. That was the one. Cause you had talked about it before you knew about it before Paris. So it was whatever before that. Speaker 2 00:27:11 Yeah, that was New York. Dan, how did you get involved? Well, truthfully, I had not heard of any of this stuff. He DIDs or rebooting web of trust until Ryan reached out to me about three years ago and told me he was involved in something super cool and wanted to know if I was interested in helping out with some programming and I dove in and haven't looked back, I think I've been to three rebooting web of trust now, but yeah, it's been a really interesting learning, all this stuff, seeing, you know, especially like, you know, how the did spec has been moving through all of its work and different stages through the W3C. And it's just been a interesting working on this project for Speaker 4 00:28:04 Me. Uh, why am I still connected to BTCR et cetera, which is that to a certain extent, the D IDs have advanced a lot in the last five years, uh, since they were, you know, at least conceived in name and four years since, uh, the requirements were done and three years since the, um, uh, you know, people actually started being able to actually use them, but these sort of trust minimized forms that BTCR is an exemplar, uh, have not made the same progression as some of these fit for purpose forms. And it's fine. You know, I think I, I value the fit for purpose forms. Uh, they serve a different purpose in the did rubric. Uh, they can do some things that we can't do for instance, I don't know that BTCR will ever be cheap enough to be for, you know, a refugee who has no money at all, nor do I believe that, you know, it will necessarily scale up to billions of people. Speaker 4 00:29:08 Um, Bitcoin can't handle that kind of load, but for what it does, nobody does better, which is, uh, censorship resistance, the ability to not have somebody say you can't have a did. And, uh, you know, some of the other properties of Bitcoin can be leveraged as well. So, um, I'm wanting to see, you know, that side of the did architectures, uh, advance forward because they have a place. This is, you know, part of the, the big thing that happened in, at the, you know, after the UN event was, you know, there were people who were pushing up pushing for one did method, rule them all. And, uh, you know, my argument from lessons of SSL TLS was no, you need to have different, uh, cipher suites and TLS to allow people to, uh, to both collaborate, but also compete. And we needed that same type of thing for did were different approaches, different styles, different community needs could be addressed and a great way to do that. Was this method, uh, style of, uh, things in divs doesn't make it more complex. That means what 97, some odd methods in theory right now. Um, but that's just proposed not actually fully implemented and, and much less deployed. Speaker 2 00:30:28 Christopher, can you share with us a little bit about what was happening at the time that uh, BTCR came Speaker 4 00:30:34 About? Yeah, so, you know, a little bit of, you know, the, the, the history here, um, you know, a number of people at the first rebooting said, Hey, we need a decentralized public key infrastructure. And this included people from the Bitcoin community, it included people like metallic from the Varian community, et cetera, et cetera. Uh, and they published that in the first, um, uh, first rebooting when we met in, uh, New York city, uh, six months later, uh, just after a meeting at the United nations, uh, there was just a lot of energy. There was a really good group of people there, but nobody quite knew how to do this D PKI and, um, Manou Sporney and his team from digital bizarre had coined this term called the decentralized identifier, but it used a fit for purpose type of approach for it. And he was confident it could be done better. Speaker 4 00:31:29 And because we have kind of the right people in the room, we were able to kind of merge their approaches of using Jason LD and did documents and things of that nature with, you know, uh, you know, BTCR proving that it could be done with a public blockchain and not, you know, one of these more federated, uh, uh, you know, I'm not saying there isn't value to Federation, but it's, um, you know, it has its limitations. So the, um, uh, you know, it was bringing all these people together. And as I recall, you know, Ryan stood up and basically said, uh, you know, Hey, all scribe. And he, because he understood Bitcoin, but also was brand new to this whole thing. Uh, he was also able to bridge the things that, uh, Manu and some of the people that were in the W3C side of the work wanted to bring to the table. Speaker 4 00:32:23 And, uh, that's when we define the requirements for what a did was, we didn't completely spec it, but we kind of removed a bunch of different options, but it wasn't until, uh, Kim joined us and in Paris that we really, uh, we're diving down and getting, you know, getting down the details, we kind of napped and sketched all this stuff. Um, you know, there were there all kinds of drawings and our old, uh, rebooting a web of trust notes, uh, of how we thought, uh, BTCR might work. Um, but actually doing it with real code, you know, him sat down, listened to us and, you know, really kind of held us to the grindstone to get the little details down. And there were lots of little confusing details. And so it was great. And then she did, uh, you know, the very first, you know, real test net implementation that, uh, that functioned. So she was the lead on the specification and that initial reference implementation and, and, uh, that really made it take off Speaker 2 00:33:29 Very cool. But I think with that, we can move on to our next section, which is all about the challenges. So we've, we've given the background of BTCR. We have talked about our cast of characters. What are the challenges and the conflicts that have come up as you've brought this, um, technology from an idea to reality? Speaker 3 00:33:48 The first one is scalability. The worry, I think, is that nobody's going to want, did meth, and that costs $15 to update. And of course, $15 for one person getting, getting into the next block of the chain is 25 cents for someone else who can wait for however many weeks, they want to, to make a minor change in key material. The challenge is to make a more peer-to-peer particle, and we think we know how to do this, Kim, what's your take? Speaker 5 00:34:23 Well, I'll talk to some more practical concerns. So scalability cost is, is huge, but practically I think, um, and I'll touch on why we call it. The 0.1 is, you know, we were all hobbyist, no one was paid in the making of the method. And so I think we, we had these tensions of, you know, we wanted to build something, you know, something that's usable demonstrable at the same time. I think we're very aware of, uh, the limitations and, you know, we wanted to take advantage of privacy enhancing features and then throw in on top of that, the fact that the did spec was and still is a moving target. So that made it really, uh, I mean, every aspect of it is a moving target. So I think we did a pretty good job. One of the rebooting web of trust, we, you know, Penn dev, we penned each other down and said, okay, what, what can we do to have a comfortable in VP and to signal that we wanted to call it a 0.1, meaning only use some tests net don't use in production. And so the current BTCR spec is still a snapshot of what we thought was easily implementable. And I think, you know, we've roughly in terms of the reference implementations, I think they've mostly preserve that. Speaker 4 00:35:43 I think there was a tension, you know, part of what was going on was of course, verifiable credentials, uh, took a few years to, to wrap. And we kind of had this dilemma, which was, uh, if we were going to use the URL form in the opera returns, that meant that the did document on the other side needed to be signed. And, you know, at one point it was just going to be a verifiable credential because that was moving forward along. And then later the did group said, no, it needs to be a different thing. And for many of the fit for purpose blockchains, they didn't need to be fined. So we didn't have a really great signature mechanism. We had something to kind of worked in a hack in JavaScript, but it wasn't really reviewed code or whatever, and it wasn't really standard. So we were kind of all, you know, you know, getting a little flustered on the standard side because we didn't have the right libraries. Speaker 4 00:36:43 We're not financially compensated for doing BTCR. This is all our, you know, hobbyists work. Um, and all the attention was going to these other, uh, uh, solution spaces of did methods. So that kind of hampered us. And then there were this, the innate things as Ryan was talking about of, um, you know, the cost of transactions, this, you know, potential ability if, uh, you know, miners started censoring things. There was at one point, um, miners basically saying we're not going to do our returns. Uh, we just won't accept them. Uh, so, you know, how could we overcome that? But there's been a lot of interesting evolution. I think, uh, this whole peer to peer movement for various peer to peer did methods we can get inspiration from. I think that, uh, you know, our trust model, uh, doesn't necessarily require all Tran everything to be visible on the, uh, uh, on the blockchain. Speaker 4 00:37:42 You know, some of it can be hidden in a variety of ways with zero knowledge proofs and stuff, or, you know, just only at key points. Like I only need with many things to prove, uh, something, if a third party is involved, if it's just a private transaction between you and I like lightning does, I don't need to tell anybody about it. It's only when we want to settle and I want to now deal with a third party. You know, I need a transaction on the blockchain, so we can learn from a lot of these types of things and apply this, uh, to what we started with BTCR. Um, and I mean, I think it's part of the reason why we call the 0.1. I mean, it, it, we knew from the beginning, we had absolutely people were in the Bitcoin side saying, don't do that, do sign the contract, don't do that. Speaker 4 00:38:30 Don't use Opry occurrence, you know, don't put keys in the transactions, et cetera, the Bitcoin side. And then on the did side, we had people who were going well, we don't, you know, we can't use Bitcoin curves because it's not nest, you know, oh, we, you know, we we've written all this stuff in JavaScript, so it can run in the browser and, and Bitcoin is not really safe and in a browser. So, um, uh, we were, uh, dealing with the overall immaturity with us and our inability to, uh, you know, uh, to, to spend a huge amount of time to try to overcome these as hobbyists. On the other hand now we're kind of reaching the point where a lot of these things are reaching a level of maturity. Um, and it's time to start looking at what is the future of, uh, you know, a real BTCR that had that, you know, has all the things we wished for in the beginning, the censorship resistance, the, you know, low transaction costs, um, uh, ability to collaborate and join with other parties to, uh, uh, to build trust. And, uh, and of course, you know, do verifiable credentials and some of the other things that, um, uh, would be really valuable in the ecosystem. Speaker 5 00:39:47 I forgot about that. How many moving targets there were, I think, yeah, I don't even know if there were, did documents per se when we started. Yeah. I remember a lot of ambiguity about what to put in there. So, um, it is amazing that we persevered Speaker 2 00:40:07 Chris, you touched on both some political and, and process challenges, um, or architectural challenges. I'm curious, and I'm going to send this to your way, Dan, but what were some of the technical challenges that seemed particularly problematic when you started out that you were able to, uh, either never did solve? And so it's still an open issue or you managed to find a workaround, um, that helped advance the work. You know, when I first started working on the BTCR did project, I was initially really nervous about actually communicating with the Bitcoin blockchain itself again, even three years ago. I mean, the, the price of a Bitcoin was not as lofty as it is now, but, you know, still I was worried about who I'm going to lose some money, but, you know, quickly know you find out, oh, no, there's this test net. And, you know, you'd mess around and test that. Speaker 2 00:41:01 And then it's no big deal. However, still, yeah, I was, it, it was really nervous every time I would try a test and transmit it to the blockchain. You know, you gotta wait 10 minutes before anything even kind of shows up. So that kind of thing, it would make me a little nervous at the beginning. Um, but really technically there was not much problem, actually, it was, it was very nice using the, you know, the API provided by the Bitcoin team. Um, things just kind of worked pretty well. I think the challenge we had, or at least I had over the time we were doing this development was that, uh, TX ref our, you know, what, what we use to refer to a transaction on the blockchain, uh, the TX rep spec, you had to change a few times. Um, and every time it had to change, basically that meant that all of the test DIDs that we had already created were no longer valid and we had to update. Speaker 2 00:42:09 Um, and the reason for these changes was that the back 32 and coding, which, as I explained earlier, the TX, the users as part of what it does, the algorithm for the back 32 and quoting was changing slightly and giving different checksums, uh, for the data that was getting encoded. And unfortunately, yeah, so as months went by, um, the designer of back 32 kept changing how he was doing this check some algorithm, there were, there was a couple of times, and we're about to have to do it one more time, uh, just for, to let Kim and Chris know, uh, the checksums are changing again. And so we need to do a little bit of an update, but I would say probably the biggest challenge. We're just kind of keeping that straight and fiddling with the bits that we had to fiddle with in order to get the checksums working back and forth. That was kind of the biggest challenge, I think. Yeah, Speaker 4 00:43:11 We, we did a, an iOS app, um, that basically did the entire functionality, but we ultimately didn't release it because of two specific issues. One of which was the signing problem. Uh, we didn't have tools that we could run on iOS unless we, you know, did a shimmy to some kind of, uh, you know, hack JavaScript thing to be able to sign, uh, did documents. Uh, but then the other thing was, you know, uh, Bitcoin has increasingly been, uh, making it more difficult to get this data. And there have been proposals. I mean, it was originally SPV and then it was going to be neutrino, et cetera, that allowed us to get some of this data off the blockchain. And, uh, you know, in particular that public key, and it was just getting harder and harder. And every time we tried to do it, it was kind of changing or somebody was changing their mind or it was proposed. Speaker 4 00:44:07 And then on proposed and, and such. So one of the things that's emerged from some of the other did methods is, uh, much less information on the actual blockchain. So I'm kind of really intrigued with learning from things like did doge and that did peer to peer methods and things of that nature to, um, you know, do some of the updates and other different types of things in a more peer to peer fashion. And then there's just also, I mean, the other thing that kind of really, uh, you know, hit was, you know, Bitcoin, isn't perfectly private, it's becoming more private, we're coming, coming up with more tools to do privacy. There are other, you know, privacy oriented blockchains that are out there that do a better job, but, you know, our clients are gonna be using mobile wallets and stuff. So figuring out how to do it with tour, which is what we've, you know, we've done recently, uh, to be able to talk to a Bitcoin core server, being able to do other hacks, to, uh, be able to get the data that we need to be able to move things forward are possible now. Speaker 4 00:45:11 And they weren't really possible back then. Speaker 1 00:45:14 Uh, you've mentioned, uh, BEC 32, a few times now, um, mind just giving a 32nd overview of what that is for those that might not know Speaker 4 00:45:25 EV everything, um, on the internet needs an encoding scheme and, you know, base 64 is a classic one. Hex is another, uh, one, et cetera. The particular advantage of the best 32 scheme was that for, uh, numbers that are typically the size of cryptographic numbers, not only was it error detecting, meaning there's something you've typed something wrong, it was also error correcting. It could tell you where something was wrong and it was relatively compact and had some other things. So the properties of a <inaudible> word are used in a new proposal for Bitcoin called, called SegWit, which has since passed. And it's now a dominant on Bitcoin to encode addresses. So we were just trying to leverage the same code there. Unfortunately, the, the, the shipping version of, uh, <inaudible> had a bug and the bug, uh, they were able to fix sort of briefly on Bitcoin without changing the encoding. Speaker 4 00:46:29 Uh, but it doesn't solve our problems. So, uh, there was a proposal of how to fix that bug. Uh, we said, okay, so we're going to do, you know, <inaudible> and, uh, we're gonna, you know, which fixes the bug, cause it, it does have impact for D IDs only to have Bitcoin, uh, the guy who, uh, invented this come up with even better solution to the bug and propose it, uh, for the next major release of Bitcoin and taproot Schnorr. So there are three versions of this encoding scheme, you know, one bug and two fixes for that bugs. So that just caused some headaches for us. And we have to adapt. Dan, did you have something to add? Speaker 2 00:47:13 I wish we had Chris's explanation of that before I was talking about the challenges that I faced, because the challenges I was facing during my implementations were based on what he explained better than I did, which was the, that the 32 M bug that was found, uh, or the back 32 bug that was found was fixed twice. Um, you know, over the months we were changing the way we were outputting our check songs based on these fixes. And now, as I mentioned, we have a hopefully final fix, uh, coming out, uh, this week, actually that will contain the very latest version of this back 32 algorithm. Speaker 3 00:48:01 I would add to the challenges. We spent a huge amount of effort on quality assurance and trusting our own code. This is, this is Bitcoin software, and we are using a huge amount of not only unit tests, but randomly generated tests. Basically we're fuzzing our own libraries. And this is, this for me, was, uh, a big learning experience in software engineering to, to see it all come together. And we found some stuff through that. And, uh, it's been nice. It's felt good to have that back there and it's been worth the time that we spent on it. Speaker 4 00:48:44 Yeah. I'd like to speak a little bit to what Brian's been doing there and how hard it is. So basically the W3C standards are split between a more legacy Jason web token world style of doing cryptography and Jason LD, which has some very different assumptions about how, uh, data is leveraged and signed. But unfortunately, uh, though there's been a lot of work in doing security reviews of Jason web token stuff over the last decade, I will say some of the biggest bugs in cryptography cryptographic code were in those versions that had to be fixed. Um, and there hadn't been the same amount of work in, uh, Jason LD. So, um, it was really, really critical for us to have better tools to do Bitcoin class signing of Jason LD. And that just took a lot longer than any of us hoped. We kind of, you know, thought, gosh, this is so important. You know, everybody else will do it first. Why do we have to write it? And the reality is that for many parties who are browser centric, uh, doing a JavaScript version of it, uh, was good enough for them. And, uh, that wasn't good enough for something also has, uh, you know, digital assets on it. Speaker 6 00:50:09 Thanks for that. Kim, did you have something to add? Speaker 5 00:50:12 Yeah, one thing I wanted to add in terms of a challenge, but also a cool thing about BTCR is I think it was the first generative, uh, did methods. So I think we had some challenges and needed a lot of feedback in terms of whether it would be acceptable and how it actually works in the dead ecosystem. But I think that part is interesting because it's informed a lot of other methods, uh, like did ki and, and other ones where, you know, just taking all you need is that initial string. And from that you can, uh, generate a day document. Speaker 3 00:50:49 One of the other things that we innovated on, which was necessary because of the generator did document is we have multiple layers of patches that you apply onto the generated document to get a final document Speaker 2 00:51:07 Developing standards. Like this is both a technical and a political job, and does have this unique architecture where there's a did core specification that's been developed and hopefully soon to be published by the W3C, but each of the did methods, uh, have their own standards track if their standards track at all. Right. I don't think any of the current did methods, our standards track. So were there any sort of political dynamics challenges that weren't so much technical, but were about how DIDs and did methods, um, enable this type of extensibility? Speaker 4 00:51:41 There are definitely worse, some big advantages for Jason web token, simply because it's heavily used by OAuth and other, you know, now mature technologies for web browsers and the larger web ecosystem. And there have been a lot of attacks against it, uh, that had been addressed. A lot of things have been solved both in software code, but also in hardware implementation. So there was a real attraction to just, you know, leveraging it, unfortunately in particular for BTCR being that all of those standards also limited the curves that you could use meant we could never use any of it officially as a standard because the Bitcoin core, uh, use of sec P 2 56 K one w was not officially allowed. So there've been hacks over the years of people doing it. There are lots of people doing sec P with, uh, with Jason web token, including Microsoft and a few others, but officially it's not accepted and there's not hardware for support for it. Speaker 4 00:52:49 The, but, but for me, the final straw and the reason why I still support Jace, uh, Jason LD as, uh, as where we ought to be going with BTCR is that Jason web token is very legacy oriented around single signatures around certain kinds of assumptions about the data that is being signed and other stuff that, um, you know, can't leverage some of the privacy and anticorrelation zero knowledge, proof, multisig things that we would like to be able to leverage in the future or the minimize side of decentralized identifiers. And I just don't know how to do those in, in the Jason side of, of this. Uh, so, you know, I'm still on the camp of the Jason LD side, despite, you know, the long time that it's taken for us to get, uh, you know, good, solid as Ryan said, you know, de fuzzing and, and lots of test cases and all that kind of stuff is just hard grunt work that has to be done on, on code. Speaker 1 00:53:55 Thanks for that. Chris did BTCR what are you all planning for the future? Speaker 2 00:54:00 We've talked a little bit about some of the different versions we've had over the last year or two. The near term goal is we need to update, uh, BTCR smartboard that we have to work with the latest, uh, back 32 M revision. So the, the DIDs that we create an output for the user are, uh, validated, but Ella, the latest BEC 32 and coding after that, another thing we've been working on for a while is, uh, Jason LD implementation that we can import into the BTCR, uh, applications with creating so that not only can we let the user create a bid, but also we could later let the user verify the did document that, that did my pointing to those are the big things that Ryan and I have been working on. Kim and Chris have had some ideas of other, you know, major features to put Speaker 5 00:55:00 In. Yeah. As we talk about major version updates to BTCR. Uh, so Christopher mentioned how, um, you know, we're one of the first we've inspired some other did methods, but in turn, um, you know, we're benefiting from, from some innovations that they've introduced. So oddly did doge, uh, has introduced some useful, uh, patterns that we can actually apply to did BTCR as well. So the idea of starting with an off-chain did that can then be transitioned to off on chain, which can have some cost benefits, things like that are examples of, of what we might add to did BDCR in a feature in a bigger version release. Speaker 4 00:55:49 So, uh, I have, uh, uh, I'm going to call it the laundry list. I'm not proposing these, uh, these are largely questions or concerns or things that solve one problem, but may introduce another. But, you know, there are some, you know, some things are decisions. So I think we in BTCR zero.one, have the root identifier being pointing to a transaction. If we're going to do the did dos style of thing that has <inaudible> Speaker 3 00:56:21 Style. We been talking about it since 2018 and Christian Lundquist invented it for you port and on Ethereum, Ryan, let us, Speaker 5 00:56:32 Let us, let us have this dead doge things. So we can just talk about did dope. Speaker 4 00:56:38 I'm not <inaudible> is a lot like, you know, dose, um, it's, you know, it's half a joke, but that being, you know, so it's okay. Uh, but I think the point is, uh, the, the root identifier we're pointing to a transaction. If we're going to do off chain stuff, we can't point to a transaction because it won't be there. And, uh, you know, there are other approaches. I have some ideas around how we can point to a Ute XO or to a, a non chain, a UTX. So, and of course there's the key methods, so we we've got some alternatives there. Um, and a lot of that is going to matter, uh, be important for how we do this sort of off-chain transition to on chain. You know, when we do do stuff that is on chain, there are a variety of different ways of, of doing things that are more future-proof way back when in 2015, when I spoke to the Bitcoin core people, they were saying, please don't do it the way we're doing it. Speaker 4 00:57:42 Use assigned to contract. But for the reason why we didn't do sign the contract was that mean? That meant the public key was not in, in the Bitcoin core. It wasn't look available. You could prove that it was used in a transaction nowadays that's kind of acceptable with did methods, but back when we were doing this, you know, everybody was basically saying, oh, well, all the public keys are going to be available from the underlying blockchain. So I'm not saying we're going to do sign the contract. I'm just saying that was an early thing. Since then, there've been some proposals for things like single use seals or Lawsky has got some interesting ideas about, you know, using HD keys, uh, for sequences of, uh, revokable keys. So you can prove that the next key is associated with the, with the previous key. It has some limitations, but, you know, it's, it's some interesting ideas in the Bitcoin world. Speaker 4 00:58:38 We now have a proposal called <inaudible>, which allows you to sign with a UTX without being able to spend the CXO, which basically gives you a proof of control of the UTX self. So if we do more with the three to two that could allow us to do Jason LD signing, where I can basically prove I've got this unspent transaction output, that's out there. Why is that important? Well, right now, there are already these coins swap coin, join, uh, collaborative events that happen that are used for privacy purposes, where hundreds, and especially with the new version of Bitcoin coming out, hopefully next year, thousands of people can basically join together to do a single transaction that they all benefit from and get some privacy benefits from a, there may be a way to leverage that style of technology, these collaborative efforts that may not actually be coined joined, but may leverage some of those same blinded transactions so that we can create large numbers of did for people cheaply in, in the future. Speaker 4 00:59:44 We, the tip right now is we follow is the zero. The TX ref that Dan has been working on allows the initial transaction, not to be outputs, uh, zero, but as you follow the tip, we kind of have this deterministic method, uh, where we just follow the zero transaction that might be privacy reductive. It may have some other problems. We ought to be able to transfer you a follow any transaction output forward, um, in a chain of transactions. And there are some ideas there. One of the things I liked about TX ref was that turns out TX ref is very similar, not so much in the encoding, but in what lightning does to identify a lightning node. So every lightning node in theory could be a D D E uh, BTCR identifier. So that was kind of cool. And that leverages a lightning. It will scale as well as lightening does, which is not infinite, not billions, but certainly good. Speaker 4 01:00:46 There are some other approaches like RGB protocol that may allow us to, to do some things there. There's a lot of stuff in, you know, uh, we're using Bitcoin, how do we keep regular wallets from spending our coins? And there are a few hacks that I did that maybe others can evaluate and consider doing to, uh, sort of temporarily hide things. And finally, there's this a lot of stuff. When we moved to Schnorr with the, uh, you know, taproot Schnorr, uh, soft fork, which hopefully will be implemented in simple trial this year. There's just lots of things that we can do with blinded signatures to increase privacy. So we can do channel me and Brian, a blinding, a variety of adaptor, signature tricks, other things that I think could have a real impact on, uh, usability and, uh, and, and privacy. And anticorrelation Speaker 6 01:01:41 Awesome. Thank you for that. One Speaker 3 01:01:43 Of the next things coming up for BTCR is going to be the ability to download an app for the app, from the app store. It can serve as provider to run a Damon to share your document, and then on the address that it gives you, and then hit a button and created, created the ID and be up and running. So that level of simplicity and user accessibility has not been achieved yet, but we're going to get, we're going to get there, and it's going to allow many more people to experience experiment with this, even they can't run our existing, uh, reference helpful. Speaker 2 01:02:24 Excellent. Thank you all for that perspective on what's next for BTCR, as I believe, all four of, you know, I'm one of the co-editors of the dead method rubric, which is a framework for evaluating did methods so that people can decide for themselves, which method is most appropriate for their use case. What do you think is the most important question that someone should ask about a did method when they're evaluating it for their use? Speaker 5 01:02:51 I'll answer the ones that we use for digital credentials consortium in terms of which did methods to support in, uh, in wallets that learners use. So has to have multiple implementations. We don't want to tie to a specific vendor, uh, fully open source, open standard. We want low to minimal costs, and, uh, we desire the ability to update or rotate the, um, associated keys. But that is relaxing will if the issuer can commit to reassurance. Speaker 2 01:03:25 Very cool, Chris. Well, for me, Speaker 4 01:03:29 I think there are going to be a lot of D IDs that are going to really work well in situations where you can trust the state, the use of didg and, uh, Netherlands and New Zealand, Canada, other places that seem like they're going to have sovereign nation support for did is grant. And I li I would prefer to live in a S in a place where, you know, you can trust society and the government. And I think that's a very desirable thing to be able to support that isn't true worldwide. I have interns coming this summer. Who've lived in, uh, Venezuela have had problems with Bitcoin in Argentina and Brazil. You know, we're seeing stuff happen in, you know, other edges of the world, whether or not it's Iran or China or whatever, where you can't necessarily rely on a high trust environment. And we need to be able to have the IDs that work in these kinds of environments. Speaker 4 01:04:31 I mean, there are, there are a lot of people who need this service, uh, red cross identified that they have doctors and other emergency people that are having real problems as they're crossing borders, to be able to do business, uh, to be able to do their advocacy in these different kinds of countries and their requirements and the privacy limitations that, um, are imposed on them. And, uh, you know, in one of their papers, they kind of, uh, metaphorically, you know, raise their hands to say, you know, we, we just can't fix this problem. And I think that in some cases we can fix this problem, at least in very focused ways, but that doesn't mean that everybody needs a trust minimized did I do believe they will always be more expensive. They will always be more. And if you're already dealing with the government for something, having the other properties that regular did have of no phone home and some, you know, basic, uh, privacy requirements or whatever is really good. And I it's desirable understand, you know, back to your question on the rubric, understand what your real privacy requirements are and your real anticorrelation requirements are and understand your threat models and choose a did that matches that. Speaker 3 01:05:47 And I just want to did, that's not going to go away when some company goes out of business, it doesn't like me anymore. When did I, when I, when I, they tell me I didn't pay the bill, even though I did or something like that. Speaker 2 01:05:58 Excellent. And Dan, how about you? Do you have any questions you would suggest people ask when they're considering different dead methods following on what Kim and Chris and Ryan said, which was all good? I think the only other question anyone might ask themselves is why would I not use BTCR didn't that's awesome. But seriously now I think that was said before was good. Speaker 1 01:06:23 One of the, uh, rubric criteria is, uh, titled open participation. Right? I understand you have some comments to make about this particular criteria in related to BTC. Yeah. Yeah. Speaker 3 01:06:35 The designers of BTCR are not a closed circle. This was conceived and developed at orbiting web of trust, which is an open conference. All of us are frequent participants at a W3C CCG events and meetings inspect. As I get hub, it's really easy to open a, get up ticket, start talking about it. This is also a reference that RN BTCR is for reference and our, our purposes to be simple and available. So I think we should get a higher score on the rubric for open participation. Speaker 2 01:07:13 Excellent. I'm glad you brought that up. In fact, the evaluation of BTCR in the current did method. Rubric is currently under development with the W3C, and I encourage you to submit a poll request to suggest a change to that. One of the structural things that happens with the rubric is that those are examples. And for some evaluators judgment, they may disagree with your judgment. And so what's published in the method. We have a catch 22 in that this is one person's opinion, and unfortunately it's going to get attached to this note. That's going to be published by the W3C, and it's not really our intention as the co-editors of any of the rubric variants, right? There was the rebooting paper and then the W3C notes. It was never our intention to create a place where we are giving official ratings to the work that you know, this vast community of people who have, uh, contributed to did methods have put together. So we welcome your input, and I think there's a good mechanism for you to do so super. Speaker 6 01:08:18 That brings us to the end of this amazing conversation today. We're going to shift gears one more time and, uh, open up a moment for any shameless plug. Speaker 5 01:08:30 Well, I thought you were asking about shameless pugs, and I have a shameless plug Percy, who I recently adopted from his rescue in Oregon. And so I would like to plug Pacific north rescue or your local animal rescue shelter. Speaker 2 01:08:48 Excellent. Thank you, Kim. If you could give us a URL, we'd be delighted within the showed us. Speaker 3 01:08:53 Okay. So my shameless plug is that digital contract design has put our BTCR reference implementation up on get hub. We are fixing the license on all our stuff. Some of it was missing a licensed pilot. We noticed recently we also have our Liberty x-ref and our lid back 32 and, uh, Jason LD libraries available for both people as plus and Java. And we'll be perhaps sending the, uh, the languages even further in the near future, Speaker 2 01:09:27 Dan or Chris do either of you have a shameless plug. So Speaker 4 01:09:30 I am a principal architect and executive director of blockchain commons, which is an open infrastructure benefit corporation. So what does that mean? Our job is to try to understand where infrastructure is required for an ecosystem for a large community of, of companies, uh, in particular, in the, in the blockchain ecosystem. Uh, we all rely on wallets, whether or not it's an identity wallet or a, uh, BTCR wallet and the barium wallet, some kind of a verifiable credential, uh, storage, and, uh, there's some underlying security requirements for all of this, which requires us to have good keys, good seeds, good entropy, et cetera. And so blockchain commons has been working on a variety of technologies and reference tools for wallet developers to be able to, uh, do things like air gap communication, which basically uses QR codes between two devices, where there can't be a network attack, tore gap, uh, separation of interests, uh, a variety of other, uh, different types of approaches to security. And although these are being adopted by the Bitcoin more modern Bitcoin wallet developers, uh, today, I believe that they're relevant to anybody who's doing a wallet. So, um, uh, if you would like to participate in that, uh, we would love to have you in our air gapped wallet community, and, uh, there is a link in the, uh, uh, description of this podcast of a technology overview of these wallet tools. Thank you much. Speaker 2 01:11:20 Very cool. Thank you, Christopher. And I see Dan has no shameless plug, so I will say seamlessly plug Dan, um, just for yucks because you have shown up and been a consistent, um, implementation level contributor, and we need folks like you. Um, so thanks. You're awesome, Dan. Well, thanks. I guess if I was going to say anything, I suppose, uh, if you haven't gotten your COVID vaccine, please go do so hair, hair. Speaker 3 01:11:49 That's a good one. Speaker 1 01:11:51 And that will bring us to the end of our show today. Speaker 2 01:11:54 We would like to thank our guests today. Kim Duffy, Christopher Allen, Ryan Grant, and Dan Pape. Thank you, Kim. Thank you, Christopher. Thank you, Ryan. And thank you, Dan. Thanks also to our staff, our producer, Eric Connell, and my cohost Eric Shu. I'm Joe Andrew, and I'll thank myself because it's been fun. And I appreciate that. We get to do this for you Speaker 1 01:12:14 Guys, wherever you find the rubric podcast, please take a moment to subscribe to our feed. So you'll be notified when our next episode is released. We'll look forward to you joining us next time. Speaker 0 01:12:25 The information opinions and recommendations presented in this podcast are for general information only. And any reliance on the information provided in this podcast is done at your own risk. The views, thoughts, and opinions expressed by the speakers in this podcast belongs solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual <inaudible>.