{ "episodeId": "SLP594", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "stephan_livera": { "name": "Stephan Livera", "role": "guest", "tag": "STEPHAN" } }, "segments": [ { "speaker": "stephan", "time": "00:11", "start": 11.37, "text": "Hi everyone and welcome back to Stephan Livera podcast. Joining me today or rejoining me today is Antoine Poinsot. He is a Bitcoin developer and also working at Wizard Sardine who are known for Liana mainly and also you might know them with Revolt. So first of all, welcome back to the show, Antoine. Thank you. Glad to be here. Great. And so we're gonna be talking about the great consensus cleanup, as well as some Bitcoin Core vulnerabilities that were recently disclosed. but, first, let's chat a little bit about, Liana and what's the latest there." }, { "speaker": "stephan_livera", "time": "00:44", "start": 43.55, "text": "Well, the Liana is going good, doing good. the team grew up a little bit, so allowed us to deliver more, than we, we could before, because it's always frustrating when you have a lot of demand from users, then you can't, can't deliver. Everything at the same time. And we are, yeah, also, we cleared up a lot of, misunderstanding on the use cases as well. People had some, idea of what we ended and it was fixed, and we had to explain a lot, going to conferences, talking to people, and there is definitely a lot of interest in the inheritance use case. And now the main thing is, so there was first step, a lot of misunderstanding on the use case, and second step A bit, it was a bit hard to use the wallet, to, to get started with the wallet, you have to use your own full node and everything. So that's the, our focus right now, trying to make the wallet more usable for the regular guy interested in, securing his inheritance. Gotcha." }, { "speaker": "stephan", "time": "01:47", "start": 107.12, "text": "Yeah, and, listen, if you're interested, you can check out my earlier episode with Kevin, where we went kind of more in depth on, some of those aspects of it. I'll put the links in the show notes, as always. and so, yeah, I guess the other interesting thing is just, I'm curious how you're seeing the appetite for more complicated uses of Bitcoin, right? Because I guess a lot of people up until now might have just been thinking, \"Oh, just single signature, you know, my standard 12 words," }, { "speaker": "stephan", "time": "02:16", "start": 136.32, "text": "She said, \"There's a lot of, let's say high net worth Bitcoiners, and a lot of those people are very interested in inheritance, right? Because we're all gonna die someday, they wanna make sure that they can pass them on. So what has it been like getting people on board with the inheritance idea? \"." }, { "speaker": "stephan_livera", "time": "02:33", "start": 152.52, "text": "With the idea, it was definitely, we didn't have to get them onboard, they were, they were already onboarded, and it looks like- Oh, sorry, sorry." }, { "speaker": "stephan", "time": "02:40", "start": 159.84, "text": "I mean, I'm, I guess I should clarify, how did you get people comfortable with the security of what you're implementing as opposed to, you know, the idea of inheritance?" }, { "speaker": "stephan_livera", "time": "02:50", "start": 169.86, "text": "I think people get it very easily about the security of the time lock. let's say the trade-off, because everything is trade-offs, anyways, and you, you have this key that is, that can always spend and this other key that can only spend after a time lock, and you have to access your wallet, let's say, every other year, in order to, to keep the second key inactive, and it's a trade-off that a lot of people are actually interested in making, in order to make sure that, they have a recovery solution. And it's also the case that-- it's the, well, I believe obviously that it's the best trade-off available, because you've, you've got-- you can't do it really otherwise, right? Because you can use a multisig, but everything is only in one dimension, only in the number of keys and the number, the threshold for spending in the keys. But if you want to have self-custody at time t and not have self-custody at time t plus one, because you're dead, you have to have some mechanism in place, such as- As you're in self custody and then you're not. So once we explain it to users, I think they, they do get it pretty easily." }, { "speaker": "stephan", "time": "03:58", "start": 238.17, "text": "Yeah. And so just refresh my memory here, I'm just trying to think back to my conversation with Kevin. this is the one where you need to cycle it roughly every twelve to eighteen months, right? And in, and in that time, after a certain time period, it's, those coins are spendable by somebody else, and this is the, the important thing to understand. Understand is this isn't just like at an application level, this isn't like on somebody's server, this is like at the Bitcoin protocol level. That's the important point to understand, right? Yeah, yeah, yeah." }, { "speaker": "stephan_livera", "time": "04:27", "start": 267.44, "text": "Yeah. We've seen a lot of communication around inheritance use cases also, which were- Which can be fine, people can use whatever they want as long as they understand the trade-offs, but sometimes there is very trusted solutions, with regard to, the, recovery mechanisms for the heads with, with Liana The trade-off is, that you have to refresh your coins, but it's enforced on Bitcoin, like your hair, can never spend your coin as long as you're alive and using your wallet every fifteen months. So." }, { "speaker": "stephan", "time": "04:58", "start": 298.15, "text": "And so, yeah, so the, I guess the conversation right now, or at least the current technology, is that, you know, it, it, it just requires this, let's say, annual, on average-ish time, let's call it, recycle. I, is that the term you're using? You kinda have to go and refresh, recycle The term isn't a huge deal, but the point is you have to do a transaction every year to kind of make it, to stay in the time lock, that you, in your desired, time lock, aspect. So that's probably just the main trade-off today, and hopefully we'll, we'll see what happens in the future. If more covenant technology comes to Bitcoin, then maybe that could be changed also." }, { "speaker": "stephan_livera", "time": "05:37", "start": 337.29, "text": "Yeah, definitely. some types of covenant could help to have the time lock start ticking by the time that you want to trigger a recovery And you don't have to touch it every other year. But we're not there yet, and it's already working well." }, { "speaker": "stephan", "time": "05:53", "start": 352.77, "text": "Okay. Yeah. So, so I guess we'll leave that for a future conversation, I mean, because we don't know if we'll ever get that. but let's talk a little bit now about the great consensus cleanup. So, I know this is something you've been working on a lot recently and trying to push that forward. So, let's try to, again, take it back from the top here just to keep it accessible for everybody. What is the great" }, { "speaker": "stephan_livera", "time": "06:15", "start": 375.38, "text": "It's originally a soft fork proposal from Matt Corallo in 2019 about fixing Bugs in the Bitcoin protocol which require a soft fork to be fixed and can be fixed only with a soft fork. So it's trying to fix," }, { "speaker": "stephan_livera", "time": "06:43", "start": 402.6, "text": "the costs, potentially worst case cost to join the network, to participate in the Bitcoin network, to run a node, it tries to fix, issues with, timestamps and how we manage time, on the chain and how it can be gamed by, by attackers with mining power and all the technicalities in the, in the Bitcoin- That's cool." }, { "speaker": "stephan", "time": "07:08", "start": 427.62, "text": "Great. And so what would you say are the main items that are trying to be fixed inside the Great Consensus cleanup?" }, { "speaker": "stephan_livera", "time": "07:16", "start": 435.6, "text": "I think the two most worrying bugs right now are the validation time for blocks and especially the time" }, { "speaker": "stephan", "time": "07:25", "start": 444.92, "text": "warp bug. Gotcha. And so let's, let's talk through some of those. So let's start with the time warp. What is the time warp bug? The" }, { "speaker": "stephan_livera", "time": "07:34", "start": 454.12, "text": "time warp bug is, alright, let's describe how Bitcoin actually, well, let's refresh the memory of the auditors around how Bitcoin, actually managed time, manages time. So, on Bitcoin, every, node is going to receive blocks, broadcasted through the network and created by miners, and attached to this block is a timestamp that's usually about the current time when the miner found the block, and as more- More mining power is r-is going to join the network, blocks are going to be found, quicker, faster, and, as more hash rate is leaving the network, for instance, if there is a change in the price, of Bitcoin in dollars, maybe some miners are going to turn off the machine, and so as a, as a whole, the network is going to find block less faster. And in order to make the time, the b-the time of, blocks intervals On average, ten minutes, nodes are going to change the difficulty for miners to find blocks. So as there is more hash rates, they're going to increase the difficulty as there is, less hash rate, they're going to lower the difficulty. This is done, every two thousand and sixteen blocks, so which is roughly equivalent to two weeks. So basically, what every block and so every note, and since it's, it's a deterministic process, every single node in the network can do this math, and they're all going to do the same math and arrive at the same conclusion. So they're going to every, every single node every two thousand and sixteen blocks. It's going to check the, timestamp of the, block, two weeks ago, so the, the block two thousand and sixteens ago, and the next block, and the, and the last block, and it's going to compare the timestamps, and if it's, if it took more than two weeks to mine the last two thousand and sixteen blocks, it's going to lower the difficulty, otherwise it's going to increase the difficulty. The issue, so that's all great and nice. The issue is there is, an off-by-one here, since the original implementation of Bitcoin by Satoshi, which is that actually it's not the two thousand and sixteen last blocks which are considered, it's the two thousand and fifteen last blocks which are considered. And in this case, it means that the first block of a period isn't the last block of the previous period. It means that the re-target periods don't overlap, which allows miners to try to always keep back in time the block timestamp of the first block of a period while continuously moving forward in the future the times of all the other blocks, including the last block of the period, and as they're doing that, they're faking that it takes them more time and more time to mine the blocks. Even though it, it didn't, and so they are lowering the difficulty. As they, as they lower the difficulty, they can, perform the attack even faster. And so after, let's say the, the attack, takes to the first three target period, which is two weeks, at the end, they're going to be able to keep the first block in the past. They're going to start another target period. At the end of this three target periods, they're going to end up with, nodes are going to believe that it took them four weeks to mine the two weeks block period, so they're going to halve the difficulty, so they're going to find the next two thousand and sixteen blocks in one week, and then they're going to do the same thing, it's going to halve again and halve again, and as they perform the attacks, it, it gets exponentially faster essentially, and they can, pull down the difficulty of mining blocks at the minimum, which is one, at the minimum in thirty nine days." }, { "speaker": "stephan", "time": "11:46", "start": 706.46, "text": "Wow, okay, so in the space of thirty nine days. Now, it means, I guess, let me understand it. Let me ask you so I'm understanding it correctly. So you're saying in the space of thirty nine days, assuming malicious miners, they could make it so that they could just dial like lower the difficulty dramatically and just like mining blocks out really fast. That's the, that's the implication, right? Assuming the majority of malicious miners. Gotcha. And so, as you're saying, that, that would require some level of either a fifty one percent, like a large mine miner or a car-- a cartel of miners to collude to do this. And I guess the argument you're making here, or that could be made here, is they might have an incentive to do that." }, { "speaker": "stephan_livera", "time": "12:26", "start": 746.39, "text": "So they don't have an incentive to completely kill the network, even though they could. So there's, there's many things there, but they might have-- basically, they might have an incentive to increa-- to increase the block rate and to increase the block space available, basically. But, yeah, let's, let's start with the fifty-one percent thing because, I think it's more important than people usually said it was before because the time warp attack isn't new, I didn't find it, Matt didn't find it, it's been known for a very long time, and people usually, some people are usually dismissive of it because, oh well, it requires a fifty-one percent attack. Sure, but it completely changes the threat model of a fifty-one percent, right? Because in Bitcoin, we have this proof of work which makes it so that a fifty-one percent attacker can only censor transactions for as long as he manages to keep the fifty-one percent active. So it continuously, cost him money and money to censor transactions, which at the end of the day could make it after one day, after two days, after one month. In this case, with the time warp, if the fifty-one percent attacker manages to keep the edge it has over the network, it can kill the network in, in thirty-nine days. So it changes the, the, the threat model, I think, of the fifty-one percent. That's, so, yeah. That's the first thing. And actually, just" }, { "speaker": "stephan", "time": "13:54", "start": 834.0, "text": "on that, can we just explain, you, you mentioned just killing the network? My understanding is they would basically mine out the remaining subsidy like straight away, and then like, like would they just still have? Be making blocks, but just happening like blocks would just be happening so quickly that it would just be like a, a bit of a farce, right?" }, { "speaker": "stephan_livera", "time": "14:16", "start": 856.43, "text": "Yes. So blocks would be happening very quickly, which could cause a lot of issues with regard to convergence on the network. So nodes in different parts of the world could have not the same tip at the same time, have major reorgs, if you have major reorgs, basically. You can't trust your, your payments in Bitcoin, it would be a major issue for protocols using time locks, such as, Layerana, such as Lightning. Also, let's say if, if they mine a hundred thousand blocks right away, all your penalty, penalties on Lightning channels, all your HLCS, nothing is secure anymore. And then of course they could also, if, in general, a fifty-one percent attacker isn't incentivized to, the, it's not a regular Entity incentivized to maximize profits, it's just like an outside attacker, and if they want to hurt the network, the block rate is the, the, the, the basic spam limit, so they, they could spam the UTXO set at, at a rate, a mad rate. So, yeah, they, they would, they could severely harm the network. I said kill to, to, to, to get their jobs, but they could severely harm it." }, { "speaker": "stephan", "time": "15:30", "start": 930.12, "text": "Yeah," }, { "speaker": "stephan_livera", "time": "15:31", "start": 930.54, "text": "gotcha." }, { "speaker": "stephan", "time": "15:31", "start": 931.38, "text": "Yeah, okay. and so, yeah, obviously that's a bad thing. Maybe we wanna try to fix that, and I think it's one of those things that, yeah, it just seems like it's kind of been out there, but I guess it's, it's needed somebody, someone like yourself to kind of Put the team on their back and actually, go do the work of figuring out how to fix it and so on. So can you, explain for us what would it take to actually fix this? So" }, { "speaker": "stephan_livera", "time": "15:56", "start": 955.98, "text": "the fix is actually pretty simple. So, what you want to do is basically to put the, the, to, to remove the off by one on the twenty-fifteen blocks period. You want to put it twenty-sixteen, but obviously just changing that is hard work because updated nodes could have, could make Could treat that blocks as valid, whereas a non-obedient node could treat it as invalid. So what Matt proposed to do in twenty nineteen is simply to tie the timestamp of the last block of a period with the timestamp of a new, of the first block of the next period, such as they can, the, the first block of the next period can only be ten minutes in the past as the last block of the previous period. So it, it basically annuls the, possibility to do a time warp attack, and it's, it's a very, very tiny fix. It's like Couple of lines. Good. yeah. Can I get back to the political games maybe also? Yeah, sure, sure. on the Timewarp, because I think there is multiple aspects. So there is that, about an, an, an outside attacker, trying to, to harm Bitcoin could leverage the Timewarp attack, and there is also the fact that miners incentivized to maximize profit. Wouldn't kill entirely the network, but they might be interested in increasing slightly the block rate to mine more transactions, to claim more subsidies that should have been allocated to miners from the future, and short-sighted users trying to just, I don't know, for instance, randomly put garbage on chain could be incentivized to, deal with that, to pay less fees," }, { "speaker": "stephan", "time": "17:46", "start": 1065.67, "text": "let's say, spam uses of the chain per se. Like more block space or more to put their spam into, or even, let's say, even monetary users might want lower fees. So, I mean, it's kind of both sides, it's monetary users and spam users, let's say. Yeah, a-and, and I think it's a-" }, { "speaker": "stephan_livera", "time": "18:03", "start": 1083.44, "text": "The pretty bad, pretty bad incentives, which are, which are bad in this case, because short-sighted miners can just increase their profit by, by leveraging this attack, short-sighted users can just pay less fees by, accepting this attack, and it all comes at the expense of the, the long-term health of the system. And that's not great, and also it can become more likely as The block reward diminishes exponentially. we can s- we might see miners play more games, four years from now as the block reward really, really becomes small. So we might want to fix this before then. I, and by no mean I want to, to urge people also, like urgency is a red flag. We've lived with the, with the time lock for ten years, th- fifteen years maybe. that's not urgent, but I think it, it's becoming potentially more urgent because there's less, more incentive for miners" }, { "speaker": "stephan", "time": "19:07", "start": 1146.99, "text": "to, to, to try it now. Back to the show in a moment. This show brought to you by CoinKites dot com, the creators of the best Bitcoin hardware security devices. such as the Coldcard Mark IV and the new Coldcard Q. Now, we use Bitcoin hardware security devices to keep our keys offline, our private keys offline. Now, the way these work is you can do that setup, write down your twelve or twenty-four words on those, the seed word cards, and keep that secure. Now, you can use this device to interact with the Bitcoin network using software such as Sparrow Wallet, Electrum, or Befiktor Desktop or Nunchuk, as a few examples. Now, you- You have a range of security features that you can use with these devices, such as passphrase, you can use seed x or my favorite is multi-signature. Now, if you're starting in a basic way, just start with the device and the USB-C cable, plug it directly to the computer and use it that way, and then later improve your setup. But I believe these devices are great at helping secure your coins, especially as you start to migrate up into multi-signature security. But don't be disheartened or don't be, scared away. They are accessible, and I think you actually do learn about Bitcoin in the process. So to get yours, go to coinkite dot com, use code Livera to get a discount on your cold card. And now, back to the show. Yeah. And look, I, I think this is something I've, I've tried to make this point as well. Like we talk about being low time preference, we should be fixing our bugs, we should be trying to keep our house in order. And so I think it is a good thing for people to talk about it and, yep, consider fixing" }, { "speaker": "stephan", "time": "20:46", "start": 1246.44, "text": "Maccarone had that idea for in twenty nineteen of how to fix it. Has there, have there been any updates on that in terms of how to fix it, or are people kind of mostly agreed on how to fix this thing?" }, { "speaker": "stephan_livera", "time": "20:58", "start": 1257.76, "text": "For the" }, { "speaker": "stephan", "time": "20:58", "start": 1258.01, "text": "time" }, { "speaker": "stephan_livera", "time": "20:58", "start": 1258.23, "text": "walk, I" }, { "speaker": "stephan", "time": "20:59", "start": 1258.99, "text": "think there is broad consensus on, on the fix. Okay, gotcha. Okay, so that's pretty much like that's done. and then let's talk about the other aspect, the block validation part. So can you explain? What is the, what is the implication of, you know, this block validation problem, or maybe if you could just explain what is the block, this block validation problem to begin with?" }, { "speaker": "stephan_livera", "time": "21:23", "start": 1282.88, "text": "Yes, so when receiving a block, a node validates the transaction inside the block, it, it validates that the Bitcoin exists, it validates, that the, person making the transaction actually could make the transaction. So it, it is done through the scripting system. So, can, can this person actually unlock? transaction and all this process takes a little bit of time. For regular transactions, it takes nowadays with the advances of the technology, to, to validate, notably with the LiPSEC-P and everything, it takes It's a very small amount of time. That's good, because, yeah, I, I want, no, okay, I, I was getting sidetracked. I'm getting back on the right track. So, and that's good. However, you can make pathologically difficult transactions in blocks, such as blocks become very expensive to validate, for nodes on the network. That's bad because obviously we want to keep Bitcoin accessible, we want, the, the barrier to entry to training a full node to be as low as possible. First of all, but it's especially bad because it can incentivize miners to play games, because as miner, as a miner, right now I'm incentivized to include whatever transactions to get, to get more fees. Third, if I can get my competition to actually be stuck on validating a block for two minutes, and I get an edge of two minutes, which is huge in terms of, competition in the mining, space I might as well do that. And so, it's possible today on Bitcoin to create blocks which can take up to one hour and a half to validate on a Raspberry Pi And about three minutes on a beefy server, which could typically be used by a miner." }, { "speaker": "stephan", "time": "23:17", "start": 1396.57, "text": "So, and so there's an implication, and obviously, you know, people who wanna keep the network decentralized, make it easy and accessible for people to run their Bitcoin nodes, y-you ideally wanna help fix this idea of how to, as you said, craft these malicious transactions that are used to sort of maliciously take down somebody else's node or to sort of, make it really slow. slow for them to be able to keep up, because then if there's blocks in quick succession, now people are falling out of consensus and then it starts to become a bit of a shit show when you're trying to send transactions and it, it just gets-- it's gonna cause problems for everybody." }, { "speaker": "stephan_livera", "time": "23:53", "start": 1432.73, "text": "I didn't find blocks which would be as bad as, making people unable to, to, to, to keep track of the chain because the block which takes, hour and a half, takes I don't remember, but hundreds or dozens at least of blocks of preparation. You need to prepare to your attack, so it wouldn't be as bad as completely fucking up the network, but it's still pretty bad. I see." }, { "speaker": "stephan", "time": "24:22", "start": 1461.72, "text": "Yeah, so as I understand, for security reasons, you don't wanna necessarily say the exact mechanism of how that's done, but can you, are you able to tell us a bit about where the fix ideas are for that, or at least, you know, where the community is? That there or at least the developer community?" }, { "speaker": "stephan_livera", "time": "24:40", "start": 1480.5, "text": "So for, yeah, for the development community, so Matt Corallo, proposed some fixes back in twenty nineteen, and it actually, so as to your question from the beginning about where everything is at and what's happening, it's been the main If there's a point on which I've been working for the past six months, off and on, because obviously I've got a day job as well, but, off and on I've been working on this point, which is trying to make sure, because I- I don't think, so I think, well, I found a blo- a block which could, bypass the fixes from Matt from 2019. So I've been working on new fixes and figuring out, do my new fixes actually cover, all the pos-possible attacks? Also, there's been, inputs from a lot of people," }, { "speaker": "stephan_livera", "time": "25:31", "start": 1530.84, "text": "so yes, that's Well, I'm at currently, I think we've settled, we, we being, AJ, AJ gave me a lot of feedback, and, walked with me through different mitigations, and I think we settled on a, on a couple, proposals, couple small fixes, simple, obvious, and also, interestingly and, nicely, which have less of a confiscation potential con- Confiscation aspect to them, which was a concern with the fixes from that." }, { "speaker": "stephan", "time": "26:06", "start": 1566.16, "text": "And can you just explain this confiscation idea? As I, as if I'm understanding it, it's like you're trying to make sure that there's not a possibility that maybe some old, older user has like lost access to their coins because of this fix that you've put in. Is that the rough idea? Yes," }, { "speaker": "stephan_livera", "time": "26:22", "start": 1581.87, "text": "exactly. Exactly. Basically With the fix is, making some behavior possible today, invalid, and we want to make sure that nobody has potentially been using this behavior in the past, given that the, recommended fixes, from twenty nineteen were, were in the scripting system, they were concerned around, well, maybe some have, someone has Hidden pre-signed transactions which were using a very weird smart contract and has deleted the private keys and everything. In this case, if we make the new feature invalid and the person doesn't broadcast his transaction for, I don't know, five years, and then the taproot activates, then- It wouldn't be able to be" }, { "speaker": "stephan", "time": "27:13", "start": 1633.13, "text": "burnt or kind of frozen and not able to be spent potentially. But I guess this is like, you're talking about like a very edge case kind of, you're trying to make sure that there's not like this edge case person or people who are losing their coins out of this. It's" }, { "speaker": "stephan_livera", "time": "27:26", "start": 1646.1, "text": "like, you can't get more edgy than that. It's like very, very, very far fetched, but still, it's, I think it's Very good, to be concerned, for the development community to uphold this, principle of never, never confiscating the money of, of Bitcoin users. And so we had, at first, I was proposing to actually only enforce, the new rules for UTXOs created after a certain block height, so this person, this theoretical probably non-existing person, could still have spent his, UTXOs because they were, created in the past. So I, I scanned the UTXO set to, see if there were, existing potentially offending UTXO, and there is no existing potentially really bad UTXO, so it would have been safe to, to Do that, in the future. But my new recommendation, my new recommended fix is to, do not involve that anymore at all. So it's" }, { "speaker": "stephan", "time": "28:32", "start": 1712.07, "text": "a little bit safer. Okay. Yeah. okay, so I guess as you said, this is kind of, this has been your focus for the last six months, and it's not, I guess, ready to deploy now or anything, but it's like you're sort of, yeah, you're pushing it forward. can you explain a little bit about that next few steps and what you would like to see happen" }, { "speaker": "stephan_livera", "time": "28:53", "start": 1733.35, "text": "Yeah, I don't, I don't know really. there isn't a handbook of, how to, to, to, to walk those steps. I think I, I really got into it into re-as a research project at first, like Is it actually that bad? Like nobody picked it up for five years? Maybe it's not that bad. Well, actually, it's a little bit bad. So, I, I, I was trying to maybe convince myself that it was worth, a whole software, it was worth changing the game, the rules of the game of Bitcoin, and I, I, I think I convinced myself that Yeah, we should probably do that. So that was the first step, convincing myself, then there is convincing, all those, I think, within the development community, If people think it's important, I've talked with a, with a few developers, presented at a few developers' events, had pretty good receptive feedback. So yeah, I don't know what the, the next, the next steps are going to be. At some point, I'm going to have to reveal these, mitigations for the block validation time. I didn't want to give, to give away, what was the issue, but if I, if I give away the, the fixes, people are going to figure out it, so I That, because it's a soft fork, you have to have users' consentment anyways. yeah." }, { "speaker": "stephan", "time": "30:20", "start": 1820.03, "text": "Yeah, that's gonna be a little tricky, but, let's just, Yeah, I guess we'll just have to kind of hope for the best there, and see that if we can, at least kind of build up enough support amongst kind of, you know, the node committee, let's say the node people, and the node runners, and maybe get some of the miners on board, To at least, the mining pools at least onboard, so that there's--" }, { "speaker": "stephan_livera", "time": "30:46", "start": 1845.86, "text": "I think we still have a bit more development to do, at, at least, so writing a new BEP, because the BEP from Matt Corallo was not even included in the BEP repo, it was just a draft. that he drafted, and then quickly after he left, contributing to Bitcoin Core. So, yeah, maybe writing a bit, writing an im- an implementation. AJ has, an implementation of a bug fix for one of the bugs, another one, from the consensus cleanup, and his, Bitcoin Inquisition, could be a good way to, to start testing that in a semi-production, let's say." }, { "speaker": "stephan", "time": "31:24", "start": 1883.95, "text": "This show also brought to you by Mempool dot space, the leading Bitcoin and blockchain visualizer, I use it all the time when I'm checking transaction fees and trying to understand what is the state of Bitcoin's mempool. You can search transactions, historical as well as unconfirmed ones, and also see a great way to visualize things across the Lightning Network, Liquid, mining, and so much more. Also, for those of you with an enterprise, they offer a mempool dot space enterprise program. So for those of you as part of that enterprise program, you might wanna get in- Increased API limits, and you might wanna have increased access to the team in terms of feature requests. You might wanna have special branding in terms of how your custom instance of mempool dot space looks. So to sign up for that, go to mempool dot space slash enterprise. And now, back to the show. Okay, so yeah, when it comes to, if they don't, I mean, yeah, I guess that's that, right? Like it just kind of, you sort of, you're at this point where you need to get enough popular support eventually. Eventually, you ne- you You need to build up enough popular support, and, that's just what it is, it's what it's gonna take to get it over the line. Yeah. So, let's talk a little bit about some of the Bitcoin Core vulnerabilities. I know a bunch of these were recently disclosed, on the Bitcoin Core website, I believe, July just recently, July 3rd, and as we record this, it's July, 23rd. So, you know, 20 days ago. do you wanna just talk to us a little bit about some of these, Bitcoin core vulnerabilities and why they're being, you know, disclosed now?" }, { "speaker": "stephan_livera", "time": "33:05", "start": 1984.99, "text": "So why, so there is why, why now? why? Because, there is, there is a lot of upsides to actually disclosing publicly disclosing vulnerabilities affecting the software, and especially in the case of Bitcoin, we want at first to, inform users Like, well, we are, we are developing the software, we are aware that there was a se-cu-rat-ive vulner-ability in the software. Would be nice if we tell you. also, it's very important to inform development and to make sure that we can learn from our mistakes, because, the security vulnerabilities are reported to a small subset of the Bitcoin Core contributors. There is a lot of contributors to- Oh, I think I lost you. I know. Okay. yeah, go ahead. Yeah, yeah. so and there is a lot of, of contributors to Bitcoin Core and, different, yeah, at different levels, of contributions to Bitcoin Core as well, and most of them Would not be aware of this, security report and some would not be aware that there was a vulnerability at all. And, yeah, in order to make sure that we, Get improve the practices of development, make the software more secure, we need to learn from that. Also, we need to incentivize, well, not maybe not incentivize, but give a clear process for security researchers, which may incentivize them to actually go through this process or to actually start looking for bugs into Bitcoin Core at all. And if they find one, at least there is a standard process that they can follow out there, and instead of just Never getting credited or just, if they don't get credit and get upset, I don't know, recklessly disclosing it, which could be bad as well. So we, we, we try to get a standard process out there and I guess one small, smaller point as well was to clear up some misconceptions about Bitcoin Core never having bugs, that it wasn't necessary to update the software, and it was putting users and the network at risk as well. That's, that's for the why. Yeah, I" }, { "speaker": "stephan", "time": "35:32", "start": 2132.18, "text": "think that's an interesting point as well, because I have seen this, even, even on my podcast, there have been some guests who sort of come out with this idea of, \"Oh, just don't update your Bitcoin Core, we don't, that way we don't have to kind of agree with what developers are saying.\" Which, at one level, you could sort of say, \"Yeah,\" but on the other level, you've got to remember there's security fixes that are coming, and sometimes there are security fixes that are Done in a way that are hidden, because the developers would rather not, if they don't, if they don't, let there be un-updated nodes out there who are vulnerable to these kinds of DOS attacks or other attacks." }, { "speaker": "stephan_livera", "time": "36:07", "start": 2167.02, "text": "Yeah, as, as usual in Bitcoin, you are dealing with other people's money, so you need to be very, very conservative and try to obfuscate when you're fixing the bugs to try to not give it away. so we try to do that. Sometimes it's given away in public, sometimes, most of the time, no, it's not But, there is also," }, { "speaker": "stephan_livera", "time": "36:29", "start": 2188.96, "text": "sure, like with regard to people saying never updating their node, it's always balanced down to what's your best option if you are, if you think that you can do a better job than the Bitcoin Core development contributors, sure, like you can fork the software, as long as you don't change the consensus rule, you should be able to connect to the Bitcoin network and try to, to go on about making a better software. But if you're not going to do that, you should probably update to the latest version of Bitcoin Core because there's going to be bug fixes. so yeah, with regard to why now, like the, the other, I guess, like the other initiatives on Bitcoin and in Bitcoin Core as well, it's like just everything happened on a voluntary basis. some people said that it wasn't an issue, turns out that there was more than a couple of people that said it wasn't an issue, and a few people volunteered to actually do something about it. yeah, just starting to, to get the ball rolling, it was-- we started really discussing that in, September at the, at a Core Dev. so a Core Dev is just an event for Bitcoin Core contributors to meet in real life and have Discussion in real life instead of on IRC the time. And, we started discuss-discussing that, and then we started to have a couple of us walking on Actually digging up past historical reports of vulnerabilities which were never publicly disclosed, and it took a lot of time. There were, there were a couple fun moments where, long time experienced contributors would like find old reports that they had forgotten about and be like, \"Oh, we thought that we had five reports, actually there's a sixth one, I just found it.\" And then one week later, \"I just found a new one. Did you know about this one?\" \"Well, no, we didn't.\" So, and as we went through that, we tried to, set up some software to keep track of vulnerabilities and try to start to triage them. In parallel, we wanted to come, to come up with the standard process, to treat, vulnerabilities. So We discussed and came up with a process which we then tested on this historical bug report. Like, if this report gets reported right now, how do we treat it? when do we want to disclose it? how do we disclose it, and what, severity do we assign it? And We've done that, then we decided that we had a pretty good policy to start with. It's not set in stone, but it's better than the current situation, and, we decided to share the policy we wanted to go for with the rest of the contributors, Who were, there was basically no objections and a lot of people were excited about doing, doing this work, so we went forward and we suggested that we would gradually Start adopting this new policy, for public disclosure. And the way we would do that is start by, releasing the reports from the past ten years and gradually up to the point where we are at the last version for which we want to disclose vulnerabilities. So we did that for all the bugs up to version twenty-one of Bitcoin Core, which was released in twenty twenty-one. So, more than three years ago. And then, so we-- and that, that we, we released all the reports for back to 2015. So there was a lot of reports, but a lot of them were Harmless, right? Nobody is running a Bitcoin Core from 2015 anymore. And so then we are going to release, so as you said, we are recording this on the 23rd of July, and we are going to release at the end of July the bugs, in 21 which were fixed in, version 22. Then next month, in August, we're going to release if there is any bugs in '22 fixed in '23, then in September the bug fixed, in '24, and at this point we will be at the version twenty-five and twenty-five is still supported. So, because, so maybe yes, I'll switch on that." }, { "speaker": "stephan", "time": "41:09", "start": 2469.44, "text": "Bitcoin Core, you talk a little bit about this kind of end of life, that aspect, yeah? Yeah, exactly. So" }, { "speaker": "stephan_livera", "time": "41:17", "start": 2477.47, "text": "Basically, there is a new version of Bitcoin Core every six months, and, the Bitcoin Core maintainers and, couple contributors maintain Well, a few contributors, not, not only a couple of you, maintain version up to the latest minus two. So the latest right now is twenty-seven, and twenty-five and twenty-six still get some bug fixes, backported, and then, a new version of twenty-five, which is called Points, release, is released. So twenty-five point one, twenty-five point two, point three, and for those, we are not going to disclose the bugs. Then when twenty-eighth gets released, twenty-five goes end of life. When twenty-five goes end of life, if there was a security vulnerabilities, reported for it, we are going to announce it to, to the mailing list, and two weeks after that, we're going to publish the details about," }, { "speaker": "stephan", "time": "42:23", "start": 2542.75, "text": "the vulnerabilities. And the vulnerabilities, yeah. Okay, so just to summarize, as you said, on average every six months there's a new- Big number, big version number, twenty-five, twenty-six, twenty-seven, twenty-seven as we speak is the latest. And so I guess you're saying, for the latest release and then two releases behind that, there's some backporting. So that's the term you were using, which is relating to how even though we're on version twenty-seven right now, they may go back and fix some of the bugs in twenty-five or twenty-six, and that's called backporting the, you know, the fixes for the bugs, but then, you know, once that particular version End of life, that's when these things are publicly disclosed and it says, \"Hey, you know, this DOS bug was there or this particular bug and the details. \" So at that point, it's sort of like, \"You better be updated on the latest, on one of the later versions so that you aren't vulnerable to having your Bitcoin node taken down or something like this. \"" }, { "speaker": "stephan_livera", "time": "43:18", "start": 2597.8, "text": "Yeah. So basically, basically what you, you have one year and a half to upgrade to the latest version, and you always want to be on the latest version because... Oftentimes, bug fixes, harmless bug fixes are backported to, previous releases, but there is a lot less churn and a lot less new features and new development on old versions which are still supported, and you can't just hide, security fixing in there. So oftentimes Point releases don't get security fixes, so if you want to always have the latest security fixes, you need to be on the latest major version. Yeah, just be on the latest major and, yeah." }, { "speaker": "stephan", "time": "44:05", "start": 2645.45, "text": "Okay, yeah, fair enough. I think it's an important point for people to understand out there. did you have any other particular-- I mean, we're not gonna like go through each of the individual ones, but it seems like just as I look at some of the ones that got released on July 3rd or at least disclosed, it seems a lot of them relate to DOS. Using various different vectors, right, whether it's like difficulty headers or the INV messages, orphan handling, like, is there anything in particular you wanna mention, just kind of at a thematic level there?" }, { "speaker": "stephan_livera", "time": "44:33", "start": 2673.27, "text": "Yeah. There is a few interesting ones, but I think one where a lesson can be drawn is the, the, earliest one, the LCE from 2015, which was actually originates from a dependency in Bitcoin Core. So there is a ton of stuff that a software needs to do and that usually you don't, do not re-implement as a software developer, you use third-party libraries because you don't want to reinvent the wheel, but as it, as it turns out, you don't maintain this code and it is compiled and included in your software binary. So people are dependent on this code, and if this code has security issues, your software has security issues. And so this bug in particular was pretty interesting because, some security firm, audited, this dependency, found buffer overflow, inside, which is pretty bad in terms of vulnerabilities because it allows potentially to execute code on the machine, on the victim's machine, which is as bad as it can get in terms of vulnerabilities. and when being informed of that, Vladimir Vandelan, long-time, Bitcoin contributors and, previously maintainers, of Bitcoin Core Looked into trying into the other parts of the, of the library and basically tried to edit it himself and found another flaw, and he found another issue, and this issue could actually have been exploited potentially on Bitcoin Core. It was exploitable on other software, but it was not demonstrated on Bitcoin Core, but it was very, very close. And I guess, yes, there is a lesson in how we need to handle dependencies, trying to potentially reduce the number of dependencies that we want to use in Bitcoin Core to have in Bitcoin Core to, like, maybe Your fancy new use case which needs this, dependency library could be cool to have, but maybe outside of Bitcoin Core inst-instead of inside Bitcoin Core, which, which brings back to the discussion at the, at the beginning of trying to draw a lesson for development as well. Try to secure Bitcoin Core going forward. Yeah," }, { "speaker": "stephan", "time": "47:09", "start": 2828.69, "text": "yeah, interesting. And as you said, it, it seems, yeah, important to minimize dependencies, and I know that is what, there are Bitcoin Core developers out there trying to work to remove things, remove these kind of upstream things where possible, and so, yeah, interesting. So I, I guess let's summarize a few of the key points. So we, we covered a lot of stuff today, but I guess the main, I guess the main thing is this great consensus cleanup idea. It is a because of some of the things that are consensus changes, right? As you said, the, this, time warp bug and this, off-by-one error, as well as certain aspects of how blocks are validated, that, it would be a good thing to fix these things and, yeah, hopefully people, at least staying aware of these issues and, you know, with an open mind to try to go and fix them. so I guess we'll, we'll leave it there. Any final, closing thoughts for people?" }, { "speaker": "stephan_livera", "time": "48:05", "start": 2884.95, "text": "Update Oh, especially if you're on 22, because we're getting to announce Verneon Bridge is for 22 at the end of this month. So when this episode is out, well, upgrade to the latest version. Just upgrade to the latest. Yeah. Yeah. Okay, well, great. Well, thank you, Antoine, for joining me today. Thank you for having me." } ] }