Live from the San Jose Convention Center. Extracting the signal from the noise. It's the Cube. Covering Hadoop Summit 2015. Brought to you by headline sponsor Hortonworks. And by EMC. Pivotal. IBM. Pentaho. Teradata. Syncsort. And by Atunity. And now your hosts John Furrier and George Gilbert. Hello everyone. Welcome back to the Cube. Live in Silicon Valley at Hadoop Summit 2015. This is the Cube, our flagship program. We go out to the events and extract the signal from the noise. I'm John Furrier. With my co-host George Gilbert, our big data analyst at wikibon.com. And our next guest is Adriana Zumbieri, Program Director. Big sequel and virtualization development at IBM. And this is a big title. Call on card. Yeah. A lot of people. So a lot of responsibility. Welcome to the Cube. Thank you. So IBM is making a lot of moves. Obviously, we've been covering on the IBM events with the Cube. So you know, we're briefed on everything you guys are doing. Certainly great story. Cloud mobile social, big data, big part of it. We've done zillions of crowd chats with the team. IBM and big data kind of synonymous. A lot of players coming in, got Oracle, got EMC, HP. It's big data is in every enterprise. I mean, gardeners report about Hadoop. 50% going to be buying and evaluating production Hadoop. Still a big number. So a lot of push on Hadoop. You guys have a huge investment going on with Spark. We'll hear more about that on Monday. Bloomberg released a little bit of teaser on that, kind of breaking that out, breaking the news. But what's going on? I mean, there's a lot going on in analytics. It's not just unstructured data. There's still SQL out there. There's still the engine, but there's open source here. Presto from Teradata is out there. Open source is booming. What's going on with IBM? Give us a quick update on IBM analytics, SQL on Hadoop, et cetera. Well, actually, I think that in the world of big data, one of the things on why we have maybe a slow adoption at the beginning and now it's exploiting is it's hard for people to actually make a mindset where you have a complete new technology. But in companies, they need to invest in new skills. They have a lot already writing on SQL in their own companies with their warehouses. I don't think that warehouses are going to go anywhere anytime soon. Obviously, there are things that Hadoop is great for, but there's also all these investments they have. So I think that SQL provides really our customers with a very easy way to reuse the existing skills, the existing applications, and be able to exploit this new world of big data in many, many ways. So I think that's why and last year, Merve already Adrian here at the SQL summit commented on 2015 is the year of SQL and Hadoop. There are like so many vendors today out there with a SQL solution on Hadoop. What we have done in IBM with big SQL is we have been investing on SQL technology for decades. So we know how to do SQL. We invented it. Actually, I like to brag about that once in a while. So what could we do for Hadoop? And that's what we did with big SQL two years ago. We took all the technology we had and we teach it Hadoop. So as you were saying, there's more than a dozen solutions or products to SQL and Hadoop. What made it so easy for that sort of technology to diffuse to so many organizations? And then what's unique about IBM's implementation? I think what's unique with us is we took the approach that it was a little bit different than the other major database vendors because we think that Hadoop is an open ecosystem where we need to share. So big SQL, even though we are actually given a very mature technology in terms of the engine, we don't have any proprietary data formats, right? We're completely open. Like Parquet. We actually support all data formats that exist today. We don't have one that is prepared to IBM. So we play nice in that sense. We support Parquet or C, any other data format today out there. At the same time, we actually have a very strong optimizer and all the technologies you can expect from a traditional relational engine. We have a very powerful SQL itself, like the expressiveness of the SQL is one of the keys in this world. In the broad coverage of the whole language. Exactly. We have the same coverage that we expect in a regular traditional data warehouse. And why is that important is not only for the expressiveness of the SQL you can actually have, but for the simple fact that you can migrate your applications with very, very low effort. You don't have to modify to adapt to the limitations you have in your SQL. You can use existing third-party applications and now wrap them on Hadoop with zero effort. So that's why it's actually really set us apart. So we love the SQL on Hadoop because it's a dynamic environment. We even covering companies like Hedapt, which got acquired by Teradata. It was a big thing. Every year it's a shiny new toy. It's streaming here and all this is going on, but they didn't make it a standalone company. They were acquired Hedapt in particular others. Why is it such that SQL on Hadoop can't fund a startup to be successful? Is it because it's just a feature or is it because it's part of a bigger picture? Is it an existing market space? Is it hard? All the above? Why is it difficult to launch a company to corner the SQL on Hadoop market? Well, I think that SQL is something that, as a language, is very simple in the sense that you can write a parser and have a SQL engine. But what you really need to make it successful is a lot of technology that behind it. The Optimizer that we build, the Cosmet Optimizer, the query rewrites we have, all the smarts behind having a SQL engine, security, auditing, it's not something you can write in a couple of months. It's something that it takes years and it takes a lot of technology to make it happen. Oracle reminds us that they've been working on it 37 years and counting. But John raises a point which is we have maybe two dozen of products that are out there. If they're not standalone, what sort of platform should they sort of be part of to make a use case that's an analytic data pipeline? Should it be an integrated SQL DBMS? Should it be sort of deconstructed into something that's a query engine, machine learning, streaming engine? All the things Oracle, for instance, baked together. Are we unbundling that? What is this going to look like? Well, I think that you need obviously an ecosystem of things to do. You cannot have a hammer and use only one tool for everything. You need different tools for different things. And SQL is one of those tools. But you need many others. You need streaming and you need, now everybody's talking about Spark, which is a great MPP engine that is very general. But there are things in the SQL engine that I think that you need for customers to do. For example, one of the things that I believe it's important to have in this SQL on Hadoop is federation. So customers want to issue queries. And they want to issue queries against their Hadoop. But they also want to bring their data from their existing data warehouses, Oracle data. That's, for example, one of the things that we have with big SQL that is unique in this space. And I think it was one big differentiator. So there are enterprise capabilities.  And we brought a mature solution for SQL on Hadoop. So about Spark, what's the impact of Spark? Because what we're now seeing is SQL on Hadoop, you got Spark, you have all kinds of other potential software innovations happening in and around the data. So the tooling is there. I agree, there's multiple tools in the tool chest. How do customers deal with this? Because we talk about SQL on Hadoop. Our customers saying the same language, give me SQL on Hadoop. And how do you guys manage the engineering projects around that? So from a customer standpoint, what are they looking for? What's the language of the customer? And how does that translate into engineering? Well, we work with a lot of customers to try to understand what trying to do around analytics, right? And different customers like have different views on how to do analytics. There are customers that actually like to do analytics only through SQL. There are other customers that say, no, I'm going to move into something else like our Spark. So obviously, we want to try to cater to all the groups as much as we can. One of the things we're doing with Big SQL right now is we'll try to integrate with Spark. We don't need to compete with Spark, right? What we want is we want to be able, for example, in any data flow that you have, instead of calling Spark SQL, be able to call Big SQL. And with that have all the extra functionality and power that you can have with Big SQL. Or from Big SQL, you want to be able to call any Spark application and get, you know, our database back and continue processing on SQL. So they're complementary. But again, it depends on what customers are doing and how they want to invest themselves. How about federation? That's come up in the conversations in the past, federation of access, federation of data. How do you guys view that as a guiding principle? What's the mindset at IBM? We look at the data out there and the access to the data, software applications. And now with the tsunami of apps coming, workloads having technology under the covers like virtualization and other things. There's a data issue out there. Well, I think that having the opinion that, you know, all the data will move into one place is very naive. I think that, you know, when you talk to customers, especially with very large data warehouses, nobody wants to go to one place. Many customers have multiple data warehouses from different vendors.  So we needed a way to give customers the ability to access all that data. We don't have them to move the data. That's why virtualization comes in place. And that's why I think that if you have that capability coming from the big data world into the rest, I think it's very powerful because, you know, when you actually do that, you have to have some intelligence. You can actually go, you know, send the query and just bring data back. You need to have some intelligence how to create that plan and trying to minimize data movement. And I think there's a lot of technology we have in IBM having for years that we actually do that. I guess I'm understanding your title differently now as opposed to virtualization like hypervisor, you know, abstracting the OS or the server. It sounds like you mean data virtualization. And that's something that the other sequel on Hadoop engines, with the possible exception of Presto, we haven't really heard much about. Tell us some more. That sounds like that's great. And it's a great trend too.  Yeah, virtualizing data is interesting, right? Because now you can do things with data completely agnostic of where it travels. Correct. And I think that sometimes when, in particular around Hadoop, that some people want to use Hadoop as a sandbox. They want to actually play with the data, try to understand it. And they don't want to have to move the data around from their warehouses in order to actually try to understand. Now, maybe once they actually play enough, they actually decide to actually move the data. But what you're actually creating, you don't want to move that data around. You just want to do the query and let the data live what it is. So from big sequel today, you can access in the same query data from Teradata, Oracle, NetEase, DB2, DB2Z. But this is like, I guess the techie term is non-trivial. No, it's not. IBM started earlier, but if Oracle worked 37 years on its query optimizer, that's when it knew where the data was within Oracle itself. Now, if you have to go figure out where all the data is outside IBM or the IBM engine, for one, that sounds like it's a platform for a broad scale of analytics. But two, it sounds like a very large effort. We have had technology to do this under Federation server for a very long time. And we have a very smart optimizer that knows how to decompose queries and only send the pieces of queries that make sense to the other data sources and exploit those servers to actually do part of the work and minimize the data travel. So it gets incorporated. So that's technology you've had and you're bringing it over to... Correct. I think that we have been reusing a lot of the technology and that we have developed over the decades and now applying it to Hadoop. That's why we bring very mature technology into a very new market and makes us very different. So will this... Will BigSeq will be the foundation for your analytic apps or will there be other engines? I think that there is no more one answer to this. I think that, again, it really depends on how customers want to deploy in their shops. There will be certainly a big number of customers that want to still keep SQL at their center of their universe and where they are for them. But there will be customers that want to move into the new thing and will be there for them too. That's the great thing about IBM, right? We can have, I wouldn't say all, but we are a large company. We come from a big ecosystem. So big data has become fashionable and well explained to some extent over the last few years. Fast data is becoming something that we need to consider in terms of time from sort of ingest to action. SQL isn't always assumed to be the way to do that. How should we think about fitting that into an analytic application? What do you mean by fast data? Fast data, where between the time you ingest it or capture it and the time when you can use it to make it drive a decision? We're talking about streaming data, streaming data, streaming analytics. We do have infosphere stream that we have a solution for that within IBM. When you say SQL doesn't have to be the only answer, that's an example of... That's an example. Even within that, I think when we talk about SQL and Hadoop and talk about performance, last year, as I mentioned, there were something like 17 SQL engines on Hadoop claiming to be the fastest when I came to the Hadoop Summit last year. So when I went back to IBM, I said, you know, we have to do something about this. This is a wild west of everybody claiming to be... We got to beat their benchmarks. Yeah, so we actually published the first independent audited benchmark on SQL on Hadoop, which is publicly available. It was audited by an independent auditor, and we showed that we are faster and nobody has challenged that since last year when we published in October. A lot of startups are groping for that benchmark just to kind of have a flag flag to plant. Obviously, IBM's got big R&D, but I got to ask you to kind of end their segment. What's the coolest thing you're working on right now in terms of technology? I mean there's a lot of stuff you SQL on Hadoop.  People use SQL pretty standard. But now Hadoop gives more folks. I get that. There's going to be a lot of stuff orbiting around this, like Spark you mentioned. So what's the cool things that you're working on right now that you could share? I think there are two parts on cool. One is cool that it would be like from the marketing perspective, and also like from the application perspective, certainly our integration with Spark is one of the coolest things we're working on, right? I think that's interesting. But from the geeky side, it's very interesting to try to solve the challenges of having a SQL engine on top of something that was not meant to have a SQL engine on top, right? When you have to deal with, you know, how do you do collocated joins or how do you do certain things that are not meant to be? This is the virtualization part. No, this is actually how to run SQL on on on HDFS and on on a falsely on Hadoop that it was not meant to actually, you know, have the ownership. We don't have the ownership of the data that you have in a traditional data warehouse. Well, Spark does the same thing where stay away from storage. Yeah, but in the data warehouses, a lot relies on how you optimize your queries, knowing about how you distribute your data, where your data is, how you can actually collocate your joins. So there was a lot of technology underneath. So that's the geeky part, maybe. But in terms, I think your question was more... We like the geeky part. Bring the geek on. We get our geek on. We're getting a hook here. Okay, so quick summary as we end the segment. What is for the folks out there, what's the show about this year?  It's operationalized as you mentioned. What's this year's theme? Share with the folks watching. What's going on at Hadoop Summit? What does it mean for the big data ecosystem? What's the vibe? Where's it going? What's your forecast? I think that the big difference, at least personally for me from last year and this year, is last year we talked a lot about the technology and how we're building this technology. I think this year is more about what is people doing with it?  We have people doing real things. We have large customers exploiting it and seeing that they can answer questions that, you know, that could not even get answers before. Like today I'm talking with, I have a presentation I'm going to do here at the summit talking about what Seagate is doing with our, you know, sequel on Hadoop solution. I think that's very interesting to see how, you know, they are changing their businesses based on what the new things they can do. Awesome. IBM here inside the Cube sharing the insights, obviously analytics and if you're hungry and you don't know what to make, always call Watson up, they have the big data, they can tell you what recipes to make. Obviously a little play on IBM's Watson which has been a great example of how analytics fits the real world. The stuff under the cover, sequel spark, a lot of greatness coming. We'll see more next week. We'll see you in San Francisco Cube. We'll be right back live at Silicon Valley here at Hadoop Summit 2015. I'm John Furrier, George Gilbert, our big data analyst at Wikibon and go to crowdchat.net slash Hadoop Summit. Join the conversation. We'll be right back after this short break.


