
Tech • IA • Crypto
Bitcoin developers warn that reliance on a single dominant software client, concentrated funding, and evolving project culture could limit innovation and resilience without broader participation.
Early contributors describe being drawn to Bitcoin through a mix of technical curiosity, ideological alignment, and exposure to early use cases such as the Silk Road. For some, reading the white paper triggered immediate, long-term engagement, combining interests in cryptography, distributed systems, and economics. Others entered through corporate innovation roles or open-source experience, later transitioning into full-time development.
The “client diversity problem” refers to the dominance of a single node implementation, Bitcoin Core, which functions as both the primary software and de facto specification. Nodes are compared to internet routers: without running one, users rely on third parties. A lack of alternative implementations risks stagnation, limits experimentation, and concentrates technical authority in one codebase.
Developers argue that Bitcoin Core has become difficult to evolve due to its scale and review bottlenecks. While open to contributions, the complexity of reviewing changes restricts development to incremental updates rather than major architectural improvements. This constraint has contributed to gridlock around significant upgrades, especially since contentious changes like SegWit brought broader public scrutiny.
A key structural issue is the lack of a clear, machine-verifiable specification of the Bitcoin protocol. Instead, the Core codebase effectively acts as the standard, making interoperability across alternative clients harder. A formally defined spec could enable multiple implementations to coexist while ensuring they remain compatible and converge on the same blockchain state.
Contributors highlight a cultural shift toward geographically concentrated teams in hubs such as New York, San Francisco, and London. This model favors younger developers able to relocate and work within established organizations, potentially excluding experienced contributors who prefer remote or independent work. Concerns include reduced diversity of perspectives and increased friction for external contributors.
Funding for Bitcoin development is described as highly concentrated, with Jack Dorsey identified as a major backer through initiatives like Spiral and OpenSats. While widely appreciated, this concentration raises concerns about ecosystem dependence on a single benefactor. Calls are growing for broader participation from other industry figures and institutions to diversify financial support.
Competing node projects, such as Libbitcoin, report difficulty securing funding unless aligned with Bitcoin Core initiatives. Developers often work unpaid or self-funded for years. This creates a “chicken-and-egg” problem: without funding, alternatives struggle to mature; without mature alternatives, funders hesitate to invest.
Developers warn of future risks including consensus failures, insufficient onboarding of new contributors, and unclear governance for protocol evolution. While Bitcoin’s core value proposition remains strong, maintaining it depends on training new developers, improving review processes, and enabling multiple development paths.
Ensuring Bitcoin’s resilience may depend on expanding client diversity, decentralizing funding, and creating clearer development frameworks to support a broader and more sustainable ecosystem.
Uh, can you hear me? Is my mic on? >> All right, great. Hey, everybody. Um, >> check one, two. >> Yeah, there we go. We have a great panel. We got two Erics and a John. Um, and we're going to start with um, I think like an origin story. >> Um, let's start with Eric Vosll. Um, what was that? Louder. Can you turn my mic up or is it me? Am I the problem? I lost my voice yesterday on the first day of the conference. Are all >> mics on? Yours sounds better than mine does. >> Um, all right. So, let's start with the origin story. When you started working on Bitcoin, what was the hook that kind of caused you to be captured by Bitcoin and it was going to be something that you were going to work on the rest of your life? >> Um, everybody hear me? All right, it's working. Okay. >> All right. All right. >> Is it possible to turn our mics up a little bit? >> Probably my fan club. Uh, so I I got started on Bitcoin after my third software startup. Um, I was kind of burned out on on that and just um was looking to do something different and it I I the trigger was I read the uh Andy Greenberg Silk Road article in Forbes magazine just on a thing and um all of a sudden I went right to the white paper and I started reading and I've been working on it pretty much every day since then u with Philip who was at my last startup uh at the same time so about 13 years ago and it just uh combined find a lot of things. I I like secure I was ex-military. Um I I did a lot of tech startup stuff. Um economics. I'm a longtime kind of libertarian type. So all the things that I like doing all fit together. >> Hi everybody. Um my name is John. Um my origin story was around back in 20145. I was interested in Bitcoin. and I was doing tech lead and and corporate CTO for innovation labs roles for European multinationals in software development and I was orange pilling my colleagues at standup meetings every day I was interested in Bitcoin I was following and one day around 2015 Vladimir Vanderland the lead maintainer of Bitcoin core for nearly a decade at that time as well um followed me on Twitter and so I started looking into Bitcoin core the project and I really really really liked uh Vladimir's leadership style style as a humble servant leader um on the Bitcoin core project and I had had some significant multi uh open source experience maintaining open source projects and also contributing to large open source projects as well and um I had certain opinions about what I did not like in open source leadership and what I did like and Vladimir's leadership style check ticked all the boxes and I was interested in Bitcoin so that gave me the initial inspiration to look at working one day on Bitcoin core which I began to do in 2019. >> Awesome. Eric, >> what was the hook? >> Can everyone hear me? >> Yes. >> All right. Yeah. So, my background comes more from commercial software development. Um, I worked at a few startups earlier u in my life and then um at some point like around 2011 I I came across Bitcoin and uh it was just this super exciting idea that you know really I thought was was really neat. Um, at the beginning I just thought it was like a fun idea that, you know, maybe would get some traction. Um, I I didn't I mean, nobody really knew. Um, but it just seemed like a really neat idea and I'd never really done much open source stuff before. And uh, so I hopped on and and it was really um, an interesting uh, you know, experience to to to hop on to like the whole thing. So I got to see a lot of like, you know, earlier stuff that happened in Bitcoin and um, it's been a crazy journey since then. A lot of stuff has happened, a lot of new things. I mean, it's crazy that we're here that, you know, we can actually organize this kind of event and that, you know, so many people are so interested in this right now. So, it's just like, you know, mindboggling to look back on it and like back then nobody just like a handful of people cared about it. It was hard to fill, you know, a room even like half this size. So, um yeah. >> So, um we have three topics we're going to be discussing. So, the funding uh power and uh Bitcoin's uh client diversity problem. Let's start with the client diversity problem. Um, and I think Le Bitcoin is probably the best the best place to start with that. What is What does that even mean? The client diversity problem. >> I know it's something you made up. >> It's something I made up. >> I think you submitted this panel. >> Um, well, you know, you I guess some people might consider it a problem, other might, others might not. But, um, when we say client, we're talking about a node, which I guess can be confusing sometimes. But uh the node a node in Bitcoin is I always think of as a direct analogy to a router for the internet. Okay? You can't outsource your router and uh if you don't have one, you're not on the internet. And same thing with a node. You you can outsource it. If you don't have it, you don't have Bitcoin. You have a promise maybe something. So uh nodes are important. Um and um the Satoshi implementation um which is kind certainly the predominant node out there is uh is first and uh most widely used. Um but it's also uh very conservative because it's so widely used and doesn't have the opportunity to take you know take on big changes architectural type things. And so in 2011, Amiritaki, who started our our project, Leitcoin, it's not the only one, but it's the the very first attempt to make another node. Um, and uh, you know, we've taken on like major architectural changes and you know, approaching things from a different way. And um I think that's from a perspective of you know the problem the problem is without um all you know competing software implementations um one can become very stagnant and and and and not evolve uh we look at Satoshi's implementation as a prototype and I I think that's truly the the right way to look at it. It was an attempt to get something working. Um and you know rule number one in software engineering is you never ship your prototype because you get stuck with it right and everything has to be compatible with it and and so on. So um we think it's important that there be other nodes out there um not just from a perspective of having different choices and more software. Uh the node community builds these things and maintains them and that community becomes the experts in the field. The technical experts in Bitcoin are really the people who can build you know core when we say core software Bitcoin core is a brand but core development before Bitcoin core was called that is really just building nodes um uh prime you know and and and you need experts that can do that and they they um different implementations allows those experts to compete both in the software and for for people's um support uh in term Especially things like soft forks, hard forks, you know, different protocol changes, policy and these things have become very prevalent, you know, recently in terms of conflict. So if there's only one group, you know, it tends to be group think and lack of evolution. But >> I think we can agree that it works pretty well, right? It's been it's been the primary client for a pretty long time. >> It's incredible that it works. I mean, it's like a miracle that it works so well. >> It's unbelievable. Where are the limitations? What's wrong with it? like why would we why would we need alternative implementations? Uh it's hard to do a tear down, right? Because it would be mid-flight. But what are the current limitations that you see? >> What would you clean up if you could fix one thing? >> The question me >> John or other Eric? Yeah. >> Well, most people would answer that from a technical point of view, but I would actually answer from a different point of view, but go ahead. >> Yeah. So, I mean, so I think that you know, the first original implementation was a prototype. It was a proof of concept. Uh Satoshi really don't I don't think knew whether it was going to work or not. It was just kind of like you know let's see if this thing flies and u there's a lot of you know un unanswered questions as far as u you know how to uh maintain it long term. Um I think uh there there was no like succession model for how to actually you know um organize the project or leadership. Um it's got this model where you know you have some some maintainers that basically like you know make you know take care of the code and like you know make merges and stuff like that. It's it's open to anyone to be able to submit pull requests. Uh but you know I think most of the actual work or the the the you know the hardest part of the whole development process is um the review process, the testing process. Um it's much easier to write code than than to read other people's code. So, I think uh um it it's gotten to a point now where that that's really a huge bottleneck. Um it worked when it was a small project, but the bigger it grows and the more people that are submitting uh you know, pull requests and trying to to make make changes even without getting into the consensus stuff at all, um the harder it is to review it. So what's what that's led to is just these small incremental changes to the codebase uh that are that limit their ambitions uh and can't really change too much. So if you want to do like a major refactor, a major rearchitecture um it's too difficult to review. So right now the process just basically doesn't really allow that and that's not even getting into consensus changes like softworks or stuff like that. Um I was I was very heavily involved in the whole Segwit um softwork. Um and before that and and I I also was involved in some softworks before that. Before SegWit um basically everything flew under the radar. Nobody knew I mean except for the handful of developers who were working on stuff. Nobody even in the ecosystem even knew that softworks were happening. Nobody was aware of it or whatever software. I think SegWit was really the the first major controversial one where it kind of became like it kind of got a lot of the spotlight and ever since then it's basically become impossible. We're at a gridlock as far as like how we're actually going to change the code and I don't think that Satoshi ever really thought through how we would change consensus rules if we were ever to change consensus rules. There's a few quotes about how things needed to be cast in stone. Uh but there's a lot of new cryptography that has come out in the last 10 you know 15 years that is really cool that it'd be really nice to be able to add at the base layer. We just don't have a way to do it. So um I think you know we need to have some kind of better model for how to specify the Bitcoin protocol protocol itself and uh to have a a clearer way to ensure that different implementations are actually interoperable uh so that we can have different approaches uh to doing this and there could be multiple different projects that are working in different ways. Everyone can have their own style u you know and u as long as they're all interoperable it shouldn't be a problem. Uh but right now it's been really really really hard to get out of this model where where Bitcoin core is this reference implementation where everyone just kind of uses it as the spec. Um and it's not a spec that's very human readable. It's not a spec that's really easy to you know verify even you know with machines. So um we need something better. How do you solve how do you solve the problem? If everybody's here in Vegas, can't we just get together and it should be easy, right? Over some beers. John, what what's the pathway for? >> So, this is a topic I spend actually a lot of time thinking about since since some time now. Um, I think that there is a growing awareness that it that it is an issue to have one legacy implementation that is the reference considered the reference and consider the spec to which sometimes the bips are even modified to because the spec maybe is different in Bitcoin core and so that actually de facto becomes a spec and the bips need to be modified. But basically there there there is a confluence of things. Um there was a leadership transition over the past half decade. Uh the culture and core has changed in a few ways and I think there's just a growing awareness that if we had say a spec that different implementations could formally verify too to ensure correctness and interoperability that it would be a good thing in terms of competition as well. Um it would be healthy I believe but it is also more difficult. the solution would require more funding, not less, because you would have not one uh say core that's taking, I don't know, $10 to20 million per year budget. You would need several of these in order for there to be a relatively even playing field uh and a reasonable bar that different implementations could reach. And that is where we're seeing some current discussions right now among funding. Whereas before things were automatically sort of Bitcoin core development sort of was earmarked automatically to the reference implementation. The questions are now more does funding need to be also earmarked maybe equivalent amounts for competing implementations or supporting libitcoin or other ones that people are that might be in the works and that is a that would require growing the pie rather than cutting smaller slices of the same one I believe. >> Um you said the culture's changed um how has it changed? Well, see, when I began working on core around 2019, um it was a very different project with a completely different set of leaders and a different leadership style. So, the leaders completely changed um in terms of the maintainers, but also um core is now more or less um best the best way to make a career in core nowadays is to join one of the main big offices that are located in New York City, London, and San Francisco um as well as one that might be growing in Amsterdam. And so if you are not willing to relocate into one of those offices and mentor under the guidance of one of the senior people there um it is a much more difficult path. Let's say you're married with a mortgage and you're living in another country in Europe or elsewhere in the planet. So the the culture has changed more to a big city and younger people who mentor up with the seniors. But uh it might be good in terms of not only having options for node runners but also for developers like myself. I'm personally since four years based in El Salvador. Um, it would be good to have implementations that are more welcome of say more senior people with more seasoned experience who are not willing to relocate to New York City in the Manhattan office or to the San Francisco office um to have options for people where the culture is more welcoming to those kinds of developers. Now that is of course a little bit divisive but and that's not the only reason but that's also a reason why it might be more useful to have different options and paths available for people to work on Bitcoin who desire to do so. seems a bit antithetical to have sort of the centralized offices. It's not how things started. >> It's not how it was when I joined. Yeah, it wasn't how it was when I joined either. >> You also run the risk of having sort of a lower level of scrutiny for peer review because you work next to somebody. You get lunch with them every day. You start to >> as an independent contributor, you come across social process blocks. >> Yeah. >> Where your review comes against a block of five or six reviewers who are allied. >> Yeah. So I think that we can move into like the funding and power element to this panel with the time that we have left. Um I want to collapse the two because they're kind of the same thing at the end of the day. Um we referenced a couple of the offices. So we're talking about chain code, you know, Brink, um Spiral and Presidio. These are sort of the localized hubs for for developers and they largely rely on um I would say philanthrop philanthropy, right? They have you know donors that have been in Bitcoin for a long time >> apart from chain code and >> apart from chain code >> and spiral which is funded by Jack Dorsey. >> Yeah. Yeah. And look this is important to get funding there but how is it distributed in in in your view um is it distributed in the most effective and efficient manner or um are there issues that we should be discussing when it comes to funding because that ends up being the centralized power that we're that we're also sort of discussing around. One one thing I just wanted to add there is that um I mean we can talk about power as far as like um I mean yes of course um being wellunded is is is a good thing and and I think that you know definitely gives you more options but there's really you know some severe constraints on what can actually be changed in Bitcoin uh just because of the nature of it. It's a shelling point. It's a very strong shelling point. So it's not like people can just arbitrarily just start making changes to whatever they want, right? Um, I think the issue right now is more just that we're boxed into this particular model of how to do this development and there should be different approaches to do it. As long as they all are compliant with the same consensus rules and they all are interoperable, they can all sync from each other. They all converge on the same chain tip. Um, you know, there's no issue really. Um, I don't even really see that as competition in like the traditional commercial sense of competition because we're talking about free open- source software. Um, you know, one analogy that I like to draw is like, you know, a large, um, you know, high-rise building. Uh, there can be a lot of firms that work in it. Uh, you know, some of them might agree on some stuff, some of them might not. Some of them might even be competitors, but they all rely on the same building foundations. Um, and the protocol, you know, the actual spec, uh, the consensus rules, uh, the the network messaging formats, um, those kinds of things are are the base the very ground floors of the building, right? and the the and the foundation. And if that's not built well, it doesn't matter if people further up like, you know, have ideas of how to do things, how to improve the building, the building's still going to collapse. So, we need to have something very solid at the bottom that kind of grounds everyone. And so, all implementations have something very solid to follow that needs to be, you know, certain things that are very important that all implementations must do. And then everything else is free. If you want to work at an office, fine. If you want to do it remote, fine. If you want to, you know, like >> thinking about a formally verified specification >> that would be that would be that would be >> the long-term goal even for Vladimir the lead maintainer of Bitcoin core for years he was hoping for that to move forward. >> There's also the money issue. >> I would say that threequarters of the funding of the entire Bitcoin ecosystem comes from one very generous person that is Jack Dorsey. He funds not only Spiral, he funds um he's the main funer I believe of open sats and of many other offices that that depend on funding. So it would be good to find other people. Michael Sailor for instance who's been reticent to fund developers but other people besides Jack the threequarters of of I mean almost all of my funding over the past eight years has been from Jack. Thank you Jack. Um so it's very centralized in that one way but not as a anything critic not as a criticism of of Jack but as a criticism of other people who could step up and help him. And the second thing is that um some funding is for example you have open sats which full disclosure I help review uh applications for um they are an independent more independent entity that collects donations and then they redirect them to developers and also to some of the offices and that's an ongoing discussion right now as to what would be an ideal repetition between helping offices and helping individual developers directly. So there there are issues with funding centralization that I think could be could be better and particularly people more people like Jack helping Jack because the ecosystem really depends a lot on Jack Dorsey. >> Thank you. I very gracious and grateful. Thank you to Jack for his his funding support. >> There's a few more uh Jacks. >> There's one more thing I want to add to it which is that um I think there's there's plenty of money out there in the space to fund this kind of stuff. It's just that people don't really know how to uh you know h how to productively invest it into something. You know what are they actually putting their money into and what what are they going to get out of it right? Um, right now with the current architecture and structure of the system, it doesn't really lend itself to an ecosystem that can grow organically that way and that can support different models. Um, and and and can have, you know, a lot of different the people that that want to fund this stuff actually be able to promote their particular way of doing this. Um, which can be their own unique idiosyncratic way of funding this thing. That's totally fine as long as like I said before they they uh stick to the same consensus rules and they can sync to the same tip as all as all the other implementations. >> Eric, you and I have been working on this for a while. Um and very grateful. I want to shout out the Human Rights Foundation as well because they're they're starting to make a dent on this issue um uh with their uh uh funding of developers and different projects. But what's your view on um the the state of funding and how it's changed in recent years as opposed to when we first went out, I guess back in like 18 or 17 to try and get some funding for L Bitcoin? >> My my experience from when we first went out to today is it hasn't changed much. Um the vast majority of what we call core development uh Bitcoin funding or tangental stuff that kind of around the near periphery of say node development um from what I can see the vast majority of it goes only to projects that are somehow tied to Bitcoin core for example we we've had we've had developers been with us like you know 13 years right um 10 years 12 years pe people you know have a long history do good work uh people are aware of it but explicitly uh rejected because the work is not tied to Bitcoin core. For example, Bitcoin core has a project called li uh used to be called liitcoin uh liitcoin consensus and now it's kernel lib lib kernel or something. Yeah. >> Right. It's the it's a script processing and and we were told that well if we if we adopted that then the person could get funded but if we maintained our own script engine or if we didn't have some other connection to bitcoin core weren't going to fund us and they weren't funded. So, uh, we've seen this for years, right, for time. >> You do have now one developer that's funded by open sats. >> Yes, we we we have had people funded. I'm not saying that we haven't got people funded, but it's extremely unusual. Like the first foundation funding we've ever got was Open SATS just recently. In the past, we had a minor I'm going back 10 years. A minor funded a couple of our devs for a couple years because they were looking for alternatives to Bitcoin Core. Probably came out of the 2017, you know, SegWit thing, right? Um uh we had a few years ago we had one whale who wanted to remain anonymous um funded one of our developers for two years. Aside from a little contract work here and there from some of our guys that's all we've ever been funded. Okay. We got four guys sitting right here and myself. We get another one in Italy. We've got a real team and we're all um basically volunteers, right? And and most working full-time. Um, so the people who have gotten funded have probably funded themselves 3/4 of the time, right? So when you and I went out to do this, I told you it wasn't going to work. Remember? I said, "We're not going to get funded." This is going back a few years. I said, "What's going to happen is like I've I've never taken money and it's my policy. I don't I I'm retired. I I've never taken any money to do anything related to Bitcoin." And um that's about independence, right? And um I said that we're not going to get funded until we're already successful. Once we're out there, we're running, we have a you know a chunk of the network, then people will come and fund us, right? But it's not going to happen unless we volunteer to do it. And that has been the case over the last, you know, 13 years working on that's been my experience. We do get some, but it's a trickle compared to compared to that, you know, what core where core gets. And I think it's the same for the other node projects as well. And there aren't that many um and most have gone away that have that have attempted this. This is this is a lot of work, right? So, um I do think that there may be some change coming and that's a consequence of some of the things that John's talking about. Culture changes at core. It's frustrated some people. Um the the controversy like Knots has been around for a long time. You know, it's it's a fork of courts. never really, you know, we've never kind of put it in the same category cuz um but because there hasn't really been an alternative, uh you know, conflicts arise and people start looking for an alternative and we you know, our our we haven't released a node um in eight years really, right? We got an old one, it's not really worth running and we've got a a very significant one now that's going to be released soon. Um and that'll provide people an alternative, but there really have been no other alternatives. not you know fork of core there's um which anybody can do of course there's BTCD which I I don't know the level to which it's been maintained I think it's a decent project but um it's I don't really see it as competitive or differentiated architecturally right >> and not NBTCD would be happy to have developers working on the projects >> right they need more help too >> now to be clear open sats has made it I think more or less clear at least on social media on Twitter that they're willing to fund developers for these projects but in the year and a half almost two years that I've been looking at applications. I haven't seen one from a developer to work on. So, um, developers, where do they go? They go to what's seen as the only game in town until very recently and they they apply to work on core. >> So, it's going to there is a definitely a chicken and egg problem. >> I'm I'm going to be encouraging our folks to do to put out more applications because um that's kind of a new thing at least from my perspective, right? This kind of you can kind of apply and your application fans out to a bunch of these organizations and they they have review processes and boards, right? is over the last few years this has become the norm. Um and uh I do think there's a there's a lot of goodwill out there and there's a desire to do more. Um I'm saying up to this point that has been has been very limited. Um and I think the desire to do more is coming from these controversies where people are starting to realize that you know there there needs to be really alternatives not not necessarily politically not about changing consensus. We don't we don't work on anything pertaining to like changing policy or changing. just do the engineering work to make a node perform well. That's it. That's all we do. Um and so but because of these things, right, this has become more visible because of the conflicts and controversies. People realize like what would happen if you know core continued down this road of declining performance which is a it's an architectural issue, right? It's a linear validator. Um eventually we won't be doing validation anymore, right? All of all of the engineering design work I would say all but the major engineering design work in Bitcoin core to solve the performance issues in terms of initial block download full validation all that have been oriented towards no longer validating right assume valid assume UTXO assume UTXO a lot of assumptions right and eventually we're we're going to get um minor commitments and it's going to be done we're not going to validate anymore and that's because of an engineering problem it's not a consensus issue it's not anything but an engineering problem it can be solved and it should be solved, but it's too difficult to make those substantial changes you need to make in that codebase. And so we set out to do it, right? Um I think until we until recently when we've demonstrated it actually working and performing that well, people didn't think it was possible. And that's what alternatives provide, right? A different point of view. Even on the other side, there could be a niche perhaps and I'm not advocating necessarily for it, but for a more conservative core because core has a lot in flight and core has some very large changes uh both coming and just passed like the legacy BDB wallet database removal and so there could also perhaps be a niche for people to have one that lags behind core >> mean the Jimmy Song project with those >> uh something that lags bit behind core and does things more slowly but perhaps has backward compatibility for a longer period of time because core only supports two versions back beyond the current version. So that's a fairly somewhat aggressive for people who want to run nodes that are older and not upgrade or maybe they have an old legacy wallet and they're scared to >> we need a slower development. >> Yeah. >> Yes. >> Yeah. So there could be more prog like notch is a bit more progressive in some ways. Um maybe liitcoin is a completely different >> we are very aggressive in in in moving the architecture. >> There are some developers who I believe are are thinking about working on new clients that might be more futureful in some ways. some more progressive even yet and yet so maybe a a slow core might be useful to some people as well because core has a lot in flight too. >> So um we're we're basically out of time but last question. We've seen so many changes throughout the the culture and community. It's not just within the development community. We have ETFs and treasuries and Bitcoin dive bars now. uh when you think about the next, you know, 5 years of Bitcoin, um just real quick, optimism, concern, like what do you think is in the pipeline? Is there is there something that could happen that would cause you to to stop working on Bitcoin? >> I mean, I've always been very concerned about uh you know, consensus failures and uh some at some point just people not converging on the same chain. And I think that uh um you know a lot of people started to tinker around with consensus rules early on and try to you know created a lot of shitcoins and stuff like that. Um and I think that you know experimentation was necessary but um u my my biggest concern is for posterity sake. Um all of the current core developers and the previous ones are going to retire or have retired already and there's nothing really uh you know no real strict no really strong guidelines for like the next generation to know what they're doing. Um, I think that that's my biggest concern. I'm not really that concerned about the price or like, you know, speculation stuff on it or whatever. I think as long as it holds together, the value proposition remains intact. >> Awesome. >> The the new developer, >> we're running over, so we got to go quick. >> Okay, we got to stop. The new developer pipeline is very important and educating and training new developers. Currently, that's been very centralized as well currently since since I've been around. I believe it's improving and I hope we continue to improve that. Eric >> as well as the funding to central >> prediction is hard. >> Anything going to cause you to stop? Nothing's going to cause him to stop. Look, we need more jacks, but we also need more Erics and uh John's. Thank you guys so much. >> More Erics. Yes. Every year this community comes together to celebrate, to debate, to build what comes next. And every year the stage gets bigger. Sound money center stage. So where do you go to celebrate the next chapter in Bitcoin history? You come home. Nashville. July 2027.