[00:00.000 --> 00:18.840]  Okay, hey everyone, good to see you. I'm Florian May. I'm going to moderate the next 30 minutes
[00:18.840 --> 00:27.920]  on the Bitcoin security panel. Yeah, Bitcoin security is a really broad topic with a lot
[00:27.920 --> 00:35.440]  of different aspects that can be considered from like mining, hash rate, key handling,
[00:35.440 --> 00:42.800]  patch management, and Bitcoin core and other implementations. There's a lot of FUD going on.
[00:42.800 --> 00:50.440]  So security by itself is always an interesting topic, but combined with Bitcoin it gets even
[00:50.440 --> 00:57.480]  more interesting. I'm really happy to have you guys here. I don't think any of you needs an
[00:57.480 --> 01:03.040]  introduction. I'm a big fan of your work. We have hardware, we have software experience,
[01:03.040 --> 01:11.080]  which is really great. And to start the discussion, I want to start with an open question to the round
[01:11.080 --> 01:22.000]  to get started. Like what aspects of BTC or around BTC or maybe crypto in common, but obviously with
[01:22.000 --> 01:28.880]  BTC as focus, do you think especially important right now to address what should the community
[01:28.880 --> 01:35.360]  and companies working on Bitcoin focus on? Maybe Pierre, can you start? Yeah, certainly. I mean,
[01:35.360 --> 01:43.360]  this is a really good question and there are many aspects affecting the security of Bitcoins and
[01:43.360 --> 01:51.400]  the holdings in general. I, as you know, specialize more in the vulnerability side with a good
[01:51.400 --> 02:00.120]  understanding of the cryptography. So I'm more looking at the vulnerability side, the health of
[02:00.120 --> 02:08.880]  the networks, the clients, and not running into issues based on that. The good thing though with
[02:08.880 --> 02:15.040]  Bitcoin is because of proof of work, even though there's vulnerabilities, there's no way to like
[02:15.040 --> 02:19.960]  kind of reverse transaction, right? That easily because you need to redo the proof of work even
[02:19.960 --> 02:27.280]  though there would be like exploitation of nodes. So this is very reassuring. And then the thing
[02:27.280 --> 02:33.880]  that gets to me on the other side are the clients, the holding and not losing the funds because I
[02:33.880 --> 02:43.600]  always get asked, I'm worried about my Bitcoins being stolen. But I, you know, tell people you
[02:43.600 --> 02:49.000]  should worry about not losing them first. That's like the there's much more Bitcoins that are just
[02:49.000 --> 02:57.760]  lost than actually stolen. So those are like the aspects that I, I'm focusing on that I think are
[02:57.760 --> 03:04.520]  important. So there's technical aspects like, you know, securing, you know, key management where
[03:04.520 --> 03:12.000]  there's basically like there you're talking about cryptographic barriers to be able to actually do
[03:12.000 --> 03:17.160]  anything. But then besides that, you have like game theory and you know, like incentive kind of
[03:17.160 --> 03:20.800]  things that prevent people, bad actors from doing stuff. And then you have like, you know, the
[03:20.800 --> 03:27.280]  social layer, people actually, you know, trying to manipulate the narrative and manipulate
[03:27.280 --> 03:33.560]  markets. And then I think that in this space, we've actually seen a lot more people hurt by
[03:33.560 --> 03:41.760]  either losing their keys or by falling prey to the social engineering more than people stealing
[03:41.760 --> 03:46.600]  keys. Not that that's not to say that we should not be careful securing keys. But I think, you
[03:46.600 --> 03:51.320]  know, unless like you're a really big exchange, you know, which kind of, you know, is going to be
[03:51.320 --> 03:57.080]  a major target. Attacks against individuals for stealing keys other than ransomware attacks or
[03:57.080 --> 04:01.840]  other stuff like that have been relatively rare. So I'm more concerned, I mean, when I first
[04:01.840 --> 04:08.880]  started working on stuff on Bitcoin software, I was mostly focused on how to secure keys and
[04:08.880 --> 04:14.880]  how to make sure that key management was done in an environment that's secure. But as I started
[04:14.880 --> 04:20.840]  to see more things that could potentially lead to game theoretical issues or consensus failure, I
[04:20.840 --> 04:24.800]  started to focus more on like the, you know, the issues with forks and issues with different
[04:24.800 --> 04:30.080]  kinds of, you know, market manipulations and things like that. So I think all these things need to
[04:30.080 --> 04:32.800]  be taken into consideration.
[04:34.800 --> 04:40.520]  Yeah, so I've spent the past few years mainly working on key management side, three years doing
[04:40.520 --> 04:47.760]  more enterprise hot wallet key management, and now focusing more on personal key management. So
[04:47.760 --> 04:54.440]  obviously, I feel like this is where I can best put my skills to work and try to help people
[04:54.440 --> 05:01.520]  basically be more sovereign to themselves. There's a number of other issues at play, though.
[05:01.520 --> 05:08.320]  Something that plays into that is actually the usability of having a high security solution.
[05:08.320 --> 05:14.960]  And really, I think one of the results of having not so good usability is that we result in
[05:14.960 --> 05:20.480]  creating more systemic risk in the system. You end up with more people basically leaving their
[05:20.480 --> 05:25.600]  keys with trusted third parties, usually because they don't trust themselves. And in many cases,
[05:25.600 --> 05:30.040]  maybe they shouldn't trust themselves. But, you know, I think the goal is that we should be
[05:30.040 --> 05:34.440]  trying to get to a point where people should be comfortable being their own bank, trusting
[05:34.440 --> 05:39.120]  themselves. I could go on, but I think that's enough.
[05:39.120 --> 05:46.200]  With Bitcoin, we have a wonderfully designed cryptographically system, which is, from my
[05:46.200 --> 05:52.520]  point of view, very secure. But at the same time, we need to also invest in the usability of
[05:52.520 --> 06:00.000]  such systems, because without a good usability, I think you couldn't have a very good security.
[06:00.000 --> 06:04.960]  The product or the project can be very secure, but if users don't know how to use it properly,
[06:04.960 --> 06:11.760]  then we failed, ultimately. And that's what we are trying to solve in a software or hardware
[06:11.760 --> 06:21.120]  wallet space. We need to educate the people what actions they are doing, what the effects of
[06:21.120 --> 06:26.960]  these actions will be. And also, there are a lot of things that can be improved, like, for
[06:26.960 --> 06:34.720]  example, people are blindly scanning QR codes, sending Bitcoins to this, and they don't check
[06:34.720 --> 06:40.800]  the address. The address itself is a problem, because there is no really straightforward way
[06:40.800 --> 06:46.160]  how to confirm that the recipient address really comes from the person we want to send
[06:46.160 --> 06:55.600]  the coins to. And there are a lot of work to do, even non-trivial work, because it kind of
[06:55.600 --> 07:04.720]  relates to the whole digital identity management thing. And I think this is something that should
[07:04.720 --> 07:11.040]  be improved, and it's not really related to the hard core cryptography security, but it's also
[07:11.040 --> 07:19.280]  very important if we want Bitcoin to be used not just by hard core cryptography nerds, but everybody.
[07:19.280 --> 07:26.400]  Okay, thanks. That was really interesting, and I think I got two keywords that kind of triggered
[07:26.400 --> 07:33.600]  me that were, obviously, education is one point where we have to work on as a community, but
[07:34.640 --> 07:42.000]  ultimately, I feel there's always a limit to education, what you can make non-technical
[07:42.000 --> 07:46.960]  people understand with what the current state of Bitcoin and the whole cryptosphere is. I mean,
[07:46.960 --> 07:52.880]  you have scammers telling people to enter some commands into the debug console of their wallets.
[07:53.920 --> 08:00.880]  We have supply chain attacks. We have different channels where people, like on Discord and Slack,
[08:00.880 --> 08:07.600]  where people get ripped off all the time. We have exchanges where, obviously, input validation is
[08:07.600 --> 08:12.880]  done on the client side and cryptography. So there's so many different layers going on
[08:12.880 --> 08:20.000]  with problems that cannot be solved at once, but I would be interested, especially in your opinion,
[08:20.000 --> 08:26.800]  James, in our experience, and yours, Pavel, what the current feedback from your customers and
[08:26.800 --> 08:35.280]  buyers is, maybe early adopters of CAESAR, not only the small ones, but also the institutional ones,
[08:35.280 --> 08:40.800]  what the problems are, the typical ones that you actually plan to address.
[08:40.800 --> 08:48.720]  Yeah, it's actually, I guess, one of the first major points is that it's loss is the biggest
[08:48.720 --> 08:58.240]  problem. And so this is because we have made great advances, like with Trezor, with hardware
[08:58.240 --> 09:04.960]  devices, making the private keys much safer from digital attackers. Just getting an air gap in
[09:04.960 --> 09:12.000]  there goes a long way. And so then what we're really dealing with now is probably one of the
[09:12.000 --> 09:18.320]  biggest security issues is really one of the biggest issues with any type of computing
[09:18.320 --> 09:23.920]  environment is always that dang user that keeps getting in the way and screwing things up. And
[09:23.920 --> 09:30.320]  we have yet to figure out how to eliminate the user from the equation, so we have to do the next
[09:30.320 --> 09:35.360]  best thing and try to prevent the user from shooting themselves in the foot in as many ways
[09:35.360 --> 09:42.240]  as possible. That's really one of the primary focuses that we have at CAESAR, where we're not
[09:42.240 --> 09:47.280]  trying to build any hardware ourselves. We're taking what's already out there on the market and
[09:47.280 --> 09:55.280]  trying to assemble it in a new way with software that just implicitly by following the software
[09:55.280 --> 10:01.680]  itself, you have to follow a number of best practices. So we don't necessarily have to do as
[10:01.680 --> 10:07.360]  much education. It's just baked into the product itself.
[10:07.360 --> 10:15.680]  From our experience with our Trezor support, I can tell that there are two big issues that happened
[10:15.680 --> 10:23.200]  during the last year. One of them is not specific for the last year, but I still feel that people
[10:23.200 --> 10:29.200]  don't really understand that the recovery seed or the mnemonic sequence is really, really
[10:29.200 --> 10:36.320]  important, and they just decide to, for whatever reason, not write it down. There are some counter
[10:36.320 --> 10:43.280]  measures, like, for example, requiring a person to give back some of the words they have written
[10:43.280 --> 10:50.320]  down, but still, it doesn't really mean they have not thrown away the paper shortly afterwards.
[10:50.320 --> 10:58.320]  Also, we had one example that a person wrote down the seed, but they didn't know they should
[10:58.320 --> 11:06.000]  really write down it in a correct order, so they just tried to be smart and randomised it for
[11:06.000 --> 11:08.000]  whatever reason.
[11:08.000 --> 11:12.000]  Oh, but you can brute force that with the right script, right?
[11:12.000 --> 11:19.440]  Yeah. And so I think that could be solved by education, and it's really a much bigger issue
[11:19.440 --> 11:26.800]  because we tried to educate people not only to use Bitcoin properly but to stand for themselves,
[11:26.800 --> 11:32.800]  and suddenly they have their faith in our own hands and they are not really used to it.
[11:32.800 --> 11:41.440]  And the other thing was, well, from the last year, it has been a year of Bitcoin forks,
[11:41.440 --> 11:48.720]  at least that's how I perceived it, and a lot of people are really hasty about trying to
[11:48.720 --> 11:57.680]  claim new coins and they were entering their mnemonic seeds to lots of various websites with
[11:57.680 --> 12:08.880]  no history whatsoever, and also it created a lot of problems because they somehow managed to
[12:08.880 --> 12:12.080]  send coins to where they should not really appear.
[12:12.080 --> 12:19.040]  For example, if you have a big cache, you claimed your big cache from the main Bitcoin chain,
[12:19.040 --> 12:24.400]  and then you accidentally send it to a SegWit address because the exchange gave you a SegWit
[12:24.400 --> 12:31.920]  address and there was no really easy way out of it, so there was a coin loss because of lost
[12:31.920 --> 12:38.160]  mnemonic and a coin loss because of coins being sent to somewhere they really shouldn't belong to.
[12:38.160 --> 12:46.560]  Okay, thanks. Maybe another indirectly related question, maybe you can even start with that
[12:47.440 --> 12:54.960]  because that topic keeps popping up, at least in my talk with people, how to deal,
[12:55.680 --> 13:00.240]  especially in your case, with supply chain attacks. What does Trezor do about it? What
[13:00.240 --> 13:05.520]  do you think about, I think the typical questions are trusted element within the hardware,
[13:05.520 --> 13:11.040]  secure stickers with holograms on it, all that kind of stuff.
[13:11.040 --> 13:17.600]  Yeah, so let me first explain what supply chain attack is. It's basically when you order a device
[13:17.600 --> 13:23.760]  and someone intercepts it on a way and they replace some of the critical parts with tainted one,
[13:24.480 --> 13:30.800]  and obviously there are more ways how to do it. One of them is to introduce some kind of
[13:30.800 --> 13:38.160]  a attestation element which is able to say, hey, I'm a legit hardware. This creates
[13:41.040 --> 13:46.400]  automatic trust to the hardware vendor and by hardware vendor I don't mean the hardware
[13:46.400 --> 13:54.240]  wallet vendor but the producer of the chip it is using. I'm not really comfortable with that
[13:54.240 --> 14:03.280]  because from my experience this stuff mostly works but then it comes a moment where it stops
[14:03.280 --> 14:13.920]  to work and this happened last year where a very smart computer cryptography expert and hacker
[14:14.960 --> 14:21.440]  found a bug in our competition which uses a secure element and he basically broke down
[14:21.440 --> 14:27.840]  their attestation model and this is really hard to fix because once you have a million devices out
[14:27.840 --> 14:35.840]  there, you can either not fix the bug or replace all of them and it's a big problem. Another problem
[14:35.840 --> 14:45.120]  is some of the platforms use Intel SGX secure computing platform and there are a lot of attacks
[14:45.120 --> 14:52.640]  related to Spectre and meltdown attacks which can be also applied to this so it's I'm not saying
[14:52.640 --> 14:59.360]  it's a bad solution but it has some drawbacks and if you rely on it, it's very hard to fix
[14:59.360 --> 15:05.440]  because it's embedded in the hardware. What we use is what you mentioned we try to protect
[15:05.440 --> 15:12.080]  the supply chain by applying various physical features like for example we are applying holograms
[15:12.080 --> 15:19.200]  on the device and on the on the box. This also has its drawbacks and one of the main drawback
[15:19.200 --> 15:26.160]  is that we really need to educate our users what should they look for, how the packaging looks like
[15:26.160 --> 15:36.160]  and of course this is also not 100% temper proof because somebody can try to copy it in a very good
[15:36.160 --> 15:43.440]  way and there is a basically there is a race how good your holograms are for example.
[15:45.120 --> 15:49.680]  I think that you know one takeaway from you know what stick is talking about of even all of these
[15:49.680 --> 15:55.760]  hardware vectors that are getting exposed over time is that the idea of secure computing is a
[15:55.760 --> 16:02.000]  fallacy. I mean it's you know fantasy land it's not going to happen at least not anytime in the
[16:02.000 --> 16:08.560]  foreseeable future and so the best thing that you can really try to do is eliminate as many single
[16:08.560 --> 16:15.680]  points of failure as possible and so this is one reason why we actually recommend with our multisig
[16:15.680 --> 16:20.960]  setup using you know a variety of different brands you know instead of just buying three treasures
[16:20.960 --> 16:28.720]  use a treasure, a ledger, a cold card and really spread out the risk because it's not possible
[16:28.720 --> 16:33.120]  even for like hardware level experts such as himself you know some of these devices are black
[16:33.120 --> 16:38.240]  boxes you know he doesn't know what's going on inside of like the ledger hardware there's
[16:38.240 --> 16:42.720]  probably you know only a handful of people on the planet who do and there's no way that we
[16:42.720 --> 16:48.480]  can expect to ever be able to really get any level of trust you know at the like hardware
[16:48.480 --> 16:55.200]  level like that. I would like to add to this because the supply chain attacks traditionally
[16:55.200 --> 17:03.360]  uh the hardware secure modules like they were not popular at least the you know the people
[17:03.360 --> 17:08.240]  in general and uh there's a big difference between buying an off-the-shelf computer
[17:08.880 --> 17:14.480]  turning it into something you know is most likely clean because you know obviously this
[17:14.480 --> 17:19.280]  computer was not specifically targeted because computers are used for general purpose and
[17:19.280 --> 17:28.080]  and uh you cannot assume to be able to hack all of them without being detected so or or um you
[17:28.080 --> 17:35.120]  can go at the store and buy it um the problem with the hardware outlets that they're facing
[17:35.120 --> 17:39.680]  is that they're obviously will be targeted just because they are hardware wallets for
[17:40.320 --> 17:46.640]  bitcoins so uh and the Kessa huddle I assume there's also advice maybe to add a device that
[17:46.640 --> 17:53.280]  is not a hardware wallet uh in the multi-sig scheme. Yeah I mean definitely I mean I love
[17:53.280 --> 17:58.560]  Trezor products but um I have to agree that uh I think um you know one of the issues is that
[17:58.560 --> 18:04.720]  they will be specifically targeted um I I've tended to like to use um you know um airgapped
[18:04.720 --> 18:08.320]  computers that are not that are general purpose that you know are it's hard for someone to
[18:08.320 --> 18:12.800]  specifically target that machine and also to use a different operating systems or different
[18:12.800 --> 18:16.720]  distributions of operating systems in case one of them gets hacked um in the case of like for
[18:16.720 --> 18:20.640]  instance bitcoin nodes usually don't want any kind of divergence there because you want them to
[18:20.640 --> 18:26.000]  reach consensus but in the case of using multi-sig um basically every single uh additional uh you
[18:26.000 --> 18:31.280]  know signature that you require is another thing that needs to be hacked so so you're adding more
[18:31.280 --> 18:36.160]  security with with more different kinds of platforms. Just to be clear I trust Trezor and
[18:36.160 --> 18:41.680]  this is what I give to family members so. Thank you. Yeah that's a good point. I just wanted to
[18:41.680 --> 18:48.000]  add that I think it's very wise to combine various security options and security layers
[18:48.000 --> 18:54.640]  so if you combine a hardware wallet even multi-sig you are getting uh the best of both worlds or
[18:55.440 --> 19:03.840]  security of the both worlds uh the bad thing about this is uh you are also getting the minimum
[19:03.840 --> 19:11.600]  usability so you combine the usability but in opposite way so uh I'm not not saying it's uh
[19:11.600 --> 19:17.920]  it's not a thing to do but there it has some drawbacks. Oh yeah it's it's going to be very
[19:17.920 --> 19:23.280]  difficult for us at CASA to uh to both advise our clients to eliminate and eliminate these
[19:23.280 --> 19:30.000]  single points of failure and for us to support all the shitcoins. Yeah that's that's a very good
[19:30.000 --> 19:36.000]  point. Uh I have so many questions left on my on my book but we have only so much time so um
[19:36.000 --> 19:43.360]  uh when why we have you here um I'd love to hand over to the crowd now for a couple of questions
[19:43.360 --> 19:50.640]  so you can pick uh the brains of the experts with uh your security questions so feel free to
[19:51.360 --> 19:55.600]  raise your hand if you have a question related to bitcoin and security now.
[19:57.360 --> 19:57.680]  Please.
[19:57.680 --> 20:04.560]  Yeah maybe can we get this guy a microphone please.
[20:09.840 --> 20:12.080]  Thanks. Yeah.
[20:17.520 --> 20:22.640]  Uh I want to ask about the multi-sig three or two of three setup with the three different
[20:22.640 --> 20:31.200]  hardware bots uh what software do you use like Electrum or more just roll CLI or there's some
[20:31.200 --> 20:37.200]  review software that I could use for this multi-sig wallet or or just I shouldn't care because the
[20:37.200 --> 20:42.880]  wallet is secure enough that it doesn't matter. Uh well I mean I I would not assume that the
[20:42.880 --> 20:48.000]  software is secure though you know if it's open source you're gonna have a better guarantee uh for
[20:48.000 --> 20:55.360]  usability I've set up multi-sig hardware uh based wallets with Electrum and it was pretty easy uh
[20:55.360 --> 21:00.640]  the most difficulty that I had was doing it on Linux and having some issues getting all of the
[21:00.640 --> 21:07.440]  the libraries installed to support but uh other than that um it it's uh if you're if you're tech
[21:07.440 --> 21:12.800]  savvy then it should only take you a matter of minutes or maybe an hour at most to set up. So
[21:12.800 --> 21:19.360]  one other question is that uh what I saw is that for the ledger I can't see the the address the
[21:19.360 --> 21:25.840]  multi-sig address on the ledger itself for Trezor and keep it implemented so I thought implementing
[21:25.840 --> 21:31.520]  it because I think it's important part to be able to verify it but. Right and you know I'm not entirely
[21:31.520 --> 21:36.880]  sure of the details of why that's not supported I mean I think that's something that we just need
[21:36.880 --> 21:44.240]  to annoy them. That's probably not done but I personally I just also use Electrum mostly
[21:44.240 --> 21:50.000]  I think they're even implemented in the uh assistant in the base one so. I would just
[21:50.000 --> 21:58.320]  shortly add to it uh it's a good idea to use uh any software wallet that uh has hardware wallet
[21:58.320 --> 22:05.920]  support for multi-sig and at the same time it's open source uh it has been set Electrum three times
[22:05.920 --> 22:13.920]  uh I'm saying Electrum is fine but do your own research there are other options uh for example
[22:13.920 --> 22:19.360]  yesterday we had a talk with uh green address I think they also support uh hardware wallets and
[22:19.360 --> 22:26.880]  multi-sig at the same time. Any more questions from the audience on the other side?
[22:26.880 --> 22:41.760]  Get your sports in. Hi just talking about uh the open source and some more eyes can see and verify
[22:41.760 --> 22:48.080]  that uh the software is clean and bug free or doesn't have something. Is there any formal
[22:48.080 --> 22:55.760]  uh process to this like how many developers have looked at Electrum have looked at Trezor and.
[22:57.840 --> 23:03.760]  Those are that's a good question uh but you know no um really the the best metrics that you might
[23:03.760 --> 23:09.280]  be able to get is uh if you're looking on github and looking to see um number of forks number of
[23:09.280 --> 23:15.200]  stars number of total contributors I mean that will give you a general idea um you know hopefully
[23:15.200 --> 23:19.520]  uh you know at least the number of contributors or people who have looked at at least part of the
[23:19.520 --> 23:25.360]  code because presumably they then you know added or deleted some code um but yeah just some like
[23:25.360 --> 23:31.120]  general activity uh but that's only really gonna give you relative ideas by comparing between the
[23:31.120 --> 23:38.720]  different projects uh there is no metric you know for open source security other than probably
[23:38.720 --> 23:45.200]  general usage um so like if we know which I I don't think that we even do but if we knew that
[23:45.200 --> 23:51.280]  you know so many million number of people uh are using this software and you know have not gotten
[23:51.280 --> 23:58.480]  exploited uh the more people that are using it the you know the more uh value basically is up for
[23:58.480 --> 24:03.920]  grabs for an attacker to come in and try to steal from them so if the more and more people that are
[24:03.920 --> 24:09.440]  using it and not seeing any exploits gives you you know a general better sense of reliability but
[24:09.440 --> 24:16.640]  there's still no guarantees yeah let me add to it there is no formal process uh uh for trezor and
[24:16.640 --> 24:22.880]  I don't think there is any for uh one of our competitors uh one of the reason is partially
[24:22.880 --> 24:27.920]  that there are not a lot of people uh developing this stuff like there are maybe up to 10 people
[24:27.920 --> 24:34.560]  developing trezor I think it's the same or even worse for other hardware wallets um not sure how
[24:34.560 --> 24:42.640]  many electrum contributors has but also it's not not a big number so I think the good thing is to
[24:42.640 --> 24:47.600]  for the general bitcoin community to look at the commits uh for open source projects because
[24:48.400 --> 24:55.440]  every everything we deploy as a firmware to our users is uh being published before on a github
[24:55.440 --> 25:03.440]  as a part of uh of the commits so if there are a lot of people reviewing it we can start uh
[25:03.440 --> 25:10.640]  formalizing some kind of process but right now I'm not sure if it's even possible like internally
[25:10.640 --> 25:19.120]  at our company uh we have a rule that uh one shouldn't merge uh the the commit if if if it
[25:19.120 --> 25:24.240]  was written by by the same person so someone else has to merge it and I think it's a good rule
[25:24.240 --> 25:32.320]  but this is as formal as uh we can get uh at the moment I guess. Okay thanks that was uh was a
[25:32.320 --> 25:38.240]  really great insight um maybe uh one addition from from my side that the usual slogan applies
[25:38.240 --> 25:46.400]  don't trust verify if you can't maybe just avoid any bleeding edge stuff use uh uh the providers
[25:46.400 --> 25:51.040]  hardware wallet providers software wallet providers or software providers in common in the space that
[25:51.040 --> 25:59.360]  have a good reputation ask around uh be careful and yeah stay safe um unfortunately the time is
[25:59.360 --> 26:06.000]  already running out so I have to close around um thank you very much for your thoughts and input
[26:06.000 --> 26:20.960]  um I hope you found it also