Okay, next on the agenda is a presentation from Larry Brody. Larry, do you want to share your screen and bring your slides up. Larry's presentation is in response to a request from council that came up at council initiated discussion, I think maybe back in February. And that was that the council said it would be informative and useful to talk about what kind of research activities related to the LC research program of NHGRI are going on across the NIH. So we tasked Larry with this responsibility to bring us this presentation. And are you ready, Larry? Yes, can you see my slides? I sure can. So can everybody else off to you then. Okay, thanks Rudy. Good afternoon everyone. I've probably heard this one of the first rules to show business never follow an act that features animals or children. So we're going to break that rule and follow an act that had a lot of animals going on. So you asked about information on LC and LC like activities. You'll see what I mean by that in a second across the NIH. So what I'm going to do is take you through mostly a very, very high level view of various activities going on at the NIH, and I'm going to do a little bit of a brief overview of the process of stopping to go to a lower altitude for some specific programs and some that are just examples of other things that are going on. And then address a little bit of how you can dig in and get into more details. So, but before I do that, I want to do a quick overview of our program just to set the scene a little bit about collaborations that we do with other ICs. And then show you a little exercise in data mining to try to answer the questions about what's going on in LC like research across the NIH in a much more agnostic way than some of the earlier work. If you were to ask this question of the NIH reporter, which I'm sure many of you are familiar with, it's a readily used public database. And you just simply searched the word biostics for active funding in 2020. You would find that 266 awards use that term. If you restrict that search to research grants, which is a function of the reporter interface, you'll find that there are 82 that use that term. And then you'll also find that 21 of those are actually our grants and HGRI support grants. That's really a very, very simplistic way of doing it. And you'll see that it's much more complicated. There's a lot of gray area when it comes to answering this question, what kind of LC work is going on at the NIH? One thing that I think I use this to illustrate is that the NIH, when you look across all the institutes, the center of gravity is clearly in things that they term bioethics. And hanging off of that are a little bit of legal research, again, mostly in our institute. Social science research related to bioethics, but lots of social science research that is not necessarily in the bioethics or the LC realm, as well as a very, a lot of larger programs in behavioral science. And I take the view that some behavioral science overlaps with LC research, but there's a lot of behavioral science research that's quite important, but not considered LC research. And I'll show you where some of these programs lie. Just keeping in mind that some overlap to a little bit with LC and some not as much. At NHGRI, we have programs into ethical, legal, and social implications of genomics and genetics research. And those are not necessarily disciplines in themselves and that the social science often use social implications, but you could have economics to look at social implications and ethics overlaps with legal and so forth. So this is our universe of research areas, but they're all surrounded in the genetics and genomics box. So what we would like to do is evaluate what is else is going on in genetics and genomics in the LC sphere across the campus. And I will get to different approaches to doing that, but I want to talk a little bit more about some of the programs that we do. I also want to just remind you that LC is one of the three divisions or one of the disciplines within the Institute. But there is a significant overlap now probably more than ever, maybe not 20 years ago, but now between genomic science and genomic medicine. And it's easy to think of areas where these two interface. So not all funding and not all grants are cleanly in the LC bucket. Some are overlapping between the two. For a very long time. A lot of LC work was focused on intellectual property, which is an overlapping with genomic science. And you can see these other topics that overlap with genomic science, as well as topics that overlap with genomic medicine. And I purposely put equity and data privacy in both overlaps because they do overlap in both directions. So what's the scope of the LC program? You heard from Carolyn this morning that the LC program is a set aside. It's funded by approximately $22 million in the most recent fiscal year. We have approximately 65 grants funded by the LC program and actively managed by the LC program. That's in comparison to about 500 for all of NHGRI and about 50,000 for all of NIH. And so just want to keep in mind those kind of almost order of magnitude jumps as you go from the LC program to NHGRI and then to the NIH as a whole. And we're going to mine data from all of those pools. Almost all of our grants come in through our program announcements. And those are on the web. And I should also mention that for those that are interested, this talk like the others will be posted. And all of the web resources that I am going to list will be down in the notes section of the posted talk when it is. So there's, you can recreate most of what I'm going to talk about by going back to these resources. So it's just to illustrate our program announcement. How do we connect with the rest of the NIH? Well, I'll tell you historically, it was centered around program directors. And so there is a quite a long history. In fact, we have program directors that have been with the Institute for more than 20 years now in the LC program, namely Joy Boyer. And so there's, that's time to build a lot of personal connections to each other, to other program directors at the NIH. We've also done tea times where we've invited back when we had a time, had the space to do this, we invited other program directors over to our place, either virtually or physically. For our tea and cookies to talk about LC work that we were doing and how we could collaborate. The NIH puts out now these things called noses, which are noticed of special interest. This is when a institute is going to do research and propose research or funding or announcements in a particular area. It's placed in a repository where all the other institutes can look at it and decide if they're interested in cooperating. And then the last way we actually build connections outward to the other institutes is what I call pedigree. And we have folks that used to work at NHGRI that now work in other institutes. And that essentially creates an existing network of LC contacts in other institutes. Through our program announcements, which we have one for different mechanisms, we have through these connections that I described on the last slide, we have several institutes that have signed on to our program announcements. And that means that they can take grants that come in under this program announcement and fund them as if they were their own. It also means that they give us, they have the capacity to add special language to our program announcement as to what they're interested in. And I'm showing you the one for the R01 mechanism, and all of these institutes have signed on to essentially accept grants that come in through this program announcement. We have another one of these for different mechanisms in the Fowardy International Center, which I'll mention in a second has also signed on to a couple of the other announcements. And so this allows us to both co-fund as well as have them accept grants that fall into their area. I've used this term that we use internally. It's not a formal term. What about other LC like or LC OID, which is an awful term programs at the NIH. And I'll give you a quick survey through those in a second. Just note that they vary in intent scope and stability. There is a 20 year trend toward more of these programs that can help address LC research and LC problems. They do cover a large range of questions. And the research that's supported in the other ICs or a mixture of standalone programs where you can get a grant, specifically for an LC topic to ones that are embedded and grants that are then supplemented with or to carry out LC research. So I'm going to go back to the supplement route in a second. So I'm going to just do a kind of a walk through some of the bigger programs. One of the largest is run by the office of behavioral and social sciences research. I would just preface this in our view. This is not an LC program. It's behavioral science program. And you can see this if you look at their priorities. Although there is some overlap with some of the funding that they have given and LC programs. And we have done cooperative programs with them, but their overall mission is not an LC like mission. There is also the Fogarty international program, which supports research in other countries. And as you can see, they actually have a very specific bioethics page where they can fund both the creation of resources and research grants. And we cooperate with the Fogarty international center and every year, co-fund some of their grants that come in. So there is LC work going on internationally through the Fogarty international center. Completely transparently as you have. There is also when you may not think of resources at the NIH, there's also a very large department of bioethics that is mainly focused on the intramural program, although it does have a lot of research. It's basic research as well. That program provides an ethics consult service like many of you have at your institutions. And we have used, the LC program has used that consult service on occasion. And features 14 faculty and each, there's 14 trainees that go along with it. So as a bioethics department, it's a relatively large one, I think, compared to what some of you might have at your institutions, and it's headed by Christine Brady. And I have the faculty, I'm not showing you the whole list, but I just want to highlight that two of the faculty in the bioethics department hold appointments in our institute as well. And that's Ben Berkman and Sarah Hall and most of their work and most of their research focuses on genetics and genomics. The rest of the faculty do occasionally get involved in genetics and genomics, but it's not really their main tactic. Just highlight one example from another institute. So several institutes NHLBI, NCI, NICHD have some dedicated staff to LC programs. Just highlighting the NCI program because you'll note that the program director in charge of this is a JD. That brings legal expertise, which is somewhat uncommon at the NIH. But I also note this is, if you have cancer questions related to cancer that might be LC questions, Charlize Kagaanan is the contact for bioethics and they actually use the term LC right in their website. So that's one of the few programs that actually spells out LC research. And we have worked with the NCI and the NCI has a fair number of programs dedicated to LC research, but of course they have a focus on cancer. One of the largest additional sources of resources for LC research at the NIH that is not in HDRI is this bioethics trans, trans NIH bioethics funding awards. It's relatively cumbersome term. It's based out of the office of science policy, which is part of the office of the director, so Francis's office. And this fund was created, I think about a decade or go, and to support bioethics research at the NIH in a trans institute way. The last couple of years it's become much, much more active and they have $5 million worth of funding each year. And they mostly use that money to fund grants that other ICs bring to them. The ICs nominate grants. The office of the bioethics group vets those grants and selects some for funding. And then the money is administered by the ICs. Not all of the $5 million is given out every year. There are some office director uses for that money. But as a single dedicated part of funds for bioethics research, this is the second largest at the NIH as far as I know of it compared to ours, which is the remains the largest. Most of what they fund are supplements to grants. I said I would return to supplements quite often. A supplement is when the institute has funded a program and as it gets rolling, someone highlights that there are some ethical, legal or social issues that need to be addressed by this program. And that's when they ask for funding and they can use that to add on programs that didn't originally have an LCA. I just want to show you just a few examples that were funded recently. Here's one from the drug institute. You can run through each of these, but you can see that theirs was on opiate use, national institutes and nursing research about funding for end-of-life care and bioethics there, allergy infectious disease, had the support of some international efforts that we're doing. The dental and craniofacial institute just funded two grants related to facial dysmorphology, including one that features genomics. Note that the previous examples did not include genomics. Here's one that actually does. And there's about a dozen or more of these that are given out each year. They are one-year funding increments, although occasionally they do fund grants for multiple years. That's the broad landscape at the NIH. And I'd like to zoom in now using and asking, what's the landscape for genomics and genetics? As you saw, I touched on a little bit that happens in other institutes, but the majority of what I've talked about is not genetics and genomics. And this also includes one that I didn't mention that's well-known is the brain initiative has a relatively robust neuroethics component, very little in the way of genetics and genomics in that program. So what we did to answer this question was we went to the RCDC program, Research, Condition and Disease Categorization Program, which is a collection of individuals at the NIH who are making the fact that the NIH funds 50,000 applications a year, and we get the full text of those abstracts as a great resource for data mining. And so what Renee Sterling did is she went into the grants database to do some text mining and data visualization. The staff of the RCDC program is actually extremely helpful, and in fact they are now establishing new taxonomy for genetics, which they don't have right now, we're just using free text. And so when we went and looked at the data from 2008 to 2020, so we first asked with a bunch of terms and related terms, are these grants that are related to ethics, genetics or not? And quite a few were not. Then we asked, are they LC research? And the answer was quite a few of them were not. And this is because bioethics, ethics and a lot of the keywords get used for training, especially for programs that train graduate students and ethical use of data. And it also included places where the investigators said that they had bioethics experience, but the grant itself wasn't a bioethics grant. We take the 53 grants that are clearly genetic and clearly LC research and ask, what are they looking at? This is a visualization tool, first saying what institutes have they come from? And so it's taken me a while, I still don't know all of the two letter codes, but this is Child Health and Development, this is Cancer Institute, this is my Darity Health. So the bulk of grants that are funded in the genetics and LC area outside of our institutes and none of this is our funding. In fact, we've excluded cases where we are cooperating with them and the program directors from HGRI are involved. So this is all outside of our portfolio. These are the institutes that are the major players. You'll note that minority health is a relatively small institute, nursing institute and our relatively small institute shows up in this type of analysis. And other large institutes like infectious disease, heart, lung and blood and diabetes and digestive disorders show up as much smaller players despite that they are much larger institutes. You look at the projects awarded by mechanism that's shown on this slide. Sorry, I'm just going to move you so I can see. Most of them are R01 projects. Again, this is 53 projects in the last decade, but there are other mechanisms used. I believe we excluded T awards from this. Very few of the other institutes have training grants that focus on LC research. So you can see the usual distribution of large awards down to other different mechanisms. And then if you ask, using again the text mining tools, what are the keywords that show up in a statistically significant fashion in these applications? Some of the most robust ones are genetic research bioethics. I think you can see the fainter ones are the subcategories. Informed consent making a relatively large appearance as well as ethical issues and genetic research precision medicine. You may wonder why Africa and Washington show up. That's because these text mining tools are looking at all the text and it's not field delimited to certain fields. And I believe it's WashU has several grants in a large number of centers. So Washington rises to the statistical significance and there are several grants related to Africa. So that's why regions show up as well as conditions. All of them are, the algorithm is relatively agnostic about what something is just looking for . So that's one of the key words. Genetic counseling from the other institutes is surprisingly and maybe refreshingly a priority or at least it has been funding wise. So these topics do mimic and mirror a lot of what the LC program does at NHGRI but there's some that are quite, some keywords quite specific. So I think that's one of the things that's really important. And I think that's one of the things that gets nicely in the domain of NIDGK and other institutes have their specific topics. If you then ask how much money is being spent and I will give you a caveat that this is imperfect numbers but they're probably not wrong by an order of magnitude or even wrong by two . So the LC research that we would consider genomics and genetics in other institutes, not ours, has crept up to about $8-9 million a year. And that's a reasonable sum if you think that it's a little bit less than half of what NHGRI dedicates. It sounds okay but keep in mind the rest of the NIH is $40 and it's a small amount from the rest of the institutes. If you want to see what this looks like from the point of view of a table, this is the total cost and this is now project years so in 2010 there were 11 full-time projects and so on. The dollar amount being spent has crept up and the number of projects has also gone up. Here's the bottom line is that NHGRI still funds the majority of genomics related LC at the NIH probably not a surprise to you. Some ICs actually have stable programs including the office of the director program not always targeted towards genomics and genetics but they are stable. That allows us to create collaborations and colleagues that are quite a bit of LC research and other ICs what I called it follows projects as I mentioned they have a project and either when they're starting to fund the research or hopefully before they fund the research they realize they need to embed or have an LC related aim related to the research and I do believe strongly that NHGRI still in this area remains the exemplar highly cooperative and highly collaborative and a cheerleader for the campus when it comes to LC research. With that I just want to thank the team, the LC team at NHGRI shown here some of them you've already seen and just give a shout out to Renee who dealt with the RCDC classification and weighted in and gathered all the data. With that I'd be happy to take questions. Questions for Larry.  You're on mute Jeff. Still on mute Jeff. I apologize I lost my screen there so thanks Larry that was really terrific and very thorough so encouraging certainly for the most part to see the trends in the right direction although I would say that the genome institutes program has been around for a long time that might have wanted to see sort of more concrete progress in terms of the genome model and that's the sort of 5% set aside that is unique so I guess I'd be interested in your speculation and welcome any comments certainly from Eric too about you know what other institutes think about that 5% set aside model and whether that's something that's ever going to be realistic for other institutes and centers at the NIH I mean I'll give you the personal answer is that it probably won't fly at a 5% amount in the other institutes I think that having some dedicated both program staff as well as funding stream I think would be really useful in the other institutes calling out a number I think would be really tough and may not be appropriate for all institutes I do think that if you look at the research that goes on in all the other institutes it's pretty easy to find an LC question that comes up especially as we move forward with new technologies and the NIH over the last decade has really emphasized implementation and so the combination of new technologies and implementation creates this essentially turbulent boundary sometimes that is where LC lives in a lot of cases there are a couple institutes that really they don't advertise a set aside but we can kind of tell from looking at what they do year in year F that they've they've allocated some budget for various projects yeah and I would agree I mean 5% is a arbitrary number 1% of the national cancer it would be a flood of money but yeah having that dedicated line would be great Eric do you have any thoughts about that I just don't think you're going to find a lot of enthusiasm for other institutes to get locked in on any number I mean I think it's one thing for them to start to get appropriately trained staff and areas of expertise and in some cases it seems like they're putting in a fairly consistent amount but I'm quite sure they want no part of a set aside or being locked in they want to stay flexible okay thank you very much Larry let's press on


