WEBVTT 00:00.000 --> 00:10.960 All right, everybody, grab a seat. I would like to introduce Tim Hobson, Pamela and Sam from Trust 00:10.960 --> 00:14.600 Chain. Trustworthy, decentralized public key infrastructure. We're going to do about 20 00:14.600 --> 00:18.520 minute presentation. We're going to stay some time again for discussion. If you could 00:18.520 --> 00:21.480 remember to repeat the question of somebody else who question I'd be on trying. 00:21.480 --> 00:26.360 Awesome. Thank you very much and thanks for the organisers. This is fantastic. I'm going to 00:26.360 --> 00:31.240 talk about Trust Chain, which is a project software project or about decentralized 00:31.240 --> 00:37.840 public key infrastructure. I'm Tim. There's Pam and Sam are in the audience there, so if 00:37.840 --> 00:43.160 you want to come and talk to us after you know, to look for. Okay, so I'm going to start 00:43.160 --> 00:48.880 with the kind of design goals behind Trust Chain. So what we're trying to do is enable 00:48.880 --> 00:55.120 anybody basically to build their own public key infrastructure without requiring any trusted 00:55.120 --> 00:59.160 third parties. Of course, there are public key structures that exist already, but they 00:59.160 --> 01:07.640 do require third parties, certificate authorities, for example. And so we want anyone 01:07.640 --> 01:11.320 anyone to be able to set up their own public key infrastructure and I explain why you might 01:11.320 --> 01:16.720 want to do that in a minute. Any user community to be able to just basically do it themselves 01:16.720 --> 01:22.080 and that means really using decentralized infrastructure so you don't, it doesn't cost fortune. 01:22.080 --> 01:26.240 And if we're going to work in a decentralized setting, then we really need the end user 01:26.240 --> 01:31.440 to be able to verify everything, essentially. Otherwise, you need to trust a third party. 01:31.440 --> 01:38.680 So end user verifiability is like a key goal. There are some really massive categories 01:38.680 --> 01:46.840 of use cases. First is digital ID in a kind of decentralized and trustworthy user centric 01:46.840 --> 01:53.280 context. That was how we started off this project was looking at digital ID, but then 01:53.280 --> 01:59.800 we basically realized that if you can do public key infrastructure in a trustworthy way, 01:59.800 --> 02:05.320 then you kind of get digital ID for free, obviously decentralized. But you also get a lot 02:05.320 --> 02:12.360 of other cool things for free. You can verify your files and I'll explain how that works. 02:12.360 --> 02:19.320 Before you visit a URL, you can verify that it really is the legitimate one. You can do 02:19.320 --> 02:23.920 data provenance because if you know if you know the public keys of your counterparty or some 02:23.920 --> 02:29.760 institution, then you can just, you know, they can sign data when they release it, like 02:29.760 --> 02:37.400 a media company can release images, video or just articles or, and you can just, you know, 02:37.400 --> 02:42.480 they sign that data and you can verify their signature on it because you've got their 02:42.480 --> 02:47.800 public key from this infrastructure. And then generally secure communications between 02:47.800 --> 02:53.560 counterparties in a kind of digital economy. So there's loads of massive use cases. And 02:53.560 --> 02:59.440 yeah, just for a highlight, trustworthy digital ID is where we kind of came from this idea 02:59.440 --> 03:05.840 came out of. And one of the motivations is the idea that instead of kind of lobbying or 03:05.920 --> 03:11.880 trying to fight against, you know, centralized digital ID, which is widely, it's widely 03:11.880 --> 03:18.560 recognized to be potentially really risky for society. Well, one approach is to just build 03:18.560 --> 03:24.240 an open decentralized alternative, which hopefully is superior, and then people just use 03:24.240 --> 03:30.840 that instead, and that's kind of worked in some other context. So, okay, so this is one 03:30.840 --> 03:37.040 picture to try to get the idea across. It's just one possible scenario. It does not need 03:37.040 --> 03:42.040 to be a kind of government, you know, centered or public sector, you know, structure of 03:42.040 --> 03:49.560 this network. But the idea is we want to be able to access, just imagine a world basically 03:49.560 --> 03:53.840 where you can access the public keys in a verified, in a trustworthy way, of all these 03:53.840 --> 03:57.880 different institutions in society. And if you can do that, then, yeah, you can see at 03:57.880 --> 04:02.960 the bottom, you've got credentials can then be issued by any of these legal entities, 04:02.960 --> 04:07.440 and because you can access the public key, you know, you can verify the signature on the 04:07.440 --> 04:12.400 credentials, and so everything just works. And, you know, when there's been lots of 04:12.400 --> 04:15.960 talks about credentials, and, you know, it's kind of just assumed that there is some 04:15.960 --> 04:20.440 public key infrastructure, but we want to be able to say, well, you know, just, you know, 04:20.440 --> 04:25.360 how does that work? And, you know, wouldn't it be great if anyone could set up their own 04:25.400 --> 04:29.040 because, for example, yeah, you could have, like, yeah, the route of this network could 04:29.040 --> 04:34.600 be a private company, and with, you know, different regional offices, and they want credentials, 04:34.600 --> 04:39.720 people be able to scan QR codes in order to sort of admit their employees as they move 04:39.720 --> 04:44.160 around, or there's all sorts of possible, or it could be an online community, not physically 04:44.160 --> 04:53.000 located in one place. So I'll come back to this example. So these key icons, they represent 04:53.000 --> 04:58.800 public key certificates, which, for us, are going to be the ID documents. So the WBC 04:58.800 --> 05:07.400 DID standard. So yes, I wanted kind of focus on the WBC standards for verifiable credentials 05:07.400 --> 05:12.880 and the IDs, and this is taken, this diagram's taken from that standard, and the whole 05:12.880 --> 05:18.480 thing, basically, revolves or works because of something that they refer to as a verifiable 05:18.480 --> 05:25.480 data registry, which sounds great, but how do you actually create a data registry, where 05:25.480 --> 05:32.400 you can somehow verify the veracity, the tripalness of the information that's on it, 05:32.400 --> 05:38.360 but the point is that you really need the end user to be able to verify it, right? So 05:38.360 --> 05:42.320 what, you know, it's called a verifiable data registry, well, what mechanisms do we have 05:42.320 --> 05:51.040 for actually verifying data, right? So what types of information can we verify cryptographically? 05:51.040 --> 05:55.880 So one, of course, is digital signatures, so their ubiquitous, and that's the whole point 05:55.880 --> 06:01.480 of having a public key infrastructure is so that you can then verify digital signatures. 06:01.480 --> 06:08.000 So that's super cool, and they're definitely going to be part of the solution, but they're 06:08.000 --> 06:12.880 necessary, right? But they're not sufficient, because, well, there's a chicken and egg 06:12.880 --> 06:18.160 problem, right? You can't, you can't only use digital signatures in order to set up a 06:18.160 --> 06:22.120 public key infrastructure, because you always need another public key to verify the signature 06:22.120 --> 06:27.120 in the first place, right? So alone they're not going to be sufficient, they transfer trust 06:27.120 --> 06:32.440 rather than creating trust. The second one that's going to be useful as well is basically 06:32.440 --> 06:36.720 cryptographic hash functions that produce a digest, an output of that function, and what 06:36.720 --> 06:41.200 that gives you is basically you can then verify immutability of the data, right? So this 06:41.200 --> 06:49.920 is how IPFS works, the implantary filing file system, so online distributed filing system. 06:49.920 --> 06:57.120 So you put data into IPFS and the address for then retrieving that data is the hash of the 06:57.120 --> 07:03.400 data set. So when anyone retrieves the data, they can simply just compute the hash again, 07:03.400 --> 07:08.880 and they know that the data is exactly the same as when it was put on the registry. 07:08.880 --> 07:12.920 So again, that's super useful, but it's also not going to be sufficient, because it's 07:12.920 --> 07:18.280 all decentralized. Anybody could have put the data there. So how do you know it was legit 07:18.280 --> 07:22.960 when it went on? How do you know it who it actually relates to in the decentralized setting 07:22.960 --> 07:27.840 just being able to prove immutability is not sufficient? So this is sometimes referred to as 07:27.840 --> 07:33.320 the Oracle problem, because you need a kind of an external Oracle to kind of like actually 07:33.320 --> 07:38.600 create the trust, if you like. So there's one, there's a third one. I'm not going to 07:38.600 --> 07:43.880 talk about zero knowledge stuff here, because I don't think it's useful for sharing public 07:43.880 --> 07:50.240 key. So pretty much the only other one that I know about, I'd love anyone to correct me. 07:50.240 --> 07:55.880 We can verify cryptographically, we can verify timestamps, and so trust chain is basically 07:55.880 --> 08:02.760 going to see if we can leverage this ability to verify timestamps to to support a decentralized 08:02.760 --> 08:07.960 public key infrastructure. So how do we actually do that? How do we, so this is kind of funky 08:07.960 --> 08:13.400 right? Because you know how, how and if can I verify cryptographically? How can I verify 08:13.400 --> 08:17.960 that an event took place on a certain date or a certain time in the past? That right, 08:17.960 --> 08:22.520 we're jumping from the digital to the physical in a really funky way. Well, so I want 08:22.600 --> 08:26.760 to kind of drill down, this is like the core verification mechanism used in trust chain. 08:26.760 --> 08:31.400 So I'll just to some people, you know, this might be kind of obvious if you know about the 08:31.400 --> 08:37.080 the pit pit networks that make this work, but if not, I want to just make sure everyone understands 08:37.080 --> 08:42.280 that this really is a cryptographic verification that certain public keys were published on a certain 08:42.280 --> 08:50.840 date in the past. And so we're using a system called Ion, the identity overlay network, 08:50.920 --> 08:55.880 and that's a DID method for those who know what that is. It's essentially enabled you to take a 08:55.880 --> 09:02.600 DID string of characters and then it returns DID documents and the DID documents are the things 09:02.600 --> 09:07.560 that actually contain the public keys that you use to verify the signatures and those documents 09:07.560 --> 09:16.280 also contain URL endpoints. That's how we do verifyable URLs as well because they're contained 09:16.280 --> 09:23.960 in this DID document. So what does Ion do? When it publishes a DID, it takes that data and it publishes 09:23.960 --> 09:31.160 it onto IPFS, this distributed filing system. And it uses these three different files at the top, 09:31.160 --> 09:37.720 that's for scalability. So you end up being able to just fit more data into each transaction. 09:38.680 --> 09:50.360 And then as I said, the address of a IPFS file is called a CID content identifier. That address 09:50.360 --> 09:55.640 is just the hash of the file itself. So it takes that hash and it puts it in a Bitcoin transaction 09:55.640 --> 10:05.800 and then publishes that on the chain. So what that does is it that anchors it in time and that's 10:05.800 --> 10:09.640 exactly what we're going to leverage. So all we have to do, you have to pay for a Bitcoin 10:09.640 --> 10:16.840 transaction but that's not high cost less than a dollar usually and you can embed up to 10:16.840 --> 10:25.320 well several thousand DID operations with the single transaction because of this scaling the 10:25.320 --> 10:33.160 guys who develop Ion took care of. So what do we do when we actually verify a timestamp on some 10:33.240 --> 10:39.240 public keys in trust chain. We start the top of this diagram, we take the actual bytes. So we use Ion 10:39.240 --> 10:42.840 to retrieve the information but we don't want to trust Ion, right? We don't want to trust any third 10:42.840 --> 10:47.800 party. So Ion would be a trusted third party unless we verify it for ourselves. And so we want the 10:47.800 --> 10:53.560 end user to be able to do the full verification which is what I'm going to describe now. So the trust 10:53.560 --> 10:58.600 chain software will basically use Ion or some other, it doesn't really have to be Ion but 10:58.840 --> 11:06.760 you retrieve this information from the IPFS and that you actually access the DID document, 11:06.760 --> 11:12.840 you look at the public keys and you say, well, how can I trust these? You take those bytes and 11:12.840 --> 11:18.440 you you check that they're contained in this first chunk file and then you compute a hash 11:18.440 --> 11:23.080 that gives you the CID of that file and then you check that in the next file, you hash it, 11:23.080 --> 11:27.400 you check that in the next file, you keep going until you get to the hash that's in the Bitcoin 11:28.360 --> 11:35.720 and then that again you can continue the sequence of hashing and checking the hash is contained 11:35.720 --> 11:43.240 in the next step and eventually you end up at the Bitcoin block header and that also contains a 11:43.240 --> 11:48.360 Unix timestamp, right? That's when the Bitcoin block was mined and then you hash that and you get 11:48.360 --> 11:54.280 this proof of work hash, right? This POW is proof of work hash and what makes all this work is 11:54.280 --> 11:59.800 that basically the PIRT PIN network, the Bitcoin network is hashing and you know kind of crazy 11:59.800 --> 12:04.920 rate of like around 800 x or hashes per second and that just keeps going up and up so it's just 12:04.920 --> 12:15.320 infeasible to edit or change any of the information in this diagram right? Without performing even 12:15.320 --> 12:22.440 more hashes than the Bitcoin network and there's no there's no authority on earth that has got 12:22.440 --> 12:27.000 that amount of you know it does infeasible like computationally that's otherwise Bitcoin itself 12:27.000 --> 12:32.040 wouldn't work, right? So I know there's been like yeah I'm definitely not a blockchain advocate 12:32.040 --> 12:36.440 I think you've got to draw a big there's a world of difference between the Bitcoin network which is 12:36.440 --> 12:42.040 doing proof of work and gives you verifiable timestamping and then all the other blockchain stuff which 12:42.040 --> 12:48.440 I would agree with most some of the people here that you know very skeptical. Okay cool so yeah just 12:48.440 --> 12:54.760 to sort of recap basically if anyone came back subsequently and edited any of the bytes any of the 12:54.760 --> 12:59.720 information in the DID document then you would end up with a different hash which wouldn't match 12:59.720 --> 13:06.280 the proof of work hash at the end of this the sequence and so each trust chain node just needs to 13:06.280 --> 13:11.880 have a Bitcoin client built into it and it can be a light client which means that you only need 13:11.880 --> 13:16.520 the sequence of Bitcoin block headers you don't need the full blockchain you just need the headers 13:16.600 --> 13:21.320 and that is sufficient for the end user to then be able to say why is this proof of work hash 13:21.320 --> 13:28.760 actually you know contained in the header the chain of headers if it is you you basically have 13:28.760 --> 13:33.240 cryptographically verified that that that document was published on that particular date. 13:35.560 --> 13:41.560 Okay so this is what it then looks like you know with with trust chain basically securing all of 13:41.640 --> 13:48.680 these public keys so whoever's going to act as like the root entity on this network we're assuming 13:48.680 --> 13:55.240 us of hierarchical network you know because well yeah these are very common but we don't want yeah 13:55.240 --> 14:00.600 you know the the end the root entity doesn't want to have to you know provision all of the 14:00.600 --> 14:05.960 infrastructure so it's all built on decentralized infrastructure but they are like you know some kind of 14:05.960 --> 14:13.000 authority within the the social structure that you know wanting to share information so in this 14:13.000 --> 14:17.640 case here we've got the central government is the root but that's just just an example what what 14:17.640 --> 14:26.920 matters is that when that entity publishes brilliant when that entity publishes their root 14:26.920 --> 14:33.160 DID right there's going to act as a kind of the root of of this network of trust what they then 14:33.160 --> 14:37.000 do is they can they can wait for a month or two to make sure that the Bitcoin chain really isn't 14:37.000 --> 14:42.600 going to get like attacked and then and then they just share the information they just have to 14:42.600 --> 14:49.320 tell everyone else in the network you know what date they actually publish that that information 14:49.320 --> 14:54.920 and then everyone is going to be able to verify that you know that there really is a DID published 14:54.920 --> 15:00.360 on that date and any attacker is you know is not you know can't overpower the Bitcoin network 15:00.440 --> 15:06.280 we're assuming and it would be observed if they did but yeah that's infeasable and they certainly 15:06.280 --> 15:11.400 can't go back in time and and publish their own root DID to sort of you know to attack this system 15:12.760 --> 15:17.240 so the root DID has a verifiable timestamp in fact they all do but that's the most important one 15:17.240 --> 15:23.000 and then after that you can then create these chains of what we call downstream DIDs right so these 15:23.000 --> 15:27.480 are DIDs that have an attestation they have a signature from the from the layer above 15:28.440 --> 15:36.840 yeah so that you know assuming you you of course we we're not when I say no trusted 15:36.840 --> 15:41.000 the parties and we don't we don't want the digital infrastructure to need to be trusted that should 15:41.000 --> 15:46.360 just be verifiable but of course you know we expect to trust the legal entities in this network 15:46.360 --> 15:51.400 that's the whole point right we we want to interact with these other institutions in society that we 15:51.400 --> 15:58.680 that we recognize so we've we've proposed a small extension to the DID standard to enable 15:58.680 --> 16:05.080 these chains of downstream DIDs to be you sort of realize within that standard in a way that is 16:05.080 --> 16:08.360 we've got to work around which is fine at the moment but you know it could be it could be 16:08.360 --> 16:16.680 need to so we're hoping to to get a slight change to the standard so how does this look on 16:16.920 --> 16:23.560 so we're we're really focusing on the back end infrastructure side but in order to like demonstrate 16:23.560 --> 16:31.320 the software we've we've forked an open source credential wallet and so this is this is the kind of 16:31.320 --> 16:37.160 the result this you know yeah this is supposed to sort of describe what what's the user experience like 16:37.160 --> 16:43.800 for a mobile user so basically the first time you you you you you run your you you install your wallet 16:43.960 --> 16:48.920 and then the first time you run it it's going to basically push you to go to the settings page 16:48.920 --> 16:53.000 and then you just need to enter the date just need to enter the date that you will have you'll have 16:53.000 --> 16:59.080 seen you communicated to you buy this central entity if it were central government you'd expect 16:59.080 --> 17:03.240 you know there'll be billboards and you know on the side of buses or in public buildings you 17:03.240 --> 17:07.240 just have posted saying this is the date right you just need to know this date if you know 17:07.240 --> 17:11.960 this date then it's you know it's a small amount of information and you know normies can type of 17:11.960 --> 17:17.320 date into an app right to configure it and and that's about small and easy amount of information 17:17.960 --> 17:23.320 you know as possible to to remember but it because it's verifiable the time stamps are verifiable 17:23.320 --> 17:28.920 it also gives you this kind of end user verification and then there's a short confirmation code of 17:28.920 --> 17:33.720 just a few characters and that that's just a fragment of the Bitcoin transaction that contains the 17:33.720 --> 17:39.880 DID you hashed into it and and that enables the software to just identify exactly the right 17:39.880 --> 17:47.480 transaction to look at so once you've done that quick configuration step you can then basically verify 17:47.480 --> 17:53.320 all the DID chains on the network that I showed a moment ago you can verify URLs because 17:53.320 --> 18:00.280 you know URLs can be you know inserted in DID documents as well so you get public keys as well 18:01.160 --> 18:05.960 URLs as well as public keys and of course credentials as well because you know you've now got 18:05.960 --> 18:11.400 a public key infrastructure and yeah so so it ends up looking like this and obviously if 18:13.560 --> 18:19.160 if the you know if the the timestamp on the the you know the ID didn't match the one that you've 18:19.160 --> 18:24.200 configured then it would just give you and you know like don't trust this chain basically 18:25.160 --> 18:30.280 I'm not sure how if I've got 10 okay I was going to do a very quick sort of demo of the 18:34.280 --> 18:39.560 the the back end so we haven't tried to sort of build any graphical light interface or anything 18:40.600 --> 18:45.640 I'll just show you so this is the DID this is the same DID that is being verified here but 18:46.520 --> 18:56.280 on the on a full this is like a full installation a full node we we can basically just use 18:56.280 --> 19:00.840 this command line interface so it has commands for working with DIDs and credentials 19:00.840 --> 19:06.840 issuing signing and verifying credentials and then a challenge response system for creating these 19:07.640 --> 19:16.280 downstream DIDs so if I just I mean you can do things like so I say DID I want to verify 19:16.280 --> 19:23.080 and then I put in my DID which I've got in a environment variable and then it basically does the 19:23.080 --> 19:28.120 same thing but and you can do a lot more stuff obviously with the with the full the full installation 19:28.120 --> 19:35.720 but it's essentially the same as on the the mobile quick word about like the text stack we're using 19:35.720 --> 19:43.000 so we're building we've built the whole thing in in rust we're using the spruce ID libraries SSI 19:43.000 --> 19:47.560 libraries which are fantastic we relied on them a lot and also rust Bitcoin to do the 19:48.840 --> 19:53.800 interact with the Bitcoin client I on is the DID method that we're wrapping around so 19:53.800 --> 20:00.200 first chain is a DID method but it's a thin wrapper around the ion method which uses IPFS and 20:00.200 --> 20:06.920 Bitcoin under the hood and then the mobile app is written in Dart, Flutter and Dart and just to 20:06.920 --> 20:11.800 yeah give give credit to spruce ID again because we we've fought their credible wallet I think 20:11.800 --> 20:16.360 it's not it's just called wallet now but I'm not going to have time to talk about all the 20:16.360 --> 20:20.920 different features but you basically this model you end up with some really cool features you can 20:20.920 --> 20:27.080 sort of impose constraints from the upstream to the downstream entities and then in the mobile wallet 20:27.800 --> 20:33.800 we implemented selected disclosure using reductable signatures which was going outside of the standard 20:33.800 --> 20:41.160 hopefully you know this was before the BBS stuff I think was fully lined out so yeah at some point 20:41.160 --> 20:46.920 we need to sort of update that to be more you know within within the standards but there are loads and 20:46.920 --> 20:54.360 loads of nice features of this of this kind of this model just finally to just say look please come 20:54.360 --> 20:59.560 and talk to us we're really interested in meeting open source devs who might want to get involved 20:59.560 --> 21:04.040 or especially use a group so if you know any any institution or if you're part of any group that 21:04.040 --> 21:10.040 might find this sort of thing useful and we can even do a live demo using some some mobile devices 21:10.040 --> 21:15.160 that we've brought so come and come and chat to us and that'll take you to the doc site. Thanks. 21:15.800 --> 21:25.080 Thank you. Thank you. I have about seven minutes if you have a question raise your hand 21:25.080 --> 21:29.160 Tim is going to repeat the question for the folks in the live stream in the recording. Tim is also 21:29.160 --> 21:32.120 a much better person than I am he's going to get me his deck so I can put into the 21:32.120 --> 21:35.560 Boston website later. I should have known better that's one of the charitable person. 21:35.560 --> 21:40.760 Anybody quite question right here. Hi. Hi. I'm from the system manager handle or 21:40.760 --> 21:46.200 compromise credentials. Yeah so compromise credentials so I mean we're focusing on the 21:46.200 --> 21:51.880 infrastructure the public key infrastructure so actual you know credentials is we're hoping that 21:51.880 --> 21:57.240 you know there are solutions that you know are being worked on to be honest I mean my view is 21:57.240 --> 22:02.920 that credentials probably should be quite short lived and so yeah replication of credentials we 22:02.920 --> 22:07.400 don't we have a solution we do have a solution like the DAD standard for revoking 22:07.480 --> 22:14.120 DIDs then there's a mechanism in fact having everything on chain and you know I 22:14.120 --> 22:19.720 will find all of the all of the DID operations that have happened since the start of the you know 22:19.720 --> 22:24.600 since the deployment initial deployment so that means the replication of DIDs and downstream 22:24.600 --> 22:30.440 DIDs is very is really nice because you can you can be sure that you've got a full list of 22:30.440 --> 22:36.840 revocations which in the web PKI is not always easy. Revocation of credentials I think the solution 22:36.920 --> 22:41.400 to that personally is is just giving short lived credentials which you then reissue rather than 22:41.400 --> 22:45.000 trying to sort of have revocation lists. 23:07.400 --> 23:14.440 Yeah yeah so the question the question is if the date is used as the kind of route you know to 23:14.440 --> 23:20.200 verify the trustworthiness what happens if someone just basically produce it publishes another 23:20.200 --> 23:25.480 Bitcoin transaction with essentially the same hash in it but then it would have a later date. 23:26.040 --> 23:33.160 Well I mean so that could that could be done I mean the the the premise is that the route 23:33.240 --> 23:38.360 authority is going to be able to share the correct date so so you would just expect that to 23:38.360 --> 23:43.480 have just been like just a waste of you know waste of Bitcoin someone's just published another 23:43.480 --> 23:48.360 it doesn't it doesn't harm the system it's just an additional sort of irrelevant transaction 23:48.360 --> 23:53.560 unless they can get other people to actually kind of look at it and think that that's the actual date 23:53.560 --> 23:58.280 but the thing is because the hash hasn't changed that means none of the data have changed so actually 23:58.280 --> 24:01.960 all they can do is just that's just another route to exactly the same information. 24:02.520 --> 24:05.560 Yeah we're only trying to share the public keys ultimately not the date. 24:10.680 --> 24:15.960 No I mean it would if if you've configured it to a given date then then you you have to find a 24:15.960 --> 24:20.280 DID with that date but if someone else just comes along and publishes that same one like you 24:20.280 --> 24:23.560 they can do it every day like you can do as many times as they want you're just going to ignore 24:23.560 --> 24:27.320 of those because you're going to find your you know the actual valid one. 24:31.960 --> 24:57.400 Okay so the question is about centralization and mining in the proof of work network so I mean this is 24:58.360 --> 25:03.880 I mean theoretically that that kind of attack could harm the Bitcoin network. 25:04.840 --> 25:11.400 I mean the the the way that that was designed that that Bitcoin's designed to be robust to that 25:11.400 --> 25:16.680 because of economic incentives basically you know those miners would be harming themselves by by you know 25:16.680 --> 25:21.160 so but you could have an attack like a nation state might decide to try to attack like that. 25:21.320 --> 25:26.520 I mean I think you know more and more Bitcoin is being seen as a as a layer that really isn't isn't 25:26.520 --> 25:32.680 you know that that 51% attack threat is actually you know becoming less and less of a risk I think 25:32.680 --> 25:40.040 I mean obviously nothing's you know absolutely you know perfect but I I don't I don't really worry 25:40.040 --> 25:44.280 about that I mean there have been times when mining concentration has increased but then usually 25:44.280 --> 25:49.400 um actually it might look like it's very concentrated but actually it's usually mining pools and then 25:49.400 --> 25:53.320 when those pools get too big then you know the individual miners can actually just migrate to 25:53.320 --> 25:58.200 different pools because again it's in their own interest so I mean you know that that's a criticism 25:58.200 --> 26:02.760 basically of the Bitcoin network and whether it actually works but it's it's kind of proved itself 26:02.760 --> 26:03.960 at this point in my view. 26:20.280 --> 26:39.080 Yeah so it's a good question yeah so yeah that's a great question so the question is about like 26:39.080 --> 26:43.240 you know you say no trusted to the parties but actually you've got this root of trust and then 26:43.240 --> 26:47.880 the other mem entities in the in the chains of trust they will you could think of them as trusted 26:47.880 --> 26:53.720 so what I mean is I don't want the the digital infrastructure used to support the system