# Raw Transcript.

So, to recap, we've had a facility for crypto request and response for a while and it wasn't adopted really by the community and we're really focused on moving things that people are actually using. And then envelope came around because a lot of people needed to solve some larger problems and we realized that we kind of needed to rethink crypto request and response for that. So we wrote some docs about how that would work last year. I think Wolf and I are very confident that it can do all of the different things that we desire here, but we need to be able to help you. We need to better understand the use cases, the specific things that you need now, give us a little bit of time to kind of future proof things. But in the meantime, we can help you get some basic use cases going. I think it'll be trivial for us to replicate at least the ability to say, hey, sign this legacy Bitcoin message type of stuff. It's the more complex things where, for instance, Jade Wallet has an exfiltration signing request. So it contributes nonces. Craig has a lot of experience with flaws in how Sign-In with Ethereum works. I'm not sure if we're gonna be doing precisely that because that has a back channel that uses web RTC. I don't know if anybody's trying to do that, but if we are, we wanna know. And then there are other things that people wanna sign where we may need, well, likely we will need to create some more UR tags and specify some binary values for things for efficiency. So that's really the topic of this call, understand the problem. We'll go back and give you some quick answers and some ways that you could deploy things without necessarily full libraries that can do all the different options. And in the meantime, we can work on things that offer the whole suite of possibilities. So-- - Yeah, our stack is basically designed. Yeah, so, sorry, Christopher didn't step on your tail there. Yeah, so I mean, our stack is obviously designed to work over, you know, QR codes of arbitrary size using M8QRs as well as over the internet, you know, the basic formats that we're working with a binary, even though when people look at you, they see text. And you know, what I'm primarily interested in is finding out what your pain points are so that we can make sure that our technology is addressing them and so to, you know, kind And also, once I understand what problems you're trying to solve, then I can make sure that the solutions we're offering are things that you really want to adopt and you see the value proposition in and not just, for example, you know, roll something quick with JSON because it's there. But I want to show a deeper value proposition. So I feel like I need to listen before I can talk on that question. So that's my first goal here is to listen. And then to talk out together how we can make what you're trying to do with things like requests, responses, sign in, things like that, that much more both technologically workable and future proof and all those things. - Craig, why don't you start off with kind of what is your immediate use case and how we might be able to help you address it. - Sure, so I'll take a step back and kind of just talk to how I see the sort of landscape with regard to the use of animated QRs, as I've sort of seen it evolve as well. So, you know, I think that we kind of began with static QRs when I was building Sparrow. I think the Spectre wallet was doing it with a fairly simple scheme, which sort of had a variety of different parts that they were then breaking up and sort of having this P1 of two, P2 of two kind of thing. And it just seemed a little bit naive. Maybe that's a little harsh, but anyway, it didn't seem ideal to me. So I was an early adopter of the UR standard. And, you know, when we were first building it in, I think that the first use case everyone was using just bytes, which I know is not what Wolf wants us to do, but that's how it was being used at the start. And then of course, I think the first major adoption by the certainly the Bitcoin wallet community was the PSBT format, which I think still remains probably the kind of dominant use case in Bitcoin wallets. It is a request and response format of of a sort because of course we're passing PSBTs back and forth and we're kind of filling them in as we go. So I think it does very well at that job. I don't think it needs to be changed in any way. The PSBT format itself is a request and response built into it. Then I sort of started looking further afield as to what are the other requirements and obviously one of the key ones, particularly if you are a coordinator wallet is you are looking to import hardware wallets. And that was the reason that I worked on crypto account, which uses the crypto output. And that's really the idea is just to be able to import a wallet, you know, with a minimum amount of user interaction, it kind of just gives you all the information so that the coordinator wallet can easily choose and just say, okay, I want that piece of information. It hasn't seen the most uptake. I'm not actually even completely sure whether anyone's using it, even though Sparrow does accept those QR codes. Most people seem to have, unfortunately from my point of view, kind of defaulted to the cold card sort of output format that it uses to share and just sends that across. And it does work, there's no issue, but it's obviously not really following the UR spec. So I think that there's not really much that one can do there. It's whether people want to implement things is largely up to them. So that kind of covers, I think, the two major areas. The one that's really missing is, I think, this sort of legacy message sign of signing. And I'll say legacy because the 322, which is the top root, the kind of modern version, really hasn't seen a lot of adoption yet. So I expect that that will happen in time, but it certainly isn't the case today. However, what is true today is lots of people want to sign a sort of message using a SegWit address or a legacy address. And that is all handled by the legacy signing. So that's kind of this big area. You can do that currently with any USB connected wallet, certainly on Sparrow, HWI, which is the sort of interop program that most people use handles that particular use case. But when it comes to QR codes, we've just got this huge gap that there isn't any way to do it, or there hasn't been. And in the last sort of, I would say six to eight months, there's definitely been more user demand for that. And we've started to see, again, Spectre has come forward with, I think, a fairly basic protocol which allows you to sign using a single QR code with the obvious limitation is that if the data you're trying to sign is larger than a single QR code, you won't be able to do it. So again, rather than just follow that, I kind of felt, well, let's go back and see or can we implement this with animated QRs? And that's really what I started talking to Chris about last year. And I can see that this kind of alternative specter approach starting to get adopted in various hardware wallets. And I kind of feel that unless we bring this to the animated QR world, we might just end up with a much more difficult hill to climb in future. So that's kind of, I guess, my major reason for being here today. And though I completely-- having read the document that Chris put out, all those different points, I completely see the bigger picture here. I do think that there is an immediate need for this legacy message signing, which is a request and response. We obviously have a message and some kind of information about the key we need to send out, and then we need to get the signature back. So we got this request and response protocol going on, and it just seemed that you guys had been working on some of the, some of the time I haven't had the time to look deeply into it, but I know that it seems to be an ideal use case for this request and response, which you have spent so much time on. So yeah, I guess that that's just a brief kind of summary of the history of it and what kind of motivates me to be here today. - So Craig, a quick question, clarification. So one of the tricks that the, the legacy message signing. I mean, obviously it's a single key. You're referencing it by an address rather than by public key or a path or any of those types of things. How much compatibility do we need to have with that versus, you know, saying here is a fingerprint and a path and here is the signature, if the signature is compatible or do we have to do the kind of the weird address thing that legacy does? - Yeah, I mean, you know, what we actually need is a derivation path, a script type and the message that we wanna sign. Those are like the key things. And if we look at what HWI does, which is obviously trying to aggregate all of these different USB-based hardware wallets. Those are the key things that it requires. Now they are, because this is, message signing is a bit of a messy thing. Unfortunately, there are two different approaches when you get into the actual signature creation itself. Electrum wallet went off and did one thing and then Trasor did a different thing, which they standardized to some extent in BIP137. So there are kind of two approaches. I don't think it matters hugely, you know, which one we take here, which one in particular, what we want to take. So probably my view better to take the traditional approach 'cause at least it is in a bit. But as I say, I think the key thing is, you know, you can certainly encode that information into an A sort of address, but I would say that the key things are a script type, a derivation path and the message you wanna sign. - Yeah, it's that's what you're referring to, a subset of an output descriptor, essentially, not a fully general output descriptor, but something that would be an output descriptor would be a super setup, is that correct? - Correct, yes, you could certainly put it that way, yeah. - Okay, Ken, what are your pain points, use cases, anything more than what Craig has already described or a perspective on some of those choices? - I mean, the only thing we're using it for right now is there's a cold card ability to do a signing of an arbitrary message just passed in. And for that you get a path and the message to sign. And we're also using it for the Casa health check where they just want you to be able to prove that you can sign for the hardware wallet to reassure the users that their key is still safe. And so that again is just, essentially it's a line of text with some random data. We just provide the signature back. They include the path and we have a script type and we just have a simple function that does the signing and returns the response. And I mentioned this in the chat, but right now that response is just a UR bytes. - Okay. Could you, could you... - Honestly, the whole UR bytes thing real quickly since I've got both Craig and Ken here is ultimately my fault because I didn't make it clear enough in the early specs that I never intended bytes to be used that way, that the whole idea is, use higher level C-war structures and declare them. So, but mea culpa in that regard. - And we- - I'm trying to clean up the mess I made here. - Yeah, and so like when we were working with the CASA team, they had already sort of defined this as what they were doing. And so we were like, okay, well, if we don't wanna like have this take like another month of back and forth, we probably should just use this. - Okay. If you have a URL to that spec, or if there is a spec, I'd appreciate it. I was looking for the, I didn't know, I had forgotten about this, the health check, but I'd looked at, tried to find cold cards and couldn't. - Yeah, I'll never gonna find that, but I think it's just- - The main part, test vectors would be the most important thing to get, is essentially something that if I quickly throw together an example of how our technology could be used in this regard, I wanna make sure it does what it's assigned to do. - So- - I think the three things are just what Craig had said, but it's like the message, the path, the derivation path and the script type, that's all we have. - Okay. So I know one of the key things that I really wanna try to solve here is that, Shannon and I worked really hard for a no single point of failure scenario for a two or three, which we wrote up in that smart custody multi-sig use case and explained how it all worked. But like a lot of our other smart custody cases, it's just too many little niggling details. And so one of my big goals is that we can eliminate some of those niggling details. that, you know, so, you know, right now, all of our examples of PSBT kind of have a, you know, an implicit trust because you've got the wallet in your hand, you got your phone in your hand and they must both be yours. And I'm not sure that's, you know, always true. But then there's like these multi-step things where I need to first get the, you know, get a public key then then I have to, you know, If I'm a coordinator, I don't need to trust these wallets. I don't even need to have a private keys. So that whole mess could be made a lot easier if we can do all of these through some kind of crypto request mechanism. And then the joy might be for both Ken and for Craig is that instead of having this list of 50 different wallets and how every wallet does it different and what is the UI steps you have to go through to do it. You just tell it, here's the things I want you to do. And it comes back and says, I can do it or I can't. Ian, Nicholas or Sean, do you have any particular things that we've missed here? - No, I'm just kind of eavesdropping, just trying to get back up to speed, find out where you guys are. - Okay, Ian. I don't have anything to add at this time. - Okay. And I know Nicholas, you said you were in a public, loud public place, so it's fine. Nicholas is in Kenya, so there might be a really fun place. So let's dive down a little bit. For me, it feels like the primary requirement that we have to meet is the immediate need for, a one round trip, meaning when I mean Mount round trip is a one QR sent, one QR received of a request to do something. And, what level of support for some old legacy stuff is maybe the conversion of our format into a legacy Bitcoin, the thing that they deprecated in like Bitcoin 14, could maybe be done offline and it would be canonical and we can do that, I don't know. So far I've not heard from Craig or Ken that we have to have 100% for that. But I have heard that BIP 137, so, let's see, where is BIP 37 I had in front of me. - You put it in the signal channel. - Oh, there it is. Well, let's do just for reference here. Share screen. BIP 31, 37, okay. So, you know, it's been a while since I looked at this. Obviously it's an ECDSA signature. One of the complications that you have to deal with with ECDSA is that the signatures actually have the public key in it and you can extract it. But of course there's more than one public key that you can extract from an ECDSA signature. There's four. So we need to be clear on what that is. Maybe this does that. So then they're using uncompressed public keys. Obviously we have X only keys as well. So that could cause some problems for legacy. So we have to tell people what that is. They've defined some, What exactly this? So basically rather than, I don't know why there's 27 through 30. So they've defined some hard coded values. The question is whether or not they sign those values, but I have a little bit of a concern here in the sense that there's no future proofing in this. Whereas, you know, more descriptor style output, you know, details can give you more things. But, you know, I don't believe that descriptors say, you know, anything about what, you know, whether or not it's a, you know, Schnorr signature that's desired or an ECDF, 'cause it's encoded into that little script fields. script type field. So I think that with this, we don't really have too many options here. We have to generate legacy signatures. This is really just a specification for how to handle the two nested SegWit types. For the legacy types, the signature is always the same. It's just for nested SegWit and native SegWit SegWit that, as I was saying earlier, Electrum went one way, Fraser went none other. So they create slightly different segment signatures. But that's not really something that the sort of UR spec needs to worry about. That is what it is. I think it's also useful to say that both 322, which is the sort of much more modern replacement to all of this does include support for legacy signing as well. So it's kind of bringing that along for the ride. But again, that doesn't really impact, you know, it just impacts whatever the hardware wallet needs to do. It doesn't really impact the protocol sending stuff back and forth. Right. So I guess so one of the things is I'm hoping that we as I recall the original format of the way Bitcoin Core did it, which is the you know the legacy that only works with pay to script hash, does not sign any of the I think it just signs a text it does not include anything about the keys or all that other kind of stuff. It just simply, you know, appends as metadata this the address, so that you can look up, look it up and compare the, I mean, basically, you extract the signature, you extract the public key from the signature, and then you go and, you know, look at the hashed address and, you know, do they match? If they do, then it's a valid I think we can reproduce that because it doesn't have any embedded things. And then we can include a variety of different kinds of other metadata, which is other ways to confirm it than the address way. So we could put an output there, descriptor there. We could put a bit one three seven, you know, tag there or whatever. Do you think that would work? Is that a, you know, will that meet the needs that we can at least be binary compatible? compatible with the sign message, assuming they're not signing path stuff and signing the address and things of that nature. Look, I think so. As I say, I don't think that the precise details of how the signature is created, so long as the signer has enough information, and I think it does if it has those three pieces of information we were talking about. you know, it might choose to use different methods. You know, what we have in BIP-322 is a number of different, you know, kind of, we have the legacy signing, we have the simple signing, we have the full. I haven't yet implemented this myself, so I don't have a great view on kind of all of the details here. And perhaps, you know, something that we would want in future is for the request still to be able to signal which one of these approaches it would want to use. But, you know, as I was saying earlier, I don't think we are there today. I don't think that 322 has been implemented in any wallet that I'm aware of. It hasn't been implemented in Bitcoin Core, where I believe it's still a PR. So it's not, it is certainly something that I think we would want space for in future, but not something that is needed today. - Yeah, well, certainly we wanted to make a proof for it. We tried doing bit 3.2.2 with a number of interns, like four interns got together and said, "We're gonna try to do bit 3.2.2." And we actually have some Python workbooks. What is that called? There's a term for it. But anyway, we have some Python workbooks that actually implement-- - Jupiter notebooks. - It's the same thing with Jupiter, right? So we have some Jupyter notebooks that they did that implement 322, but as you said, for whatever reason, it's not been broadly adopted. Maybe we can solve that problem later. - One of the main things that I want to make sure this group is cognizant of is that when it comes to adopting our technologies, there's obviously a number of different approaches and part of what we wanna do is make sure that we're all using the same approach. When it came to, for example, signing PSBTs, I faced the question of, OK, PSBT is this tightly packed binary structure. It's not CBOR. It's, therefore, it's not parsable with that. But there's a lot of existing code that knows how to parse and sign PSBTs. And so is it worth expanding that to its own kind of CBOR description that might be more flexible and more future proof in certain ways? Or is it worth it just kind of treating it as a black box from the level of our stack and then just wrapping that up in a UR or as just a type, which is the approach we took. Now what we're talking about is keeping that obviously because it's legacy and it works, but also coming up with a more kind of generic, please sign this structure kind of thing. And for that, crypto envelope is an excellent choice because you don't even have to define it at the C-bora level, you basically define it at the semantic level. And, but obviously if we're talking about an existing standard of signing something, then we have the option then again of whatever binary structure it sends, of just taking that and expecting something to little parse it and do it. It's not my preferred approach. So I wanna make sure that, with that said, I'd like to understand whether there's anything about the existing kind of binary structures here, whether it's a text file that's been sent and needs to be sent back with, you know, a signed kind of header lines and things like that, or, you know, things that are basically C4 encoded, if that's important, or we can basically set that aside and say, okay, for our purposes of signing things, going back and forth between the signing object and the requester object, you know, that we can basically do this, you know, using a binary level objects, using CBOR and envelope. - But describing it another way, obviously, you know, we could take the front of a descriptor, which is, you know, the output, you know, the details of the paths in X-Pubs and things of that nature. Or we can say, no, outside of our code, you convert that into a binary structure that includes some things that it's missing. like, please sign this not with ECDSA, sign it with snore, or sign it with snore with this adapter signature, have all these other choices, but there is a deterministic binding from the current Bitcoin standards to a little binary object that allows for richer capabilities, or should we just, in our libraries, parse these forms? I mean, do you have a kind of a box on that requirement, Ian? - I don't want to speak for Ken, but I don't believe there are any binary structures with regard to message signing that exists today. I mean, I have read that coldcard doc, but I wouldn't say that that is a widespread kind of format. And I think it's specific for just this file that you create. I think it's useful as a reference, but I wouldn't regard it as something that needs to be followed. It's not broadly used in that sense. So I don't want to speak for Ken, but I suspect that you can use whatever fields you would like to create so long as they had those three pieces of information, and then they should fit well within the wallets that do exist today. We obviously need to fit the message signing in with the functionality we already have for the USB ones. and those are sending those three pieces of information across. So, so long as we can fit in with that, I don't really mind at all what kind of format that information is sent in. - Yeah, I would agree. The cold card file signing is kind of misleading because it can't really sign any arbitrary file. Like the file has to be a single line of text, essentially followed by an optional second line with a derivation path. But the only reason that we're using it for CASA is because they were already supporting this health check with cold card using the exact same format. - And I think it sounds like from that, they're actually signing the second line too, or only signing the first line and including the second line. - We're only signing the first line. We split them out, sign the first line. - The second line is just another parameter essentially. - Okay, that makes it easy. You know, I mean, my hope is that we can do this in a way and say, here is how you take a message, take what your other existing app do, convert it into this binary object. And when you come back, it'll exactly match what Bitcoin Core 14 does, what BIP 137 does, a couple of other different variations there, such as the signature of the signed text, but it could be binary. will exactly match. - It would be almost no work for us, there'll be almost no work for us to switch to that. 'Cause the signing is identical, it already takes three parameters. So it would just be pulling from the C-ball format instead. - You know, I forgot what is, you know, obviously when you sign a Bitcoin transaction, you're having to grab a bunch of other information. information such that, you know, I mean, what prevents somebody from creating a transaction, converting it and converting it and, you know, trying to trick somebody into signing a-- The signatures for a PSPT are integral to the structure, not external to it, whereas I think everything we're talking about here, the signature is essentially an appendage to whatever is being passed as the object to be signed. So when you send a PSBT, you're actually passing back a new PSBT that's been modified with the signature. That doesn't seem to be the use case here at all. It seems to be something where you're passing back a totally external appendage signature to the object that's been signed. Does that sound right? - Yeah, I'm just trying to think if there's some, you know, a raw transaction, you know, what prevents a raw transaction, not the PSBT, but a raw transaction from being, you know, accidentally signed. Does anybody is anybody aware of how the old message format prevented that? I mean, I think that was it only was text. So if you look at Bitcoin Core, you couldn't put binary into the command line of Bitcoin Core so you could never sign a transaction because the transaction. Presumably, if we pass, if what we receive is a arbitrary binary object and we're told how to sign it, how to drive a key to sign it and what kind of signature to produce, and we send it back, then theoretically, assuming that the object to be signed is not going to change at that point, the signature will be valid for it. So you might actually have that kind of exposure where somebody could pass something to be signed because essentially it's a black box. It could be a Bitcoin transaction. - Yeah, that's what happened on adherioms. That's what almost every major Ethereum wallet attack in the last two years has to do with the fact that they don't do any protection there. - When we receive a PSBT, we do a lot of checks on it. You have to make sure that everything belongs to this wallet. Make sure that the amounts don't look weird, like especially with these checks to make sure that the minor fee, for example, has not been manipulated to be too big. like we warned you if it seems like it's too big. We tell you if you're doing a send to self versus sending to another wallet. There's a bunch of little integrity checks that we do perform. - So I understand that, but what happens if, the requester QR basically says, please sign this text. But in fact, the text is a carefully manipulated binary object such that they can insert the signature that you generate and make it a valid transaction? So the first thing that any legacy signing needs to do is add a piece of text onto the front, which says Bitcoin signed message with a colon, and then there's a new line off to that. So there's no way that that could ever be a transaction. So they have to put that on at the front. And that's what the signer will do with the message that it gets. So there's just no way that once they've signed that piece of text that that can ever be a Bitcoin transaction. Cool. So let me talk about that a second. So if we basically made that another binary object that said, this is the pre-penned text or the pre-penned value because we don't want to necessarily, in the future, not always be text, And we basically say in all of our notes, if there isn't a prepended text, don't accept it. Like you have to have something different there. It cannot be null. It has to have some value or else your app should sign. Your app should not sign it. Is that, you think that would work? - No, no, what I'm saying is the signer would do that. The requester wouldn't even get the option of being able to, of being able to, in the case of a legacy signed message, suggest what kind of prepend should be made. At least that's not, and I'm just gonna refer back to this, that's not the way that HWI works, and I think it's a good model, because at least it fits in well with what we're trying to achieve here, is what happens is that the signer actually ends that text, and because that text is fixed and will never change, there is no way for the requester to ever pass something in which might be delicious because it just, it's always going to have this piece of text on the front. - So our use case is actually, you know, for, you know, even considering, you know, using blockchain come to stack and so on is that the message to be signed this could be arbitrarily large and therefore we need to ultimately make this compatible with, you know, URs and, you know, animated QR codes and so on. So when we're receiving that message to be signed, Are you saying that that message must be somehow text or must be somehow binary that is prepended with, you know, a UTF-8 string before being signed by the signer. So then once returned, it's, you know, the requester knows that the signature is only good if you prepend that preamble. - Look, I mean, I'm not actually sure whether it needs to be a UTF-X string or not. From what I can see, it just needs to be a byte string. I think that's fine. So long as it is a series of bytes. - Well, here is my suggestion for this, which is that if a signer receives a request without a value there, it at prepends a known value, which happens to be Bitcoin or whatever the default is. Okay. If somebody has some other value that they say they want to be the prepend, that it has to be, the signer has to go, am I allowed to sign something that has this in the front of it? And if it can't, it should refuse. Otherwise, it will respect that. And that allows us to do other things in the future, have other kind of mining, a tag that is the prepend for the, for a 5322 or a non Bitcoin thing without risking Bitcoin transactions. - Right, so here's an idea, because we can sidestep this whole conversation if we just elevate it up to the level of using crypto envelopes. So here's a crypto envelope. It has, it's a request. So it has, it's subject is, and sorry if any president isn't familiar with crypto envelopes too much yet, but I'm just speaking that terminology for a moment. You know, the subject of the envelope is a CID, which is a random request ID. The body of the envelope or the assertions on it are basically the thing to be signed and maybe an output descriptor, which, you know, obviously the signer could only accept subset of possible output descriptors, but basically essentially it's your path and your script type and so on to derive the key. And we already have support in crypto envelope, EC, ECDS, a signing. So what happens is the envelope gets wrapped signed. But, you know, the key gets derived with the contents of the request. The payload gets wrapped, signed using the same mechanism we already have with an ECDS, ECDS signature, which we support as well as short signals, Shnore signatures, and then pass back as an envelope again. And therefore, you're dealing with envelopes. So no matter what happens, no matter what the payload is, since you're signing the whole envelope, you can't sign a Bitcoin transaction in such a way that that signature is good for just the transaction, because it signs the whole envelope. But then it wouldn't be compatible with these legacy formats, which is something. Well, the thing is, what is the use case? Do we need, are we actually replicating these legacy formats? Because if so, then that's why I asked earlier, are we are we able to just roll our own in terms of binary formats? Because if not, if we are, then let's use envelopes. If not, then we have to basically wrap up these things in, you know, we have to embed text files and sign in the same way that was the BIP. BIP 137 says and so on and do it that way. So we do have to have binary compatibility of the signed object. done either way. If we do, that means we have to be more careful and prevent these, you know, a risky signing attack, which if we do it with the pure envelope way without any parsing or, you know, known things of, you know, hey, don't, you know, there's no prepend. We add a prepend, which is, you know, the Bitcoin prefix. So the envelope approach can be done and make it absolutely secure, but it would not be binary compatible with a signed object from BIP 137. - But anybody who supports it with- - With some of those extra rules, we can. - Yeah, so the question is, what do we absolutely need to be compatible with or are we just creating a new standard for signing arbitrary messages with Bitcoin, with the Bitcoin, with the drive Bitcoin key, that essentially could also be an address, but essentially is, we're talking about it in this conversation more like it's a, an output descriptor or a subset thereof. And so what will suffice? And that's, I guess the biggest question I have for the present group is, are we trying to be binary compatible with bit 322 in BIP 137 or are we able to actually just fulfill the use case of signing arbitrary messages in such a way that people who pass these non-volts back and forth can verify the signatures? By the way, Judd, BIP 322 does address that in the BIP 322 standards. So that's, we don't have to solve it for that. The bad ones are the original Bitcoin signing and the BIP 137 if we try to make it more flexible. So those are the two worst special cases because they out of ban say their return value must have this prefix on it. So those are the two risky ones. I don't think BIP 322 is a risk. I'm still not following how they are at risk if they are forced to prepend a set and fixed value. Well the thing is, okay, so right now when you send a message to the API, I do not believe that 1.37 is prepending. It's the signer that prepends. So that means the signer needs to know I have to prepend this and we're trying to make things that allow for a variety different types of such. So, you know, what, you know, we either, you know, have some type of thing that says, you know, you know, if we, we either have some kind of specific binary thing which says this is a legacy and we're going to add, you know, it could be just a single bit, we're going going to add the prefix. And otherwise, you have to use one of these safer methods. So certainly from my side, legacy message signing, I wouldn't want to specify any kind of prepend ever. I would only ever want the signer to prepend the only valid prepend text that can ever be used. because if I was to specify anything else, then the signature would be invalid and all of the validators that are out there, all of the other wallets would call it invalid and correctly so. So I certainly have no desire to ever prepend anything when it comes to legacy message sign-in signing. And from what I can see on BIP322, which is the future of this, that it falls away anyway, as you rightly point out. So, you know, for me, it's, I just don't see that there's any need to include this prepend coming from the request side. It's just not necessary. - Right, right. What I'm saying though is that they would, they're gonna say there's gonna be a legacy flag, okay, in the request. So it doesn't, isn't gonna affect the message. If you have a legacy flag and you're asking something to be signed, what will happen, you know, the API will prepend the signer on receiving the legacy request will prepend this text and there's no choice. It's like, this is the standard choice for that prepend. And then it'll be totally compatible with all of the old legacy Bitcoin in 1.37 and hopefully even Electrum. But if you don't have the legacy thing, then you have options that are safe. So whether or not that's some predefined things like bit 322 where you don't have to worry about it, or some list of various techniques to prevent these, it's not really a replay attack, is it? It's not really a replay, but anyhow, it's these malicious signings that every other choice will avoid the malicious signing as well. - So Christopher, may I take a moment and just kind of go through kind of these quick envelope examples to kind of show how it would work at this level, so kind of roll the same page. - I think the key thing is this is fine for everything else. It's the, but you can't do that. You can't use this for legacy. And what I heard from Craig, and I think I heard from Ken, but maybe less so, is that we have to be able to sign something it's binary compatible with these legacy things. You cannot do that with the envelope signing approach. - That's true. So if that's, well, if that's the case, then again, what we need to do is we need to identify which legacy signing methods we're gonna support and then create one or maybe one for each, a crypto request because ultimately again, the use case here is signing messages that are arbitrarily large because that means that the, because by packaging in a UR, they get sent to the signer who then performs this legacy kind of signing and just sends back the signature, which is just simple because it's always gonna fit into a QR code, a single QR code, but send it to the signer. - By the way, I'm not seeing it being a separate crypto request. It's a tag that even if a signer doesn't understand, It's a binary value that they put, that they send along to our API to say that this is a legacy thing. But otherwise the crypto requests look exactly the same. It's just some special handling is done. I mean, maybe we even double sign. We basically sign it with crypto envelope. And then in there we have the legacy extra sign. - Sure. I mean, that's easy to do. But I guess what I want to know is, okay, so if we want something that's, you know, say compatible with if we want to implement BIP 137 signing. All right, so we basically have a request that says, you know, here's a BIP 137 compatible payload. Here's the path to derive, which is optional, I guess, and the fingerprint. And then, you know, we basically treat the payload as text, as if it were just an input text file, We validate it to make sure on the signing side, to make sure it is just one line of text, and then sign it and send back the signature. The magic is in that whatever we received could be much larger than will fit in one QR code to sign. And that's, again, that's the whole raison d'etre of what we're talking about here, is that we want it to fit into a UR, but we don't want it to be a crypto bytes. We want it to be something a little bit more semantically meaningful or despite sign-in crypto bytes. And so I'm trying to figure out what that level of semantics is. - And other-- - It's just a packet that says, "Bip 137 signed this, fine, that's easy to do." And so is the other one as well. There's just different, it's a different kind of request. So we're not actually using the envelope signing mechanism at all. We just have a request that says sign this and a response says, "Here's the signature." - So the way the W3C does this with a number of identity wallets is they have in effect a proof purpose flag. And it's not really, I mean a proof purpose. I'm not saying we need to use their proof purposes, but the first proof purpose is legacy, which technically has the bytes of, what'd you say the byte prefix was? It was Bitcoin01 or something? So, you know, so the signer just needs to be careful only support the proof purposes that you want to support, which, you know, legacy, this legacy one would be, you know, the first one. But you know, there might be other proof purposes. So like one of the problems with the therem was there was an approved purpose difference between sign in with the Varium and some of the other purposes. And a signer ought to be basically, oh, wait a second, you're asking for a different proof purpose than I want to support or I want to do some extra confirmation. So like with sign in with the Varium, they actually do a domain check. They're supposed to do, excuse me, a domain check to actually see whether or not the request came from a web domain and there is an RPC connection to that web domain. I'm not saying we want to reproduce that, but that is kind of what the proof, what not having a proof purpose harmed that standard and that's why there's a whole bunch, you know, Wayne who's not here has been working on trying to address that. So I'm just trying to make sure that we can do the legacy, but make sure that we have an architecture that has some flexibility that can work for a variety of other cases. And I think that in effect, what the proof purpose is to sign a legacy Bitcoin message. And we do that. Because I don't think we can always sign with, having a envelope signature only as if it's not legacy, I don't think will work for a bunch of use cases. So for instance, there are other cases where a protocol might wanna sign a binary object and for some offline signing purposes or, I mean, for various protocol purposes or with Schnorr to create an adapter signature or other different types of things where we can't count on them to do a, excuse me, not you are, the triple signature that we do. It has to be a binary thing. So that means we have to have in the requests what the proof purpose is. And if you don't understand what the proof purpose is, don't do it. If Ken receives some weird stuff and he's asked to do a proof purpose that is ZK29, and you don't know what ZK29 is, and you can't present in your interface what ZK29 is, say, "I don't know what that proof purpose is. I'm not signing it." Does that make sense, Ken? - Yep. - Okay. So- - I'm just trying to figure out if essentially what we're after in the moment though is Since we're talking about supporting legacy signing methods, message signing methods, is identifying a set of signing methods that we wanna support and identify a set of test vectors so we can make sure that we support them correctly. And then I can quickly design a CBOR structure that encapsulates those and a crypto request around them and some code that actually accepts a message from the set of test vectors, signs it and returns it and verifies that it matches the-- - I just wanna not change the verb. I wanna say, what I'm saying is that there, a crypto request to sign, - If you're trying to say, you want a generic signing request that supports several methods, yeah, we can do that. But it's important to identify, if you don't wanna make it very special purpose, that it's important to kind of identify in its generality what we might support in the future so we don't, you know. - Right, and that's what I think, you know, you've got a good handle on. So the question, I guess for you guys is, when do you need this by? You know, how much, you know, back and forth do Wolf and I need to on, you know, is it a different verb or is it, you know, sign legacy or is it, you know, sign and then the object has to have some value, you know, added to it. - Okay, so here's the thing. If ultimately what we have is a crypto envelope, which is a request, because we already have a format for that, there's always a verb in there because it's a remote procedure call essentially. And the procedure and the verb, the name of the call that's embedded in the envelope could be BIP 137 sign, you know? And the arguments passed to it could be a line of text. - Well, let's argue about that offline. I don't, I'm not sure I agree. You may be right, okay? I think-- - Well, what I'm telling you that's the architecture of design. That's how it works. - No, but you can also look, you can parse, when you receive what it is to sign, you have to evaluate that. You have to look at that, the pieces of it, because it may have multiple things in it. Remember, there may be an option or not. - Yes, I know, but there's two optional arguments and so on. - There may be a-- - That's the whole point. - But that shouldn't be a different verb. - It's not a different verb, Christopher. It's not a different verb. I'm trying to tell you this. It's a different set of arguments to the same verb. The verb might be BIP 137 sign, or might be what BIP we're talking about. But the point is, that's the basic verb. And then the nice thing about APIs is you can add arguments later that modify the meaning of that basic verb, of that basic call that basically they may not exist first or they may be optional in the first release, but you can always modify it later. And you can and then you add other verbs which include, you know, ways of other other ways of assigning other legacy methods of signing. I guess I'm saying, but they'll have other. Let's take this offline. Okay. I'm saying that I think, you know, there's a difference of opinion. Do you have more verbs? Or do you have more kinds of information in the in the data of the request that that you do your interpretation with and I recognize there's crossover there and whatever, we can deal with that offline. The question is, right, well, basically, the fundamental question as an API designer is, would you make it a separate function call? If you make a separate function call, then it's a separate verb, but it's also part of a crypto request, you know, and if it would be, it would be all be part of the same function call, then it would be the same verb. But that's, that's, that's a semantic question. We will make some decisions about that later. Okay, Let's not do that now. Simon, welcome. Thank you. So Craig and Ken, are you aware of what Simon's signing tool is? Or what? I'm not. Basically we're building a wearable with a secure element and an NFC, it's a ring form factor that can be used to manage private keys, act as a security key authenticator and act as a signing device for all sorts of transactions, including crypto transactions. So it's special because it doesn't have much in terms of either input or output from the user. But it does have, but it is biometrically authenticated to the user while being worn, but there is no sort of UI to show confirmation of the transaction being signed or anything like that. So it works together with the companion app that does all the user intent confirmation and then communicates to the ring over a secure channel to do actual signing of NFC. So let me talk about this from the perspective of this conversation of one of the fundamental differences is that, so if we look at the passport, it is both a controller of private keys and it is a trusted UX to the user that parses things, asks various questions, evaluates it, presents some of that to the user to say yes or no. And then if it's true, the passport will sign it. Whereas there's a more explicit separation in the proxy architecture where the trusted UX is on a trusted app and keys are on a wearable. So one of the complications that this adds in this story, and this is why Wolf and I are maybe tussling a little bit on this verb versus object type thing, is that what'll happen is that a request like to sign is received by the wallet, by the iOS app, excuse me, or the mobile app, and it's gonna do some preliminary requesting and things of that nature. but ultimately probably what it does in most cases is it basically now is gonna make a new QR request, but maybe with the same identifier to the ring where it's doing the hashing for it because the ring can't hash, can't do a bit 3.2.2, has no network access, et cetera. And the ring now is receiving a signing request to sign this hash, which then is going back out to the iOS device who is then packaging it for the final response back to the requester. So that's kind of a use case where that particular functionality is now being split between two trusted devices. So I want something that'll work for Simon as well as doing the very basic use case of, okay, I'm gonna make this specially formatted thing. I don't even want, I don't want to understand UR's, I don't understand, want to understand any of this other stuff. I just want to have this message signed in a FIP137 thing. And we basically say, put this at the front of it, change this byte to make it for the length, pass it on as in a, in a, in a UR form and, somebody else will convert it to a QR code or send it over an NFC or whatever. but to make a dirt simple, when in fact, that thing that they're putting in the front of that message is rich in the future to be able to handle a variety of different things and ultimately allows, Simon's ring to sign it 'cause it can only sign the hash, it can't sign the whole message. It can't hash it yourself. Go ahead. Somebody raised their hand, I thought. - Simon, is that a fair representation? - Yeah, yeah, absolutely. And some of the other things that I would like to see is I would like this to be fairly, let's say a chain agnostic or even cryptosystem agnostic. So you can have different types of signatures, different types of keys, whether it's like P256K1 or R1, or EDDSA since you're not gonna have a specific hardware device for each different type of thing that you're using. - I would even say that the message, again, nobody needs to understand who doesn't wanna handle it. I mean, it should say what the derivation format is from the fingerprint of the master key. - Yeah, exactly. - There's a specific one that's required then, yes. - The ring can parse CBOR, right? - It's, it's, it's, it's, it's, it's, it's, it's, it's, - I'm sorry. - Well, go ahead. - I'm just saying. - Simon, the, the, the, the Java card on, it's a Java card on the, on the ring, right? The Java card compatible. So it can, it can parse CBOR, right? So you know, if you pass it a CBOR, you know, something encoded as CBOR, it can basically parse the fields of it out and see what, for example, what's the payload, what's the payload? - To a limited extent. It can't run a full-fledged CBOR browser, but it can, but C-BOR is simple enough to parse in a dumb way or in a way where you- - You wouldn't want to use something as sophisticated as the envelope layer for that then. You'd want to have a request response, which is pure C-BOR, which is, you know, you essentially could just prepend as a, you know, as a binary and, you know, have kind of very limited, obviously being C-BOR, it could have fields added to it later, but you probably wouldn't use the envelope layer of the stack in that case. - Yeah, and it can have, you know, I'd be able to do basic C-ball parsing of, you know, there's several header fields that need to be passed out to identify like what type of key it is or key fingerprint or whatever. It's basically, I would say a subset of C-ball that more or less resembles TOV, right? So most of the tag length value, - Okay, right. - Most of Java card APIs operate on TLV type structures. So there is structured data and, you know, C-BOR has sort of a subset of that. And I've decoded and coded things like SSKR shares from C-BOR before. So it's not just something that's not deeply nested or requires like a generic, a fully generic C-BOR. So you're just hard coding it for specific use cases, I guess. - Yeah. - Yeah. - My take on it is that, you know, his ring wants a crypto request to sign. And, but then along with it, it is basically getting, you know, here is a fingerprint. And so it goes, I don't have that key and says no. Or the next thing it says it has is a kind of derivation from that master key fingerprint and it can go, I don't know how to do that path, but if you, here's what I call a partial error, if you'll transform it for me, if you'll do the derivation, I might still be able to do it. And then the next thing would be the path if it does understand what the derivation is. And then there's the hash, 'cause I don't think that it can, I mean, there are some limits to how much you can do the hashing and the hash of the thing to be signed. - So I can hash pretty much anything. I just, I don't have the code space to be able to interpret what I'm hashing. So I can't make a judgment of whether this is a valid transaction structure because I'm not gonna have knowledge of all the possible different transaction structures and not have the code space to implement those. But I can certainly generate a hash of a message in most common hashing algorithms. - But you need the image to hash in that case. And that means that the whole image has to be transferred to the ring. And so you'd probably rather sign a hash rather than have to- - Yeah, yeah. - The rings are paired. So I mean, unlike the Passport who cannot trust that the QR it received is fair, in fact, it's almost like in the Passport you have an SE and an MCU. It's like now the MCU and the SE are in two different places but they do trust each other. There is a pairing that is happening there. So I think, am I incorrect that you can assume that, you know, if the, if you receive something from the iOS app, might as well let it do the hashing. 'Cause it's gotta do it anyhow to do the user presentation. - Yeah, exactly, exactly. Yeah, most of the time there's no reason for the device to do the hashing because it's, the app can do the hashing. There's one exception, which is ED255.19 where the original message is required to generate the signature, you can't just sign a hash. But that's the internals of how EDDSA works. - So, back to the, trying to take in the big picture, I'd like to have for you, Craig, and you can, an initial thing that, you know, is, you know, a basic demo that we can do the single round trip solutions for your two legacy needs, but is, you know, flexible enough to serve proxy. 'Cause I mean, there are, so to give you some context also with some of our other discussions, the, you know, we're working with crossbar on new silicon, and we've been talking with Tropic Square and others, where the SE may finally be able to actually sign with Bitcoin keys and be able to sign with Schnorr in the secure element. But they're very constrained devices, and they've kind of said, we want to kind of do, you know, a CBOR envelope type thing, even for, you know, down at that very low silicon level. So, you know, we need to be able to handle use cases that are these very constrained devices where it's okay if, you know, let's say somehow the ring and the is a little spec out of sync with the iOS device, the ring ought to be able to say, no, I can't do that, but I can give you, you know, a continuation and you come back to me after doing some things that I can't do. So the same thing is, you know, they're talking about in these Silicon devices where like with frost type things where some of the operations are very computationally expensive, you know, the secure element can say, well, I'm still gonna hold on to the keys. I'm not gonna give you the keys like, you know, Trezor does, but if you will do these transformations for me, so ends up being this kind of, you know, crypto request to do this, parsing, crypto request to do this, returns back. with a partial failure, something happens here, comes back, it's finally signed, brought back and then back out to the users. So that is the thing we want to try to enable without stopping Craig and Ken or allowing other people to do, we need to do it fast enough so that Craig and Ken can get their legacy thing out there to serve the immediate need of CASA and to try to have less kind of, go ahead. - For that kind of back and forth, repeated back and forth, envelope using our request response structure is ideal. I'm just concerned that Simon's Java card element is probably not powerful enough to parse and write that format very well. It can do basic C-BOR in a constrained way, but trying to do something as general as envelope might dispute, you know, would probably be over the line. - Well, yeah, and I don't think he has to do as general as envelope. He just needs to be able to have some well known requests. - Yeah, exactly. But that seems to me that's a separate protocol from a higher level envelope based protocol that people using, you know, mobile devices and desktop devices and so on would generally prefer. At that level, when you're talking about such a small embedded device, you need almost a different protocol. Now it could all be, you know, it's ultimately all CBOR, but the question is are you using a higher level semantic structure like envelope to package these things which would probably overload, you know a very small embedded element like that. And then you design a specific subset for that very small embedded and for that constraint environment because it wouldn't be preferred to use that higher levels. - Yeah. - But it might be necessary to use it at the lower levels. - Yeah, and it might be, it's, you know in this particular case, because you have a the party in the middle that's able to reinterpret that request, it can extract the bits out of it that it needs to pass down to the lower level and repackage them in something simpler. Even if it just repackages them in TLVR rather than in C-ball for that purpose, that's fine as well. It's more about having, I guess, standardized semantics the original request level said, you know what to expect, right? In terms of which fields are going to be there, how are the keys going to be referenced and what the expected result is. The actual format packaging can be translated for the device. So we'll figure that out. So, you know, Proxy is a full sustaining supporter of Blockchain Commons and we meet with them regularly. So, you know, we don't necessarily have to solve all those problems right now. I think the main thing I wanted to indicate to Craig and to Ken is that, you know, part of what we're trying to be careful about is to make sure we conserve, you know, lots of wallet developers and Simon has some very specific needs. But we also recognize your needs. I mean, Ken has also been an ongoing sponsor of Blockchain Commons as well. And I want to meet his needs also. And I think we have enough knowledge that Wolf and I can knock around something that will solve the legacy need and yet be able to have the right choices to solve of Simon's needs and some of these oddball weird things. So the Jade Wallet, I've been trying to get Blockstream to join Blockchain Commons and maybe if we can, we'll finally get Cold Card and some of these other people to participate here, 'cause I haven't been able to get them to come, I've tried and tried. Jade Wallet does this extra thing, they have an extra optional field, which is this nonce-like random thing. And when the signature is all done, they're not just providing the signature, they're also providing that the signature was done properly given the weird knots that it was given in the initial request. Those are both optionals. It's like, you know, if, you know, Craig, you see this optional thing and you don't want to, you know, deal with exfiltration stuff, you just ignore that field. If you receive, if your software signer receives this nonce, you know, you don't have, you know, it's optional. So, 'cause it's really ultimately the verifier who cares whether or not it was ultimately done, not you as a signer can say, no, I don't know how to handle this exfiltration nonce, but I can still deliver you a software based signature as you've requested. So those are the kinds of things and adapter signatures and some of these other weird things that we wanna make sure we're able to do. Does that help your confidence in Craig and Ken? - Yeah, that sounds good. The other thing I wanted just to add is I've been working the last few weeks on a different BIP129, which is the Bitcoin multi-sig sharing protocol. And that also uses legacy, well, it uses BIP322, which includes legacy message signing. And all of the examples are using legacy message signing there. So, you know, the immediate roadblock that I ran into, which again, brought me here was that that immediately excludes all of the QR code hardware wallets, because of course they are then unable to sign those messages being without that. So that is a multi-line format. I believe all legacy message signing, I've just been doing a bit of research, is UTF-8, just so that you know. But that just might also help you, Wolf, just as you look through at the different sort of examples there that's not just a single line of text. At times, it is a multi-line, line, line, line of text. And that can actually, it doesn't seem to be commonly expected. For instance, the cold card doesn't allow you to sign a multi-line of text that actually throws an error. So just something to be aware of. - I mean, there's some similar things. I know with the crypto request in PSBTs, if you remember, there's what we call the unsigned notes, or I forgot what the exact field is, but we have the CBOR thing you can add so that you can add a comment that is not part of the signature, that is an untrusted note to give you some information. So we wanna be able to handle those kinds of optionalities and maybe that's where that second line goes or other kinds of things. And then of course, if the signer and the requester have a trusted relationship, they can even sign those notes so that you actually know that the, say the no private key private key, Mari, I'm sorry, the no, sorry. The no private key coordinator can still have a trusted relationship with the signers and use these public keys to trust the signers and we can make it such that that kind of relationship will not break anybody. So Ken, how about you? How does that sound? Yeah, that all sounds great. I mean, our needs are pretty limited right now. As we get into our next device, I think we're going to be looking at a lot of other potential use cases, though. I'm planning to reach out to you at some point to the next few weeks about some of those. Great. Simon, am I missing anything? - No, I think that's a bad right. - So my takeaway from this and my action item personally is I'm gonna be studying the BIP 137 and BIP 322. I want to design some, at this point, envelope-based structures that use our request response format and then probably come back to you guys and show some actual running code, which basically shows, okay, here's how you would compose a message using the envelopes, probably in Swift code because that's where our current implementation is, although we're starting to work on a Rust stack now. And then, here's how you compose it, here's how the receiver receive it, validate it, sign it, send it back. And here's how the requester of the signature could then easily extract the data and reformat it in such a way so that it would be essentially the result of say, a cold card signing, a single line of text or whatever, even if it didn't come back that way, it'd be trivial essentially to extract these fields, put them into that format and have something that would work with legacy devices. Does that sound right to everybody? - Yeah. - Yep. - And Bit322 sounds a lot more complex, but I will also research that and see at least if I can't get some functional subset of that working as well. And then so basically, it's obvious what the path forward would be if we all want to support this and how it makes sense to all of us in terms of how that would work. Obviously, when it comes to something like the ring, it would be probably another layer where the envelope is extracted by the iOS device packaged up into a much smaller CBOR structure that's much more kind of-- because it's smaller and tighter, It's also a bit more brittle, but it's very purpose-specific. That would be sent to the ring, signed, sent back, that kind of thing. Does that sound right, Simon? - Yeah. - Great. - No, I'll share with you in a sec what, just what that, what it looks like currently for. - If you're in the signal channel, that'd be great. If you're in a URL or whatever, you sit in the signal channel, that would persist past this conversation. - Some things, I mean, one of the things we have to appreciate is we wanna be able to support the simple things simply and the complex things as elegantly as we can. And like with BIP 322, I don't think we're ever gonna have a BIP 322 that can be done on a ring. 'Cause, well, excuse me, there are subcases of BIP 322 that can be done on a ring. But anything that's paid to script hash or taproot or whatever, you have to have a Bitcoin script parser. You have to have access to Bitcoin data in many cases, et cetera. And clearly that's not something that Foundation Devices core passport device will be able to do 'cause there's no network. And maybe they can do some of the Bitcoin stuff. So we wanna have these kind of graceful partial failures where a device like the physical passport, I know that you guys are working on iOS apps and stuff. So you may ultimately have a trusted relationship between your device like Simon has between his two. But where your passport can basically go, "Oh, I can't sign that, but if you'll do this operation for me, I'll sign it." So yes, that makes it two round trips 'cause you're doing QR code, QR code, QR code, QR code, but it works. So we wanna be able to future-proof for those types of scenarios. - So, just to speak to that briefly, QR will not always be our only communication method. - Cool, well, yeah, we wanna support NSEs. I mean, most people don't know this, but the reference wallet, which again is not a commercial, it's not something we're trying to go out and sell and make a business out of, but it's just a reference for all this. Supports NFC, you are as now. So that's like one of my other reasons. Well, I just want to say, I want to drag in the cold card people 'cause they're the only, that tap signer is very proprietary and some of the code is not open. And I really wanna be able to do that with what TapSiner does, but with an open standard and completely open source. The Java Card stuff in the TapSiner, as far as I know, is not available to the public for review. - Yeah, but the way we've sent our stack is obviously if you want URs, especially because you're doing QR codes, it's there. That's your kit. But below that is CBOR. And outside of that is envelope. So you can have envelope that's encoded to CBOR that's turned into a UR. And then you reverse that process. But if you're just dealing strictly between an iOS device and an embedded device like the ring, you don't need UR's. You don't need to parse UR's. You don't need to send text. You just send this to the Robiner CBOR. - You can pair it. or B64 if that's what you desperately have to do. - Yeah, whatever. But the point is that our stack has a very clean separation of responsibilities. So you only pick the parts of it that you really need. - Okay. Well, does anybody have any objections to me sharing this video to the broader community? - No. - No. - Okay. - Well, I'm gonna go ahead and stop recording now and thank you very, very much. I think our next step is to give you a preliminary, this is how you can do legacy that we think addresses the future use cases without explaining them all to you and try to get that to you relatively quickly so that you can make sure it solves your things and then we can run the bigger details of how some of these other use cases by not only other wallet companies, but also I wanna run it by some cryptographers to make sure we don't have any protocol, snafus like the otherium people have had. So I'm hoping Wayne can review it and maybe some other people are more sensitive about these issues. So thank you very much for your time and we'll get back with you shortly. We also next on the first have a, which is you know a week from now on we have a more general call in the afternoon so I know Craig you can't make it about DC-BOR and the DC-BOR library. We have it in Swift and Rust right now and we're We're working on getting it into Kotlin and into Python. And we wanted to talk with you all about that 'cause it's a found, it's underneath the envelope library and it's generally useful. So, you know, we'd love to have more people using it and then we can give a report out on other things. So again, the first will be our next meeting. And I don't remember, is it 3.30 or four on next Wednesday? But anyhow, I'll send- I have 4 p.m. Pacific time on-- - 4 p.m. Pacific. And then Craig, if you're interested in these types of things as well, we can maybe alternate. We have some problems 'cause we also have some Vietnam-based developers who are actively using SSKR and some of the other UR standards. So we've been scheduling friendly for them, but we can also alternate. Simon, do you want to quickly say something about, are you thinking we have to talk about SSKR on the first? Simon, you're on mute? Yes, sir. Sir, what specifically? Oh, I just wondered if you might be able to talk about SSKR on the first. Yeah, yeah, probably. Yeah, yeah, probably. So anyhow, I hope you guys will join us for that. Thank you very much and talk to you soon. Bye bye. Thank you. Thank you. Bye everyone. everyone. ( [BLANK_AUDIO]