Hello everyone, I would like to welcome you to today's class. What we discussed last time we would recap in a brief way today. We started with zinc borohydride based reductions last time and we saw how the chelation with zinc allows highly diastereoselective reductions of ketones and we tried to look at some examples in which the chelation is seen both as a 6 member and a 5 member transition state. Then we looked at the super hydrides and we saw how the like lithium-ry ethyl bromoborohydride is introduced in and compared with lithium borohydride which is more sort of ionic than lithium triethyl borohydride. Since the electron releasing nature of ethyl group makes this as a stronger reducing agent this is called as a super hydride because it is much stronger than lithium borohydride. And then we also saw how it can be compared with lithium aluminum hydride where we saw the reactivity was quite different from the lithium triethyl borohydride. And then we also looked at towards the end the selectrides and in the case of selectrides we saw 3 different types of L-selectride, K-selectride and N-selectride. Of course, these two are not really so much popular as the L-selectride is because of the lithium plus being the stronger collating ion than potassium and sodium. And therefore L-selectride is a reducing agent of a choice in which we have the secondary butyl group as a bulky substituent on the lithium borohydride paste reducing agent. And therefore L-selectride was obviously a choice for the reductions in which high diastereoselectivity is expected. And we saw some examples we also discussed and looked at that these are used only in cases where high diastereoselectivity is required at low temperature. And we then looked at the temperatures where the some cases minus 78 degrees can also be used because of the high reactivity of such molecules. They are called selectrides because there is a selective reduction and therefore they are called selectrides. So these names like superhydrides, selectrides etc have been given based on the reacting nature of such molecules. Now we look at even more strong reducing agent where even more steric hindrance has been introduced. For example, this is called as LS-selectride and this is called as KS-selectride. L stands for lithium and S stands from the trasiamyl part that is tri iso-amyl part in which the S letter has been taken up and this is how it is called as LS-selectride as you can see here. So this is KS-selectride and this is LS-selectride in which the groups which are attached are bulkier than secondary butyl basically it is iso-amyl or tri iso-amyl group which is present. Now we take a case something of this kind which is reported in literature in 2003. Now if we take this bicyclic molecule which is now reduced and as you can see the reduction leads to this particular hydroxy group being alpha. If we see the conformation of these molecules, this molecule we see that if we make it as a trans type of molecule in which now we have a nitrogen here and hydrogen here then we can put the oxygen at this stage methyl group is alpha therefore we can put it in this way. And now if we put the carbonyl group which is here and then the substituent C5H11 which is beta oriented is put it here C5H11. Now very clear that this particular conformation is not a preferred conformation because the bulky C5H11 is axial. Therefore, we would imagine that this particular conformation is preferable as you can see that the C5H11 now is in equatorial orientation and the methyl here this is axial hydrogen this is methyl this is also equatorial this is equatorial hydrogen and we can remove this part here and look at the methyl being equatorial. So both the groups are equatorial and now in this case what is happening is that this particular CH2 group is axial and therefore the reduction does not come the reducing agent does not approach the carbonyl group from the lower side because lower side is basically offering a steric hindrance and therefore the reduction takes place from the top side that is the beta side and therefore the reduction leads to the hydroxy group being alpha oriented and the hydrogen is coming from the beta side. This is very easily seen by this particular conformation and so there are two reasons why this conformation is preferred one is of course you have a substituent which is expected to be in such a way that the bulky substituent prefers equatorial orientation and then between the two of them that we consider the trans as well as the cis type of di-calone type of molecules we prefer the cis one and obviously in all these cases wherever we have discussed the carbonyl group reduction with any reducing agent we have to keep in mind that the reduction takes place at 107 degrees angle which is the rule according to or the descriptions made according to the Burgi Donitz kind of hypothesis or the observations. So in any case the reduction has occurred in a very highly diastereoselective fashion mainly because of the very large bulky groups which are present on the this LS-selectride as we discussed earlier it is whenever there is a preference of L-selectride versus K-selectride we prefer L-selectride in a similar fashion when we have LS-selectride versus K-selectride people prefer LS-selectride where there is a solubility problem. Now we go to another reducing agent which is sodium cyanoborohydride not only alkyl groups which we saw in the case of lithium triethyl borohydride or selectride or LS-selectride we saw different alkyl groups which are being put in order to increase the electron releasing nature of the borohydrides and thus making them stronger and stronger reducing agents. But not only alkyl groups that can be put as substituents but even electron drawing group such as a cyano group has been introduced and attached to the boron part of the sodium borohydride which is easily made by reacting sodium borohydride with hydrogen cyanide and that leads to a sodium cyanoborohydride. So what is the purpose of such a reagent that is something that we need to understand it. Sodium borohydride is obviously the simplest reducing agent and that reacts with carbonyl compounds readily because it is ionic and in ethanolic or ethanolic solutions it reacts. But when we put cyano group so cyano group is an electron withdrawing group this particular cyano group is an electron withdrawing group and obviously it reduces the nucleophilic nature of the borohydride part that is now in this particular case BH3 is much less than the sodium borohydride case. It is obviously not easy to reduce a particular carbonyl group with a compound that is having an electron withdrawing group as a nature cyano group as an electron withdrawing group and therefore in order to increase since we have decreased the nucleophilicity of sodium borohydride by putting cyano group. So we need to increase the electrophilicity of the substrates that is the carbonyl group and what is interesting is that because the nucleophilicity nucleophilic nature of the sodium borohydride has been reduced by putting cyano group. So the sodium cyano borohydride now is not nucleophilic enough. So it is found that it does not decompose in a solution even up to say BH3. That means it is stable under acidic conditions and that is the advantage and it is also soluble in THF methanol water HMPA that is hexamethyl phosphoramide DMF that is dimethyl formamide and these they do not react with these particular solvents. Now just for comparison this is a phosphoramide and this is a phosphorus triamide but this is more used as a solvent and this is used as a kind of phosphine in comparison to triphenylphosphine or thialkylphosphine. What do the sodium cyano borohydride allow the reactions of that is if we take a halide such as RI or RBR or R-tosylate where there is a fairly good leaving group. You have an iodide as a leaving group, bromide as a leaving group or a tosylate as a leaving group or even mesylate as a leaving group. So we have paradolene sulfonyl or this methyl methyl sulfonyl. So sodium cyano borohydride reduces these molecules and the leaving groups go and then hydrogen is introduced at the R position. So I can see here at in HMPA at 70 degrees this kind of molecule which is somewhat sensitive molecule we can reduce this particular carbon bromine bond and introduce here carbon hydrogen bond. In this case is one thing which is important to remember that the reducing agent sodium cyano borohydride is stable under acidic conditions up to pH 3. So what are the reactions that are done? As I mentioned if we have decreased the reducing ability of sodium borohydride by introducing a cyano group and thus the sodium cyano borohydride is less nucleophilic therefore we need to increase the electrophilicity of the molecules which we need to reduce. And for that purpose since sodium cyano borohydride is stable up to pH 3 to 4 we can add acid into the molecule where carbonyl group gets now protonated to form the corresponding oxonium ion which then now is fairly good electrophilic in nature to which sodium cyano borohydride then reacts and then your hydrogen is transferred as a hydride and the corresponding alcohol is formed. So we can also do in this fashion that we put H plus and then we have sodium borohydride and obviously we can introduce the deuterium here and form the corresponding deuterated alcohol. So this utility of sodium cyano borohydride to the corresponding deuterated alcohol is also utilized it. Now in all these cases what we have seen is that we have introduced the acid to the reaction medium in order to increase the electrophilicity of the carbonyl group. We can also utilize the nature of this sodium cyano borohydride which is stable under acidic conditions in such a way that for example if we take an alcohol of this kind and see that the alcohol which is a tertiary alcohol can easily be reacted with a Lewis acid and could be ready to form a sort of carbocation which is a tertiary carbocation. In this particular case it is a rigid molecule and therefore the alcohol when it coordinates with a zinc bromide it releases the OH path and then sodium cyano borohydride attacks from the same side and the hydrogen is introduced where the OH group was present. Basically only because the reagent sodium cyano borohydride is stable under acidic conditions. So it is basically what we are talking is that you have a sort of carbocation that is formed. So carbocation allows the reduction to take place. Even here in this case as we can see that this carbonyl group is reduced to the corresponding alcohol and the at pH 4 the reduction allows the approach of the hydrogen coming from the beta side here because of the ester group which is alpha oriented. So you have a beta hydrogen to come at the carbonyl carbon. So not only it is reducing it at lower pH but it is also of course following the same principle of stereoselectivity. Now in this case in the last example here the aldehyde is also reduced again at pH 4 in methanol as a solvent. So when can go all the way. So you have a possibility of going via a carbocation. We have a possibility of protonating the carbonyl groups and therefore under these conditions the sodium cyano borohydride being stable can allow the reaction to take place. Now because carbocation can be formed as we can imagine that we have an enamine and this enamine can be reduced to the corresponding saturated molecule basically because you have the enamine which is kind of nucleophilic in terms of the fact that we can move the electron density to the proton. So if we have under acidic conditions the reaction to take place in the presence of sodium cyano borohydride then we can expect an intermediate to form something of this sort. So this is the intermediate that will form which then gets reduced under the conditions to basically have the reduction taking place at the center and then there is such molecule is coming. So this particular hydrogen is coming from the acid and this particular hydrogen is coming from the sodium cyano borohydride and that is how we get this saturation of the double bond. In a similar fashion this is an emine which is very easy to understand that it gets protonated under the conditions to form the corresponding positive charge on this center and therefore the nucleophile sodium cyano borohydride would attach it here and then your hydrogen will come there. So this hydrogen comes from sodium cyano borohydride and this hydrogen comes from the corresponding acid. Therefore such reductions are quite useful in order to which cannot be easily done by means of sodium borohydride because such possibility of formation of an ammonium ion or a carbocation is not there. If we now look at this aspect of it here of examples in which we have done the alkylation that is very interesting. Now I would like to discuss it in detail about it that how does this particular alkylation of amines takes place. So let me remove this particular part of it which we discussed just now and look at it here. If we take this particular molecule and react with formaldehyde and of course sodium cyano borohydride and under these conditions what happens is first the formation of an something of this sort occurs after the nitrogen of the molecule methyl interacts with the formaldehyde. That means there is a condensation with the formaldehyde and an emine is formed and this ammonium ion then gets reduced at this stage here with sodium cyano borohydride to form here NHCH3 and of course the corresponding carbonyl group is present and the corresponding ester is also present. Now here there are two aspects one of course we have deliberately added formaldehyde therefore the reaction occurs by condensation of amine with the formaldehyde and we form this secondary amine. Now if we continue the reaction secondary amine also will undergo condensation and form the this type of CH3 and here you have a double bond CH2 positive charge. So the second condensation occurs of the secondary amine here and again the reduction takes place at this center with sodium cyano borohydride here leading to the formation of dimethylamino group. So what we have done is we have introduced say you have an R and then you have NH2 and we have gone stepwise so to form RNH CH3 and then you have RNCH3 and CH3. So that is because of the formaldehyde and sodium cyano borohydride and that is a very straightforward and an easy way of introducing a dimethyl group on an primary amine using the properties of sodium cyano borohydride reducing a cationic species. So the interesting way of converting a carbonyl group to the saturated sort of molecule like this hydrocarbon here. What are the ways by which such a reduction can be done? That means if we have a carbonyl group of course we can carry out Wolf-Kishner reduction and then we have another possibility that we protect the carbonyl group here as a diethioketal and once we have the diethioketal the reduction can be done by Renny-Nickel, a special Nickel catalyst which on the surface of which hydrogen is absorbed and that allows the cleavage of this carbon sulfur bonds by the hydrogen and then you get the corresponding molecule in which the oxygen is replaced by two hydrogens. Now there is another way by which we can do the same reaction by converting carbonyl group to the corresponding n-tosyl hydrazone that is what the reduction is that we are discussing and if we use a proteic source in the in the DMF and heat it we can get the same reduction but then it is via tosyl hydrazone. Now what is the mechanism and the acidic condition the nitrogen the first nitrogen here of the tosyl hydrazone gets protonated here and we generate a ammonium ion here to which now sodium cyanoborohydride donates hydride here and the double bond moves with the loss of tosyl group here it goes off leading to the formation of this particular intermediate which then is losing a proton and goes to another molecule like this which can now be expected to be somewhat like this that we have loss of nitrogen in this fashion and then under the proteic condition the anion which is formed here is grabbed by the proton which is present here. So the blue hydrogen is coming from the sodium cyanoborohydride and once that allows the formation of this proton proteic species here this can rearrange by the loss of nitrogen and the proton is coming at this stage this is how the reaction occurs. Now if we take alpha beta unsaturated system we have seen that the normal tosyl hydrazones are reduced to the corresponding molecule which in which the carbonyl group has now through tosyl hydrazone be replaced to the corresponding two hydrogens. But if we take an alpha beta unsaturated system which is from molecule like this if we take a molecule like this we can convert into the corresponding tosyl hydrazone which then under the similar condition forms the corresponding hydrazine type of molecule like this which then undergoes rearrangement in this fashion to move the double bond to this position which is this was a conjugated system. Now what we have found that under these conditions it undergoes deconjugation and the hydrogen is coming at this stage here the hydrogen is coming here. So the original hydrogen had come at this stage here this should be blue in color and then we have a rearrangement that means now what we have started we started with this molecule in which we had the carbonyl group like this and eventually what we have got is this. So it is not only the reduction of the carbonyl group to the corresponding hydrogens which we would have expected to give something like this if it was a normal reduction then we would have expected the two hydrogens to come here but that is not the case what we have got is the two hydrogens which have come are basically at this position here eventually. So instead of getting this molecule which we did not get it we got this molecule via the tosyl hydrazone. So this is how the reactions of sodium cyanoborohydride take place. So we will stop it today at this stage we have seen various aspects of these reducing agents and now we will take up the other reducing agents next time you can go through the notes of today's class and get ready for the next class till then bye and thank you.


