 A lot of the core team, they seem to be really gung-ho on going with the off-chain scaling solution, at least prioritizing that first. So much so that I have a quote here on red recently that says, we should not change Bitcoin to accommodate more users. And that's one of the things that they were talking about in the IRC. So they were going with like the said with soft working rather than let's say going with the hard working. And they were also criticized notably like by other people like Jeff Garzik of the risks that are inherent by gung with the more complicated solution. So how can you compare this with let's say Tom Xander's flex cap proposal of taking the hard work approach and how might core's roadmap be wrong? This would take an hour to answer and more importantly I don't think my opinion matters at all to any of the parties involved, nor should it. This debate about big blocks and small blocks and how we scale Bitcoin. First of all, I don't think it's accurate to say the core is focused on not scaling the core layer. It's, as you said, it's a prioritization issue. Which one gets prioritized first? Now, I have a nuanced opinion on this, which pisses off everybody. Because if you have a nuanced opinion, then you're sitting on the fence and both sides can throw eggs at you for not taking a side. And I'm not gonna take a side because I think that both sides have merits. And really the question is a matter of prioritization and sequencing and conservatism versus a more aggressive approach to scaling. From time to time, my opinion has changed as I've seen new data. More recently, two days after the Ethereum fork, I thought, whoa, that went extremely well. A clear 95%, 5% splits technologically executed beautifully. This is gonna put a lot of pressure on the core to come up with a similar solution for Bitcoin. I was wrong. I was very wrong because a week later, actually two weeks later, we discovered that even though technologically the fork worked, politically it failed. And suddenly you ended up with a 70-30 split. And that was a disaster because there was not enough provision in the software to deal with replay attacks. It cost a lot of exchanges some money. I think there's some people from Coinbase in here who may have suffered some losses because of that, because of the replay attacks. I know other exchanges did too, or I heard that other exchanges did. So after that, my opinion was revised. And I think in Bitcoin, politically, a hard fork is a hell of a lot more difficult and will cause a deeper schism. So I don't think it's as easy as one team is right, the other team is wrong. I think we're going to have to let this roadmap play out. And for the time being, it seems that the majority of the participants in the system are continuing to put their trust in core, as long as core continues to deliver on their roadmap to a certain approximation. I'm not worried, because I think in the long term, what we're going to do is we're going to scale in the second layer, and we're going to scale the core layer with a block size increase. And we're going to do network optimizations, and, and, and. The scaling options are not either or, they're, and, and, and, and, and you just have to decide which comes first. I think a lot of this drama is unnecessary. And honestly, in terms of segregated witness, soft fork versus hard fork, I think soft fork is a better way to go. I do. I think we're going to get to the cleaner and quicker than a hard fork. I think a hard fork, given the current political situation in Bitcoin, is way too dangerous. Even if it was for something that everybody agreed on, like Segway, which I don't think you can even get that agreement. So that's probably a very nuanced answer about a very nuanced question, and I'm sorry if I didn't give you more of a direct answer. I don't think there is a simple black and white answer to that problem.