Hey there friends. Thanks for checking in after ranging out today. We're looking at the Taurus spectrum little 380 ACP handgun it comes with two magazines This is a seven round mag. You can see that it does have the extension out of the base plate and a flat base Six round mag, but there it is Taurus lowered the MSRP to 224 224 used to be 305 they also offered it in many different colors You can see this one here kind of weird looking the aqua green gray Frame there and a black slide if you go to their site now They just have the all-black model and they all black with a stainless slide But what they have here is called the soft coil system. All right a rubber molded grip Backstrap and where there are typically serrations It has the rubber soft coil and they said you know anywhere that you touch on the gun When you grip it you're you're grabbing on to that soft coil and I would say it's a very ergonomic gun It does feel nice, especially with that mag there a pound double-action trigger integrated sights and Many different color combinations were once offered. I don't know if they're still offered. I saw them on Various other sites for sale. I think the red one looks cool. Let me go ahead and take a few shots nice I Shot it before I had a couple problems with max-tech all the other types of ammo I never had an issue with that was Fioki 95 grain your regular target loads But it's a it's a cool little gun and one of the things I wanted to show you okay, there's the trigger pull does have restrike capability and A full double-action reset right around eight pounds, but what I wanted to show is the disassemble All I have here is a round and it's got that Little circular piece there you just take it and turn it Turn that and then there you go All right, you can see it does have Longer rails in the back and then you just put that back on and it automatically moves this Back into position so it locks the slide the Torah spectrum has a 2.9 inch barrel It's unloaded weight is just under 12 ounces loaded with seven rounds. You're looking at 14 ounces So a very lightweight 380 that many people would pocket carry But let me see how well I could do one-handed or at least better than Before all right a little bit of Nail polish or something on that front site it is integrated into the slide But a little something to make that stand out I was able to see it on those targets, which are similar to the same color as the soft coil rubber grip Which I'm noticing right now See that same color as my targets. That was not planned But it's it's a neat little gun many people have said that it's ammo finicky I found it to be ammo finicky But only with max tech and then I later learned that max tech was not the greatest ammunition I haven't shot much of max tech at all, but it's a it's a neat little gun I've learned to appreciate it more and more over time and It's certainly lightweight and pretty much a straight shooter I did question why they went with this rubber piece here in place of regular serrations, but You know so far it's held up pretty good. Let's go ahead and do a lip risk test see what happens here tourist spectrum past the lip risk test the longer I'm owning this and The more that I am understanding the little pistol the more I am appreciating it It's not the greatest ever But it certainly is working well now and I think that You know those who have them tend to like them and a little bit of a crunchy trigger But not bad when live firing So there it is tourist spectrum at the range and it certainly did perform well If you like videos like this, please subscribe and share I always appreciate thumbs up button Thanks for watching and you guys be safe


Hello Columbia and welcome to This Week in the City. Highlights brought to you from the public relations, media, and marketing department with the City of Columbia. I am your host, Lisha Yutzi. On Monday, January 24th, please join Columbia Water for a public information meeting. Columbia Water will host a sanitary sewer upgrade drop-in meeting in the Olympia community. The meeting will be held again on Monday, January 24th from 5.30 p.m. until 7.30 p.m. at St. Lutheran Church of Olympia located at 1127 Olympia Avenue. Please visit our website for additional details or contact Columbia Water. On Tuesday, January 25th, there will be a free COVID-19 vaccination clinic held at Drew Wellness Center located at 2101 Walker Solomon Way. The clinic will be open from 1 p.m. until 5 p.m. Please stop by to get your COVID-19 vaccination or your booster shot. For additional details visit our award-winning Resilient Columbia website at Resilient.ColumbiaSC.gov. Don't forget that every Wednesday our Solid Waste Division is hosting open interviews from 9 a.m. until 11 a.m. at the Public Works Facility located at 2910 Colonial Drive. These open interviews will give you information about all vacancies inside the Solid Waste Division. Please bring with you appropriate information, a driver's license, a social security card if available, and your vaccination records. Again, this is every Wednesday morning from 9 a.m. until 11 a.m. at Solid Waste in our Public Works Facility at 2910 Colonial Drive. Please visit our website at ColumbiaSC.gov for additional details or call Solid Waste at 545-3800. On Thursday, January 27th, a free vaccination clinic will be held at Hyatt Park located at 950 Jackson Avenue. The clinic will be open from 1 p.m. until 5 p.m. And you and your loved ones can receive a free vaccination or your booster shots. Please visit our award-winning Resilient Columbia website at resilient.columbiasc.gov for more information on COVID resources and information. Thank you, Columbia, for watching this week in the City, where we are proud and happy to bring you highlights from the public relations, media, and marketing department with the City of Columbia. I'm your host, Alicia Utsi, and on behalf of the City, remember to continue to watch us on City TV, Amazon, and Roku, as well as our YouTube channel. Please follow us on all social media platforms on YouTube, Facebook, Twitter, and Instagram. And make sure you visit our 24-hour around-the-clock information station on our website at columbiasc.gov. And remember, above all, we are Columbia.


Rune is up 11% in the last 24 hours, 75% in the last 7 days of trading and 278% in a month. With the recent surge in the native token, Rune, the Thor chain ecosystem is buzzing with enthusiasm. The uptick in Rune not only reflects a surge in interest, but also underscores a burgeoning confidence in the project. This positive momentum is intricately tied to the ecosystem's ongoing development. During the coin's performance over the past week, there are indications that this upward trajectory might persist. Thor chain has recently jumped to third place among decentralized exchanges, DEX, in terms of trade volume, and has quickly become a top native asset settlement protocol. As an alternative liquidity layer for centralized exchanges, CEXs, the network has additionally contributed to its expansion. Trading volume as of today, reached an impressive $1.44 billion, which solidifies Thor chain's position as a big player in the cryptocurrency world. DEFILAMA says that the protocol is now very close to industry leaders Uniswap and Pancake Swap, marking a significant milestone in its journey toward dominance. Since then, the price has been going up since the beginning. But on November 12th, a new barrier showed up and stopped Rune's push toward $5.30. The coin's momentum is full of twists and turns, which keeps investors interested as the market moves quickly. Rune is currently trading at $6. The fact that Thor chain's rise has been faster than expected and has surpassed curve finance shows how important it is becoming in the DeFi scene. The main creator of Thor chain, Chad Baraford, was surprised by how quickly things were moving forward. He did admit that things were moving much faster than expected, taking only two days instead of the two months that had been planned. This good news shows that the protocol is moving quickly and surprisingly in a good direction in the decentralized banking sector. Meanwhile, metrics show that Rune is strongly overbought. According to money control, the relative strength index, RSI, stands at 80, signifying the coin is currently in an overbought condition. This suggests caution among traders as sustained high RSI levels might indicate a potential correction soon. But if the investors sustain the momentum, the uptrend may continue. On the positive side, the moving average convergence divergence, MACD, is above the signal line at 47.26. This points to strong bullish momentum. This alignment of technical indicators implies a prevailing bullish trend, but warrants careful monitoring, especially considering the overbought RSI. So traders should stay vigilant and assess the market conditions, keeping an eye on both potential corrections and the support of SMA. This will help them to make informed decisions in this volatile crypto market.


Hi, folks. My name is David Benjamin. I work on TLS at Google, particularly our TLS library and also TLS's usage in Chrome. So this talk is not going to have any crypto in it. Rather, it is going to be about the troubles that come up when we try to add more crypto to things and all kinds of bugs and implementations. Or why your crypto isn't real world yet. I consider titling this why my life is hard, but I decided that might have been a little bit too much. All right. So, as in the previous talk, suppose we either have a new protocol that's been analyzed or we find some bug and we need to patch and we would like to go and fix the problem in TLS or make it better or whatever. The first problem we run into is that the internet doesn't update atomically. We can't just wake up tomorrow and realize that all of our mistakes have been erased. So, at least for a transition time, new clients with the fix need to account for old servers without the fix and vice versa. At least until we've gotten everything updated and then we can remove it. And so we have four easy steps to change TLS. First, we go and add the new thing, but we carefully design it so that old connections still work and so we sort of upgrade the ones we can. Then we wait, you know, a short while, remove the old thing and rejoice to go home and I can leave the stage now. No. Everything on the slide is a lie. This is actually a huge pain. The internet, the TLS is this vast ecosystem with like lots of different implementations with varying degrees of quality, ability to update things, and as a result, we end up having a very hard time removing things and even adding things end up actually being rather difficult, much as we would like to be able to make things better, you know, very quickly. So, if you remember no other slides from this talk, remember this one? It's pink. There's another pink slide later on that's also important. There was a template and it made things pink. The universal law of users is that the last thing that changed gets the blame. This is how every single user of any software works. And I don't mean this as like a disparaging comment on users. I do this, too, and I'm sure everyone else does, too. If Chrome updates and suddenly everything is green, I blame Chrome and not my graphics driver, even though it might be the graphics driver's fault. And this means that when we go and break things, either when we go to like remove things or deal with some buggy server, even though the server is the one that has this 15-year-old cryptography or they just completely implemented the spec wrong, we're the ones that have to deal with the fallout. And fallout usually is in the form of angry emails and angry users and possibly someone telling me to go revert the change and lots of political capital lost. And so while we do manage to break things, it's rather expensive and much slower than basically anyone would like except for the people who don't want us to break anything. And so as a result, TLS parameters are extremely long lived. SSL 3.0 was 15 years old before we got rid of it. That's kind of ridiculous. And we still have a whole mess of TLS modes that we know are insecure, we know they're broken, and we still haven't managed to get rid of them much as, you know, it would be nice to do. And so the result is that adding things is much easier than removing them. And so if you're not careful, your complexity budget like quickly goes to zero where like we keep adding lots and lots of little patches and we have to deal with this quadratic product of like every single combination. And so you often find that implementers are a little bit uneasy to add new things. Like we would like to make things better, but if it's sort of a like epsilon improvement and there is a major improvement that's about as much work, we would rather just go straight for the major one and not have as many intermediate steps. And the other consequence of this is downgrade protection is absolutely critical. And what do I mean by that? So because we're sort of stuck with this swath of like history that we have to support and clients and servers for a long time, TLS includes a negotiation step. The client advertises a list of parameters it supports. This is the version, the cipher suites, various other things. And then the server processes this message and responds with a selection. And for this to work, we care about two properties. We care that this thing is downward protected. Because we're going to be stuck with things that we know are insecure for way too long. And that means both client and server will be supporting these. We need to make sure the attacker can't activate those code paths and that we can rely on the newer thing actually getting negotiated. This is done by some variation of taking the handshake transcript and stuffing into the protocol and the finished message or the signatures. The second property we care about is extensibility. This doesn't work if we can't actually add the new parameters. The way this looks like is the first message with the advertisements, we keep that compatible from version to version. And then the protocol tells you what you should do if you see an advertisement you don't understand. Typically the rules are the server must ignore things that it doesn't know what they are, just skip over them. And the client must not advertise anything it doesn't know what it is. And this should be relatively straightforward. None of this is particularly subtle engineering. And unfortunately it keeps going wrong. And so removing things is sort of naturally hard, but adding them also can be hard. And then my life is hard. So first, as an example, we have, TLS has had roughly four major versions so far. There's also SL2, but it looks sufficiently different from SSL3 that I think it's reasonable to consider a different protocol. Whereas SL3 to 1, 2 are exactly the same. And the negotiation works by the client includes a maximum supported version and the server computes the min of that and its maximum version and sends a server hello. Everyone can take the minimum of two 16-bit integers, no one can possibly get this wrong. Unfortunately, when my predecessors went to go deploy TLS10, we found that a bunch of server hello, sorry, SSL3 servers rejected the TLS10 client hello. They should have just negotiated SSL3, but they would break the connection. And that meant that deploying TLS10 and clients would break those servers, and the universal law of users says that would be our fault, not theirs. And so if it's too many, browsers ended up implementing a version fallback. At any connection failure whatsoever, we just turn off TLS10 and any other features that might freak out this server and see if it works this time. And then this problem kept happening every single time. TLS11 turns out that those break some TLS10 servers. TLS12 breaks some TLS11 servers, and by 2014, Chrome was trying four times to connect to a server before it would give up and just show an error. And so this was a huge complexity nightmare. When you have these kinds of retries, it turns out to mask other kinds of bugs, and so other things got into the ecosystem, and it was like don't do this. It also turns out to have security consequences. SSL30 is completely broken by triggering requests in certain ways, and fiddling with the ciphertext, you can decrypt the traffic. Ideally, we designed this thing so that this would be fine. Around this time, there was still a small fraction of SSL30 servers, so those we would need to show angry warnings about and gradually phase out, but the majority of traffic had already updated by then. But the problem is the downgrade protection broke. Because we had this external fallback, the attacker can just close every connection that has a version that's too new for it, and the browser would just happily turn them off, and then at SSL3, and then we would trigger the SSL3 code, even for those newer servers that should not have been vulnerable to these bugs. So this means that if your client has a version fallback, you cannot rely on security properties of newer SSL3 code. This is a disaster. Happily, this is gone. In 2016, Chrome no longer performs TLS version fallbacks as of 2016. I will note that at this time, the fallback was 16, 17 years old, and this still took a year worth of fixing up metrics, yelling at people whose sites were broken, dealing with bugs that the fallback had masked, and lots and lots of angry users. And we also learned that vendors don't really understand version negotiation, like TLS server vendors, which is kind of surprising. So the conversation would usually go something like, hi, so your product doesn't implement this correctly, you should be computing the minimum versions, your TLS12 intolerant, et cetera, please fix this, and the response is, oh, okay, we'll implement TLS12 in the next version. And yes, please do implement TLS12, it's better, but that's not actually the bug. The bug is that you are not computing this minimum of 16-bit integers, and so you're just going to cause this problem in TLS13, and then you'll fix that by implementing 1.3, and then 1.4 will be painful, and this cycle never ends. Additionally, it's not just the version field that goes wrong. Basically, everything else in the protocol also goes wrong. LPN is the way we negotiate the protocol, and you can negotiate which protocol to do next. That made the client hello too big, because now we had to list a bunch of protocol names, and we found that a particular load balancer would start hanging when the client hello was bigger than 256 bytes. We thought that this, and this was kind of problematic, we thought the problem was they had a fixed size buffer, and unfortunately, TLS13 is going to stuff even more things in the client hello, so this was kind of bad. But we were very lucky that one of this vendor's engineers posted the mailing list that, actually, it's not that we have a 256-byte buffer. If your length is in this range, then we think you're speaking SSL2 and get very confused, because the 2-byte length has a 1 here, and they were distinguishing them wrong. So now all clients actually will produce the client hello, and if it's in the bad range, we have a padding extension, which has it up to 512. This is ridiculous, but it unblocked our extensibility. At some point later, I think this was when we added certificate transparency. We got some reports that some users couldn't pay their taxes because their tax website was hanging. Turns out this vendor hangs when the final extension has an empty body. If it's elsewhere in the list, it's fine, just that the final one can't be empty. I still don't know what they were doing, but we strategically reordered extensions, and it was fine. Then we added a new modern ECDH curve, and some other servers in Proxies broke. They forgot the default case when looping over the curve list. Thankfully, that one was rare enough that we could just break it. And then this happened again for RSA PSS, which is added in TLS13. They also actually was the same implementation. Forgot a default in their switch case. But fortunately, we were able to break them too. So the problem is when this happens, we don't really have easy options. Ideally, we would prefer to just break these servers and try to get them fixed. The ecosystem is much healthier when we manage this sort of thing. But many vendors don't ship updates. They might be, for instance, some fancy hardware load balancer, and due to its excessive fanciness, to take an update, you must bring it offline for two hours, and so nobody wants to take their updates. And anecdotally, the folks who mess up these switch cases also don't build auto-updaters. And if it's too widespread, it becomes prohibitively expensive very fast. It's a very hard case to say I would like to break 25% of connections on the internet. I don't think anyone is going to allow me to do that. The universal law of users gets in the way here. So while this is preferable, if we can manage it, our metaphorical breakage budget is rather limited. We can only break so many things at a time before people start getting angry. Alternatively, we could work around the bug, and this is usually what non-TLS folks will ask me to do, and this keeps our users happy. It's nice in the short term, but then there are long-term costs and protocol complexity. This TLS is already a nightmare, and we're going to make it even more a nightmare. And as we saw with the fallback, sometimes they have security consequences, which is extremely unfortunate when we have this nicely analyzed protocol, and then we just break it all outside. So ideally, we could prevent this from happening in the first place, so it makes sense to look at what is actually going on here. Specifications are written and consumed by humans, and humans are not very good at this. We make mistakes all the time. The only thing that keeps the internet working at all is some form of natural selection. If your implementation breaks with existing stuff, you will not last very long. The users won't want to use you. Hopefully, your QA folks will yell at you first, and possibly even when you're testing things on your machine, you'll notice, oh, hey, this doesn't work in insert browser here. Conversely, the general rule of thumb is it works in my browser, ship it. In standard circles, this is known as interoperability testing. This is all interop testing is. Interoperability testing does not catch all bugs. Problems with extension points are usually latent. They will work today and then break tomorrow because it doesn't matter that you break on unrecognized curves because you know all of the curves that exist today, it's that tomorrow we're going to define a new one, and then you break. And additionally, TLS has far too many extension points. You're not meant to be able to read all of that. I'm sure this list is missing. I just went to the page where Ayanna keeps their TLS registries and listed all of their titles. There's too many of these. And because there's so many of these, our changes are spread across them. Like today, this change is a new curve. Tomorrow, we added a new cybersuite. And each individual extension point is very rarely used and frequently untested. When we added 2519 in Chrome, that was the first time in the history of TLS anyone ever deployed a new curve, as far as I know.  So there's a nice analogy here, which is protocols should have only one joint and keep it well-oiled. If you have these extension points that you never exercise, bugs will gradually accumulate and if you wait too long, they will rust shut and it takes a lot of effort to get them moving again. So the solution is we can apply a little grease, which because I have far too much fun with acronyms stands for generate random extensions and sustain extensibility. In each of these extension points back here, we'll just reserve a handful of code points that we promise never to actually use and have the clients pick randomly out of this list and send fake ones just to get people used to the idea that there will be curves they don't know what they are. And we ideally break the buggy implementations before they spread. Because breaking things when there's only one or two is not a big deal. It's when they went unchecked for five years and are suddenly one percent of the ecosystem that we have a problem. And in a way, this is sort of inverse Postel's law. We already know that being liberal in what you accept doesn't work very well. We keep adding these workarounds and workarounds and security problems. But maybe we should invert the other half, too. And rather than being careful about not breaking random servers, we should go out of our way to break them while we have a chance. So Chrome is doing this these days. And it appeared to actually work. We prevented some bugs in some draft TLS-13 implementations that they supported all of the current curves. But because TLS-13 changed where the curves are listed, they forgot to skip over the unknown curves correctly. But our implementation will always send fake curves. And so they found they couldn't talk to Chrome's draft implementation. And notice the bug before TLS-13 even existed. So speaking of TLS-13, that is the other... TLS-13 has been plagued with a lot of these problems. I'm not going to talk about what's in TLS-13 either, but I think you heard from the previous talk that we're doing it a lot better this time. So we're very excited about getting it deployed. Unfortunately, TLS-13 used the same versioning scheme that worked so great the last three times. I think there's some saying somewhere about doing the same thing over and over again and expecting different results. So we did a crawl of some list of top sites. And the folks who run SSL lab did as well. And we found that somewhere between 1 and 3% of top sites rejected a TLS-13 client hello. These weren't sites that you never heard of either. These were like popular newspapers and other things. So there was no chance we were going to be able to break that. Our breakage budget is several orders of magnitude below 1 to 3%. Which means that clients would be forced to fall back or do some other work around because these numbers, as much as we would like to just break them, other people will scream at us. Also it's actually not that great for our users to have the website suddenly stop working. But that would break down very protection again. And we spent all of that trouble getting rid of that 17-year-old disaster. So that wasn't very happy. So we actually ended up just moving the versions, extending information somewhere else. The old version field is now frozen at TLS-12. Minimum versions, sending a maximum version seems reasonable, but apparently it doesn't work. I don't know. Now it's in an extension and critically, we send a list of versions rather than a maximum version. And although that is actually slightly more work to process, it is more aligned with how other TLS parameters work, and so hopefully people will not get the idea that each, people will get the idea that, one, a single client hello is good for multiple versions at once. And more importantly, we can grease a version list. We can't grease a maximum version because if we send, you know, a fake high number, that implies we support everything below it, which doesn't actually exist yet. And this indeed successfully prevented TLS-14 intolerance in the draft implementation. The two bugs we managed, there was, no, sorry, there were three bugs we cleared. One of them was a version intolerance. The other one was a curve list, and then there was an extension. And also, this allowed us to be able to safely deploy the draft versions. The old scheme requires you support contiguous range of things, and that doesn't work well when you want to temporarily advertise, you know, TLS-12 and a half to see if it works and then get rid of it later. So with that resolved, we were very excited to finally turn this thing on in February of 2016, and everything broke. So if you were wondering why TLS-13 isn't here yet, it's because of this disaster. We got a lot of user reports that folks' firewalls, proxies, antiviruses, random pieces of software or devices that sit in between the client and server were doing something. And the impact was that we lost about six or so percentage points of handshake successes, and this was on the beta channel where you would expect that fewer people are running these like, these things tend to be more enterprise-y features. And 6% is not within our breakage budget. We would need a fallback without any question. The good news is, we didn't find any endpoint issues, at least not that round. So the versioning hacks, while disgusting, worked. The bad news is, diagnosing middle box issues is very hard. We can't just ask the user for a URL and poke at the server and see, ah, you don't like it when the final extension is empty. Okay. So what did we do? Well, we didn't have, we don't have very many tools at our disposal. So we did a small deployment with our beta channel. That was small enough, large enough to trigger problems, but small enough that we didn't hit the universal law of users too much. And then we monitored metrics and waited for people to tell us what broke. This is not a very good mechanism. Only a very small fraction of users will actually send reports. Once you get a report, they tend to be on the order of, I can't visit Gmail. It doesn't work. That's not very useful. You need to go ask them what their setup is. This is probably some random employee of this company, not one of their IT folks. And so as a result, only a small fraction of users actually respond to these questions. Anecdotally, the half life of a user report appears to be about 1.5 questions. But we did eventually find a small incomplete list of vendors. And so we reached out to them, maybe they would be able to fix their bug, maybe. But now we have yet another having or whatever. Not all the vendors are responsive. Those who are responsive, they aren't necessarily willing to fix their bug because their product works just fine for them. Those who are able to fix it almost never are able to reliably deploy fixes. We were already pretty dismayed at how servers could auto-update. These enterprise boxes will never update ever. And so we tried another attack, which was we just purchased every broken device we heard of and attempted to reproduce the issues. At last count, we have four middle boxes, one printer, and there's a poor Windows laptop that has two antiviruses and some scanner software, sorry, a label maker software installed. It's been a fun year. So what did we learn? This is an oversimplified picture, but roughly these middle boxes either terminate TLS so they have their own CA, which maybe they configure the client to trust or something, or they might not terminate it. The ones that terminate it, I will make no comment on whether or not this is a good idea. I will merely say that they don't generally break TLS 1.3. A TLS terminator is in theory a client and a server.  If the client is correct and the server is correct, you will at least not make me angry at you for breaking TLS 1.3. You might have other problems that's not the subject of this talk, although some vendors do still manage to break this anyway. The other middle boxes, which is the bigger problem, will process TLS without terminating it. The problem is TLS is not the same. Officially, only the client hello is promised to remain unchanged. Everything else we're allowed to change in newer versions and indeed we changed basically everything after the client hello in 1.3. But we didn't do it for 20 years. TLS 1.2 and everything in between are the exact same protocol. And so although these things can't change, they didn't. And people got used to the fact they didn't change and built products that did various things with these information. Some of them are, you know, firewall type filtering things, and some of them, they just wanted to check the length prefixes worked out because it seemed reasonable at the time. One of the vendors actually said, we just wanted to sell the customers a box that did something and didn't justify it beyond that. This is an oversimplified picture. A lot of middle boxes are mixed of the two, but this will give you a flavor of the kinds of things that we're having to deal with. So well, we need to work around some kind, either a fallback because or whatever, but we don't want a fallback. So enter TLS-13 compatibility mode. This is ugly beyond belief, but it does work. We made TLS-13 look like TLS-12 resumption, which actually only takes injecting a few dummy fields and some messages that the other side ignores, but for whatever reason, the middle boxes think are critically cracked. So this is ugly, but it's only ugly. The fallback has a security consequence and this one just costs aesthetics and complexity. I would rather not pay that, but I'll pay one of them, I guess. If I have to pick one, I'll pay that one. So we, I think this was an idea by someone at Facebook originally, and then we iterated over this with Chrome, beta and Google servers until we got something that worked and it does appear to relieve most of the compatibility problems. So TLS-13 draft 22 and later includes this disaster. So with that out of the way, in December we did a Chrome stable test and thankfully, so we turned it off intentionally before the holidays because that seemed kind of bad manners to leave on. But we got a number of results that were consistent with Chrome beta. So it seems to basically work. There were two new confirmed bugs. There's a new buggy middle box. I do not think we're going to work around them because the workaround would actually have security consequences so hopefully they can fix themselves. Also, someone used extension number 40 for the extended random extension which was never standardized. That collides with TLS-13 because the ITF really likes to number things consecutively. Pro tip, if you're making your own extension, pick a large number. They're within the limit. The limit is 65,000. There's plenty and the ITF will never get to 65,000. So in draft 23, that extension has been renumbered and is now 51. Oh, well. So hopefully this year we should have TLS-13, I hope.  I want to deploy. And the other thing to think about for the future is that the first version of Greece, it was basically about endpoint bugs. It doesn't work against the middleboxes because it doesn't touch the server response. We need to think about how to keep our protocols from ossifying that way too because the unfortunate reality of the network is that if you have any observable property of network traffic that does not change over time will get stuck and you need to be constantly doing some things to deal with that. Finally, as a parting thought, folks who are shipping things please do not ship network software without an auto-updater. It causes lots of pain and suffering for you and everyone else. Just build one of these. All right. We have time for a question. So great talk. I love the idea of Greece. What happens if you say, oh yeah, I'm using curve grufflump and the server calls your bluff? We promise that you never allocate those curves. So there's a grease draft that I actually haven't updated for a year. No, no, but the server is buggy. Oh. A buggy server that says, oh yeah, I'll do that. That would be impressive. I don't think we've seen a server that is confused about what curves it supports. Because. So hopefully that doesn't happen. Although because we've already deployed Greece, that server of universal law of users goes the other direction too. Thanks. I have a question regarding the chelsea compatibility mode. On the slide, you write that it is exactly, this is ugly, but only ugly. Do you have any formal reasons to buy this claim? In particular, in light of the preview stock by Tyler? It would be nice if someone could do it formally, but it's sort of obvious serialization silliness. So, before this, there were every record in TLS13 has three bogus bytes in there that are completely useless, but if you remove them, middle boxes will hang because they try to parse out records. I don't know. There are a lot of dummy fields in TLS. If we are unable to add dummy fields and keep things compatible without breaking things, that would be something that we definitely want to find out about. So, question, what do you ... it sounds like the take away from your last point was that protocols should actually be hostile to middle box analysis just to ensure we can change them later so we could just randomize things and always make it hard. Do you have any reason why we shouldn't be doing that? I would maybe like a temper that's going to make it difficult to understand what the invariance is. We promise the client hello, stays fixed, everything else go to town. And this is about enforcing ... whether or not implementations follow those ... so these invariance, every implementation that touches TLS needs to follow for the ecosystem to work. I think we should defend those invariance and make sure that enforce those invariance. I don't think that quite answered your question. I was wondering about the parts that aren't invariance, but that people mistakenly assume are. I don't have a complete answer for how to resolve this. This is something we'll probably be thinking about over the next year and hopefully you will see some ideas. But the obvious thing is encrypt more things because encryption is kind of nice, but TLS has a stopping problem where the first few messages are the one setting up the encryption. The best idea I have is to mutate them a lot, but doing that carefully is a little tricky. Thank you. Hi. One potential strategy to tackle this would of course be vendor shaming, like saying your thing is broken and you seem to be extremely reluctant to do that. I mean you know my opinion on it and we've discussed this before. The technical solution, so this is not entirely a technical problem. I think we need technical measures and I think also the ITF might need to have more of a conversation on whether the stuff is socially acceptable. But like when it's six percentage points of connections naming and shaming is not going to do a lot of good. Everyone's going to get sort of all angry, the vendors won't talk to us anymore and at the end of the day these folks don't have auto services. They're not going to get fixed, at least not for 5, 10 years and I don't want to be waiting for 5, 10 years for TLS13. When it's a smaller amount then Chrome has gone out of its way. Chrome has broken things before that aren't working right. But it's sort of a numbers and costs game. All right, let's thank David again.