From 972167ac10f1cf9621d3f29124c3178a6b5799e9 Mon Sep 17 00:00:00 2001 From: Carla Kirk-Cohen <42311294+carlaKC@users.noreply.github.com> Date: Mon, 2 Sep 2024 10:33:38 -0400 Subject: [PATCH 1/5] lightning-specification: add 07/29 (#510) --- .../2024-07-29-specification-call.md | 367 ++++++++++++++++++ 1 file changed, 367 insertions(+) create mode 100644 lightning-specification/2024-07-29-specification-call.md diff --git a/lightning-specification/2024-07-29-specification-call.md b/lightning-specification/2024-07-29-specification-call.md new file mode 100644 index 000000000..2aaa81fda --- /dev/null +++ b/lightning-specification/2024-07-29-specification-call.md @@ -0,0 +1,367 @@ +--- +title: "Lightning Specification Meeting - Agenda 1185" +transcript_by: Gurwinder Sahota via tstbtc v1.0.0 +tags: ['lightning'] +speakers: [] +categories: [] +date: 2024-07-29 +--- +Agenda: + + +Speaker 0: Are we on the pathfinding one or did we pass that? + +Speaker 1: I think [redacted] should be attending because they added their new gossip status thing to the agenda. I think they should join soon, but we can start with the verification, where I think it just needs more review to clarify some needs. But apart from that, it looks good to me. 1182. That's the kind of thing we want to get in quickly because otherwise, it's just a mess to rebase everything on top. + +Speaker 0: 1182 is on my list for this week basically. As far as getting through it. + +Speaker 1: There's one thing that I commented in there. The way [redacted] put it, whenever you use blinded paths for payments, you usually do not use blinded paths before the introduction point, but you could in theory. They phrase it like it's something that we may want to do in the future, but do you think we ever want to do that? Because if we do that and use blinded path before the introduction point, that means that the sender needs to create dummy encrypted reception data and dummy values for the fees and CLTV, and I think it's really a mess. But I can't think of a scenario where we would want to use blinded path before the introduction point for payments. But if someone… + +Speaker 0: Do you mean the sender just like making their own blinded path and using that independent of the receiver's blinded path in the invoice or…? + +Speaker 1: Yeah, but what would that gain for payment? + +Speaker 0: So that's a scenario, right? Basically, I have my own line of path and I use that in addition to yours. That's just to clarify that. Is that the scenario we're talking about or something else? + +Speaker 1: It's just that in order to get to the introduction point, once you have found the route to the introduction point, do you make it look like it is a blinded path and tell each node inside that route that they are inside the blinded path and should relay as such? + +Speaker 0: Oh, up until the introduction point. So you're saying a fully blinded route. Half from me, half from you. + +Speaker 1: Yeah, what I mean is that I don't see what we gain by adding a blinded path from the sender. Oh. Hi, [redacted]. We were discussing 1182 and my comment about — let me post. + +Speaker 0: I guess it's like uniformly where everyone does the same processing and it looks like one big tunnel. I guess you would lose the explicit errors outside of the tunnel, which is nice assuming that the part outside would be larger than the part inside. + +Speaker 1: It seems to me that it's useful to not use blinded path before the introduction point because as you mentioned, you get nice errors and you can more easily retry. It's a bit annoying to actually use. Make it look like it's a blinded path before the introduction point because you have to construct the encrypted recipient data correctly. And it's a bit annoying, and there doesn't seem to be any benefit to that. But maybe it’s a use case I'm not seeing. + +Speaker 2: Yeah, I thought about doing that too, but then I decided we've got code that works. We'd have to add a whole heap more code, and you'd lose the errors. + +Speaker 0: Yeah. I don't think we do this right now. I guess one question I have while reviewing some of the blind paths code for dummy hops. So, for example, whenever y'all add dummy hops, are you adding dummy hops just to pad out the size of the blinded path or are you actually adding real fake policies or CLTV and fees? If you're adding real fake policies, what do you do for the fees, right? Because I guess you would want to add additional fees, but not too much that you're making them pay too much or something like that. I'm just curious about it because I was just thinking: ‘What should we actually do here?’ We could just do nothing. Does that make it look worse than if we did something? Because at least for the old shadow route, it was basically just CLTV. But now, you can add other stuff potentially. So I was curious: How dummy do you make the dummy hops look basically? Or how real do you make them look? + +Speaker 2: We don't. It's like this big ‘fix me’ game. We should put dummy hops in here, right? You could argue that you should do what we used to do. We used to flip a coin and pick a random channel and go: ‘Let's pretend we were going down that one.’ Then, we'd add fees — it used to be that we would add fees and CLTV for that. But with MPP, we dropped the fee thing. It wasn't as obvious anyway. In theory, yeah, you should do both, but I think I decided that three dummy — like, making it always three hops long. So, ‘cause we only introduced single — it's a single if you've got a private, like an unannounced channel. That's when we automatically put one in. I'm like: ‘Really, we should just always make it three hops rather than a single hop.’ If we're gonna use it at all, we should make — three is a good number. It covers most of the network. It's believable. Then you've got the question of if you're just going to take some extra fees. I'm doing it for your own good, man. + +Speaker 0: Yeah, I think it's really interesting because you can say: ‘Well, take some extra fees, but my node gets the fees that happens to be around.’ + +Speaker 2: Exactly. Yes. + +Speaker 3: So actually, regarding the fees, the recipient could just eat these fees. Like, you could always use… + +Speaker 0: Yeah, the recipient can get more. + +Speaker 3: You can always use your blinded routes with zero fees, and you eat these fees. + +Speaker 0: Mm-hmm. It's a little tax. + +Speaker 3: That way, you hide the fees completely, and there is no way to guess the channels that are used using these fees. + +Speaker 0: Yeah, I guess given we already allow overpayment in that regard as well. As far as the blinded hops, what we do now is basically, rather than targeting a fixed value at the moment, we take all the blinded paths that we have and make sure they're all the same length. Maybe one of them was five, one of them was three, and one of them was one. We'll make sure they're all five. That's what we do at least right now. Obviously, we can add that constant in the future, but there's just some code I was reviewing for MPP stuff in particular. I realized that we do a similar thing to what [redacted] mentioned last week as far as making it look like they all go to the same destination when you have multiple blinded paths for a particular hop. You can read the algorithm. So we have that now, and we're trying to get this into the next minor release, so we can get some more testing and stuff like that in it. + +Speaker 2: There's a problem with eating the fees, and that is that if they've got a base fee and they use MPP, you have different amounts. So I wonder if you're actually creating a vector where they can potentially probe. I mean, because if you say: ‘Well, okay. We'll just pretend it's zero fee, right? And we'll just end up with slightly less than we expected.’ If they MPP across it, you'll end up with a different number if they have a different — if they ever said base fee involved or rounding in fact. So it's not entirely clear to me how that would work cleanly. But when the fees are so small at the moment that it's de minimis. You probably could do it and say: ‘Well, you'll allow some smaller payment than you expect because it's eaten by fees.’ Maybe. + +Speaker 0: Yeah, it could just be like below one sat even, just top up 100% of each of them or something like that. Yeah. Depending on the amount. It's interesting. Gotcha. Okay, but I guess going back to the top thing, I guess we're saying: Is it actually useful to add binary passes yourself as a sender before the introduction point? Probably not, seemingly. You could do Trampoline, of course. That actually gives you some stuff. But maybe in this case, you basically just lose information. I guess the only argument would be uniformity of processing for all the nodes, but I don't know if that's a big deal either. + +Speaker 1: Yeah, it's just that I found the paragraph on the spec a bit confusing because it makes it look like you should do that by default unless the previous nodes do not support route blinding. So I think it should be clear that whenever you do payment, the thing you do by default is not used to find the path before the introduction point. So, just a small clarification. + +Speaker 0: Okay, I see the comment for that now. + +Speaker 2: Yeah. + +Speaker 0: So, 1182 is on my list. I'll promise to check it out before the next thing I have on my high-priority spec list. Should we talk about gossip status? Something new? I haven't read it yet. + +Speaker 2: Yeah, I added it. So, one of my nodes had fallen behind. I misconfigured it and it didn't allow incoming connections for a while. The gossip was like: ‘Hold on. Why have you lost half the channel updates?’ I was like: ‘Okay, I could sync it manually and stuff.’ But then I'm like: ‘Really?’ Or I could play with the heuristics and try to get them to try harder, and then I'm like: ‘Ugh.’ But what I really want is to be able to send a message out to peers to go: ‘Here's how much gossip I have’ and have them go: ‘Nope. You need all of it’ and just flood me with gossip, right? So basically, it's the simplest message you can imagine. It says: ‘I know about this many channels. I've got this many channel updates. I've got this many node announcements.’ The idea is your peer goes: ‘Wow, you're way behind’ and just sends you all the gossip. So, I've got a scratch implementation of this. Of course, using the feature bit plus 100 and message plus 30,000. When you connect to a peer, we just send this message, and if it supports the feature, it should look at it. Basically, I picked a random number of 100. I looked through what's the — because you could be one block behind. Like, you could be a little out, right? There was one block where we had like 96 channels open. So I went: Okay, 100 is a good number. So basically, the recommendation is that if you've got 100 more of something than they have, just send them the gossip. Just send them everything. It was the dumbest thing I could think of. It will work, I think, and not give too many false positives. Because I mean, I know that LDK for a while were every so often just asking for all the gossip, and that's a bit antisocial. This is designed to be a little bit nicer. So you can at least tell that the peer is way off. + +Speaker 4: We still do that when we connect because there's no other reliable way to make sure you have all the gossip. + +Speaker 2: Yeah. So I sympathize, but I'm like: ‘Well, this is slightly less antisocial, right?’ At least the other person opts in to sending you all the gossip. Sure for V2, I want fast, intelligent minisketch, blah, blah, blah, but this is basically a bandaid until then. + +Speaker 0: So, isn't this basically introducing the old initial gossip dump that we took out, but this is like doing it with more context, I guess? + +Speaker 2: Yeah, basically. The nice thing is that for bootstrapper, obviously, it just works really well. If you end up somehow missing a whole heap of data — particularly, I'm always nervous about node announcements getting lost because they're not kind of essential. So you can function reasonably well and without any node announcements at all. Because there's no really great way of syncing those up. So if you lose them somehow or whatever. So yeah. This is kind of about as trivial as you can get, and I'm hoping it won't have too many false positives. I don't want to — because my worry was you get into a loop where you start sending this and everyone starts going: ‘Oh, wow, you're way behind,’ and for whatever reason, you reject enough that you're asked to stay out of sync. + +Speaker 1: Should we then also have requirements about gossip timestamp filters that say that you have to do a graph dump if you receive a gossip timestamp filter that covers basically everything? Should we entirely remove that in that case and rely only on gossip status to decide whether to do a graph dump on the other peer? + +Speaker 2: That would be possible. I mean, at the moment we treat it as a trinary, right? I think that it is maybe still useful to have the whole ‘I want everything' message. But yeah, this could supersede that if we're on support it. + +Speaker 0: One question for you, [redacted]. So, I guess you have this old node. Did you find that for some reason it didn't catch up? Or was it that it was super slow? Or you were looking for a faster way? Or was it in some weird…? + +Speaker 2: It was in a weird state. It wasn't sinking half the — like, it seemed to have all the channels. It just didn't have half the channel updates, and I'm like: ‘What the hell?’ I don't know. I'm guessing that — so we pick a random peer and we query it. Then, if we don't get a response, we go: ‘Okay, I think we're caught up.’ I tried not to put any heuristics, like we should have this many channels or something like that. But it seems to be missing a whole pile of channel updates, which is really weird. So yeah, I should debug that on the side as well. But I was like: ‘We keep hitting these kinds of problems where people end up with partial gossip.’ I was tempted to go the map route for a while, where every minute, we ask someone: ‘Hey, give me everything.’ Or randomly pick a peer when they connect or something. + +Speaker 0: But don't we kind of have that? As you're saying, for a while, we didn't implement the time test. Now, we have timestamps. Timestamps are great because nowadays, we ask for the heights, intersect that, and then also the time the timestamps, which is a way that you can spot check. So, I should say that I think we already do have the ability. It is more round trips because now, we have a lot of channels. + +Speaker 2: Yeah, we spot check every so often, and then, we kind of double the number that we asked for. I'll have to check my heuristics again. But we basically go: ‘Huh? What have you got in this range?’ If you give us stuff we don't know about, we start doubling the range till we cover the entire possible lifetime. I'm not quite sure why that heuristic is not working. So, I'm gonna look through my debug logs. But yeah, I decided to try to fix it properly. [redacted], you were gonna say. + +Speaker 4: I really feel like it does seem increasingly like we've all found weird issues with gossip, either on our nodes or someone else's nodes. We've never really managed to track down a cohesive set of issues here, and it seems like we haven't in fact tracked down any issues lately for the gossip problem. I'm a little hesitant about adding more band-aids. Like, band-aids are fine, but it seems like we should have more than a band-aid here, and we might maybe prioritize doing something minisketch-y. + +Speaker 2: Yeah, Gossip v2 makes this much, much easier, which is kind of… + +Speaker 4: To be clear, I'm not raising my hand to actually do the work. + +Speaker 0: We're working on the implementation. We got to revise some draft PRs, but it’s moving along. + +Speaker 2: Well, this implementation was easy. I modified the spec. So originally, I was like: ‘Oh, if they were behind on node announcements, you should just send the node announcements.’ But then I added that ‘may send everything.’ So we basically go: ‘Huh, you're more than 100 behind on something.’ We just flood you with everything we've got, which is nice and dumb. We keep our flags, we'll only do it to each peer once. It's no worse than them just asking for all the gossip currently anyway. But yes, [redacted], I agree with you. But I definitely don't want to — I mean, we looked at some designs to do minisketch with Gossip v1, and they're all ugly. It's much nicer with v2. + +Speaker 0: We're gonna be working on referring up some of the blind paths I just mentioned, and then, we'll basically be back fully on finishing up the concept of v2 stuff. Or at least what we have of that so far. + +Speaker 2: We've got our release coming up within a month. So this will probably ship out in that, but with dummy numbers. So at least we can test and drop and stuff, and see if that helps my node. + +Speaker 0: Cool. + +Speaker 1: Alright. Next up is offers. Where are we on that? Now a few comments directly on the PR that potentially need to be addressed, and I'm not sure if everyone is caught up on the implementation. + +Speaker 2: Okay. I need to do another pass, but our implementation is finally caught up. So, our master branch should be interoperable with everyone. + +Speaker 5: We have to do the experimental ranges still and add new test vectors. I noticed also that the invoice error section is kind of empty, and there's a fix me, I think, in there. One question I had was whether invoice errors are expected only in response to invoice requests or either invoice requests or invoices. + +Speaker 2: That's a good question. You can definitely send an error in response to an invoice. So, I think it's either. It's basically an error field. + +Speaker 3: I think usually you don't set a reply path when you send an invoice. + +Speaker 5: We did not until — I think we're going to add it soon. But it helps us in the sense that if we get an invoice error back for outbound payment, we could abandon the payment. We, of course, authenticate that. + +Speaker 2: Yeah, it does give you an ability to — actually, I have to check our implementation. We may not set a reply path there either, in which case you just discard whatever error we have, but you certainly could. + +Speaker 1: You just could reuse the blinded path you used to send the invoice request. You send the invoice request through a blinded path, you receive the invoice, and you can send the invoice through the same blinded path as the invoice request, right? + +Speaker 2: You can, but we would ignore it because we never allow you to use — we strictly match that you're using it for the intended purpose. In theory, yeah, you could. The same way you could push an unsolicited refund a similar way, right? + +Speaker 5: Yeah, we don't have state for invoice requests. If we get one, we're not going to hold on to it to the blind path. Oh, and we also authenticate request inside. Or at least we're adding that code now. + +Speaker 2: The experimental ranges, I managed to get it wrong. I've moved the recurrent stuff, so we still support the old recurrent stuff in a, I think, still works kind of way. We moved that into the experimental ranges to actually test that that works. Also, ‘cause it's cleaner. So that seemed to work pretty well. It was kind of painful because we used to have some really — it was really neat to cut a single range out of the invoice to cut two ranges out. It was just a bit fiddly, but we've got that now too. + +Speaker 1: I'm curious: In which case would you want to send an error when receiving an invoice? What kind of errors did you encounter in your implementation? + +Speaker 5: One if you receive an invoice where you don't understand the features, you'd send back an invoice error. That would be one. + +Speaker 1: But that should never happen because there's a features field in invoice request. So the invoice should never set a feature that was not set in the invoice request, right? + +Speaker 5: I think they were independent fields, right? Or independent features? There's nothing in them at this point. Actually, no, invoice has features, but invoice request does not. + +Speaker 0: Either like it's missing fields that are required or something like that. Or say it gets bad or something. I don't know. + +Speaker 2: Expired. + +Speaker 1: Yeah. Or expired. + +Speaker 2: Wrong amount. + +Speaker 5: Yeah, expired, so they're on. + +Speaker 0: Yeah, it's like a sanity check, I would think. + +Speaker 1: It would basically just be a way to get debug logs on the invoice generator to see that they have a bug that they need to fix, right? Because this is not really actionable in an automated way. You would just redo a request. + +Speaker 5: I mean, you could see that when you have currencies, if the conversion is not to their liking, they might send back an invoice error. + +Speaker 0: Yeah. Or the receiver just knows that the sender can't pay versus expiring. I guess it's one of those two. Either you get the fast error or they don't pay. Then, you just mark it as a dollar something. + +Speaker 1: Interesting. + +Speaker 2: I mean, if it's already paid once, for example, you'd be like: ‘No, I'm not giving you more money.’ + +Speaker 5: I think for that case, we do not send back anything because we actually send multiple invoice requests. So if we get multiple invoices, we'll just only pay the first one and ignore the rest. It's very normal for us, I suppose. + +Speaker 2: Yup. + +Speaker 0: Cool. Should we go to the BOLT 12? Mutual auth and contacts? + +Speaker 1: Yeah. This is just picking your brain on this. We wanted to have a feature where you're able to have something that really looks like a payment app. When you pay your friends, they see that it's coming from you. So when you have trusted contacts and you send a payment to one of your trusted contacts and you are also in their trusted contacts list, we can automatically display: ‘Oh, this is coming from Bastien. This is coming from someone else.’ The way we initially did that was by reusing the payer key that was in our offer. So the payer key I use in my offer is actually the public key that identifies me as a contact. But [redacted] pointed out that we should probably decouple those because then, this is really tied to either a single offer or I have to reuse the same payer key in my other offers, which can be an issue for wallets that want to handle multiple offers and segregate them for privacy reasons. So, do you agree that we should do something completely different and find a completely different way to exchange those public keys and handle a public key that identifies you as a contact? Or should we reuse something that is inside the offer somehow? + +Speaker 0: So you're saying add like another key? I guess like an opt-in? + +Speaker 1: Yeah. You derive from your seed a specific key that is your contact key, and this one is never going to change. When you see one of your friends, you can send them a QR code with some specific encoding that says: ‘This is my contact key.’ You can store that and you can put this — when I use that as a payer key when you receive a payment, that means I'm the one paying you. + +Speaker 0: Yeah, that can make sense. I guess either way it'd be like opt-in, right? That you would check, like use my contact key or something like that? + +Speaker 1: Yeah. The thing is, then we need a way to distribute those keys and I'm wondering whether we could include them in BIP 21 URIs so that you can put them in your BIP 353 address directly. This way we'll have ways to pay you and ways to know that you are paying them. I don't know. + +Speaker 4: You don't strictly have to — I mean, yeah, there was a bunch of conversation back and forth on the bLIP. You could imagine a key exchange protocol when you first pay. So you don't have to — I mean, there's a bunch of different property questions around what exact properties you want. It was my opinion that the ideal outcome is that a recipient can only see that someone paid them if you're mutually in the contacts, in the lists of each other. So, if I pay Bastien regularly, Bastien won't learn that I'm the one paying Bastien unless Bastien also has me in his contact list, which makes it a little easier. It makes it so that we can do things like exchange keys that are derived from the name or something. Versus if you want it so that you reveal that you're paying twice if they're in the — Bastien’s in my contact list, but not the other way around. I think there's a lot of different questions that we need to answer on what exact properties do we want before we start to commit to a specific key exchange. Is it okay if it only gets shown after the first payment, or does it have to work just in the contact list? Can we assume that a user knows they're BIP 353, and that you only want it to work if the contact list was derived from BIP 353? Or do you want it to work more generally, like someone scans an offer and then stores the offer in the contact list? Do you want that to work without BIP 353? + +Speaker 2: I was sort of assuming — I think this is documented on the BOLT — that the issuer field — if the first part looks like a URL, like everything up to the first whitespace, then that is a handwave, something important, right? Whether it's BIP 353 or whatever else, right? Which is kind of a hacky way of ad hoc dividing the issuer field. But that was my assumption that the issuer field would literally be something and then perhaps, some comment. So, the obvious thought was originally it would be blockstream.com space. Blockstream incorporated or whatever. Obviously, blockstream.com is the URL or even HTTPS. Whatever. I think that scheme is reasonably robust and fairly simple rather than splitting into two fields. Do we want to extend that to BIP 353? Do we need — I don't know. I agree with [redacted] that I don't quite know what exactly this UX is going to look like. So, it's hard to come up with a protocol that works. But I mean, this is what the issuer field was kind of for originally. To basically say who's doing that. + +Speaker 4: I think [redacted] wants it the other way around though, right? [redacted] wants the sender to tell the recipient who they are. Is there an issuer field on the invoice request? + +Speaker 2: No. There isn't, but there is a payer note. + +Speaker 4: Right. + +Speaker 2: And there's the payer ID, which is nominally a transient key, but doesn't have to be, right? + +Speaker 4: Yeah. [redacted]’s kind of proposing we're using the payer note or payer ID, but only if you are paying someone who's in your contact list. Then, it is an open question to me whether that's exactly the thing we want when — do users expect privacy there or are they okay with it? Like, are users going to be suddenly surprised that their wallet is docile? The fact that they're the same guy who bought this thing once a week. Just because it was in their contact list. + +Speaker 1: Yeah, I think we want, at least, the option for someone else to make this private, because maybe I only really want to give this key to my friends, whom I see in real life, and whenever I hand out an offer for people to pay me. I don't want them to know my contact key. + +Speaker 2: But you've got that UX problem on both sides, right? When you're paying someone, you're like: ‘Do I want to reveal who I am to this person?’ You're suggesting you do that through your friends' contact list. If you're paying someone in that contact list, you automatically reveal by default. + +Speaker 1: Yeah. Or you make it a choice. You could, on every payment, let the user tick a box or make it tick by default if it's in your contact list and they can untick it. There are a few exceptions here. I think we can easily allow all of them, but it's rather where we want to put that contact key in the first place to be able to share it with others where I'm not sure yet what we want to do. + +Speaker 2: I mean, so payer note is unstructured by definition, but I wonder if we want to, at least — so I don't know. It depends. Is 353 going to take over the world? In which case, it's easy. We end up going: ‘Well, if your payer note is structured the same way.’ Basically something that looks like a 353. Something that looks like a URL, or an app, or something followed by space and some junk. Then, that first thing is basically saying who you are. + +Speaker 1: But why wouldn't you use the payer ID instead? Because it's just a public key, so that's exactly what the payer ID is for. + +Speaker 2: Because it doesn't give you the information that you want as to who they're claiming to be, right? So, it gives you the actual key to pay them, but it doesn't give you anything to display to say: ‘This is Bob at whatever,’ right? + +Speaker 0: Also, the payer ID is only in the invoice request, right? Not in the onion you send. So, you're basically tracking that the same person fetched the invoice, but not necessarily that paid it. I guess we're saying the same thing. + +Speaker 1: What you include you as the creator of the invoice, you can include that in the encrypted recipient data for yourself in the invoice that you are going to receive it again. + +Speaker 0: Ah, I see. + +Speaker 1: You were able to identify that this was linked to the payer ID, but the sender doesn't have to do anything specific here. + +Speaker 2: Yeah. I mean, you can always delegate who actually pays it, but in theory, you have authorized it, right? Sorry. I honestly saw these briefly last night when I was looking through to edit the thing and was like: ‘Okay, I'm gonna have to read up on those and figure out what I think.’ We use transient pair IDs at the moment, so I haven't really thought really hard about what this would look like. + +Speaker 4: We currently let the user pick whether they want a transient pair key or not. I think we were actually about to remove that option and force the user to use transient pair keys. + +Speaker 1: Yeah. What we're currently doing is transient pair keys by default, unless you're paying someone in your trusted contact list. But we're still evaluating that as well. I think we want to make sure that wallets are able to choose for themselves what they do and that all options are on the table. + +Speaker 2: So, there's definitely an intersection here with Nostr and stuff like that, where people are starting to use pub keys and actually build out a web of trust or a key distribution mechanism, which I definitely don't wanna get in the way of. Like, it would be nice if someone were to merge those really nicely, in which case, yeah, this would fit pretty well. As long as we don't have to go through a PGP signing party, I'm good. + +Speaker 1: Alright. Let's keep thinking about it and discuss it directly on the PR and move on to something else. + +Speaker 0: Cool. Okay. We’re gonna do some other stuff. No updates on Taproot stuff on our side. We fixed that bug I mentioned a bit back. I think last, Eclair's working on some interop. They're figuring out the splicing component of it. Any updates related to that? + +Speaker 1: [redacted] is on vacation right now. They have been making some progress there, but they have quite a bit to do before they’re ready to share something. So, they have some work that needs to be done on that side. That's what we're working on. Cool. + +Speaker 0: Cool. As mentioned in Taproot Gossip, we're looking to get back to that pretty soon. We want to get these by blinded path finding receiving stuff in first, and then we'll revive these PRs. Feed them our draft PRs. I think last, we got some diffs from people, and then people said they'd take another look at it as well. Okay. Liquidity ads. + +Speaker 1: For channel jamming, there has been some discussion on channel jamming. I think [redacted] and [redacted] will need to discuss something. + +Speaker 6: Yeah, I think we're kind of just down to bikeshedding on values for the bLIP. Like, [redacted] and I only need to use a binary value, and I think [redacted] wants to use a value between zero and seven. So, just the mapping of those two things between them is difficult. This is an experiment, so we do want to be flexible. But I think for the purposes of the bLIP, if we just say: ‘Zero is unendorsed, seven is endorsed, and it's up to your interpretation what the things in between are,’ we can move forward. + +Speaker 4: I mean, is there a way we can use this test and do 0 to 7, but then also gain information for whether 0 to 1 will work? Because in an ideal case, we run the test, we learn what the right number is. Hopefully, that number is just 0 or 1 because that's much better for privacy. But if it's not, maybe we will discuss that. Is there a way we can use this to learn that? + +Speaker 6: I don't think we can learn about both things at the same time. Because right now, what it would look like is whoever runs what [redacted] and I are working on interpreting 0, 1 and then the async node uses 0 to 7. My concern… + +Speaker 4: Right. So maybe we do one, then the other? + +Speaker 0: But isn't the question like what does 7 mean? And 0, 1 is like a clear cut... + +Speaker 4: Exactly. That's kind of where we are. A system that uses zero to seven is never really going to set a seven. So then, where do we interpret that threshold meaning 1? That's really difficult. This is why I kind of think a 0 or 1 is preferable because you don't run into these interpretation issues. + +Speaker 0: Yeah, I guess the question is like if you get a 4 what do you do with that? Does that change it for you? I would think for the initial computation probably not, right? Like, a 4 is a 1. + +Speaker 6: Yeah. + +Speaker 2: I think that [redacted], if you want to take that one, but I think the algorithm they were working on was basically using a certain state probability of success and mapping that to this value 0 and 7? + +Speaker 3: Yes, exactly. So actually, I could work with any number between 0 and 1. I treat it as a float, basically, and 0 and 7 is just like, I discretize it. But I treat it as a continuous value. + +Speaker 7: So I think for us to understand what comes from you, it will help us if you'll give us a cutoff. ‘Cause 50% doesn't seem — I don't know. Something like 80 or 90 or something like that. What should we round to zero and what should we round to one? I think it will also inform you — maybe some logarithmic scale or something like a softmax kind of thing, but where should we cut off? + +Speaker 3: So currently, the score we output is an estimation of the priority that the HTLC will succeed. + +Speaker 7: I understand. + +Speaker 3: Then you can — I don't know what should be a good threshold. I guess that depends on you. + +Speaker 7: Did you run some simulations? What kind of numbers do you see? + +Speaker 3: No, we didn't. + +Speaker 2: How do you estimate the probability of success? I'm interested in that. + +Speaker 4: Basically, for each source, we just look in the past how much fees they paid divided by how much fees they should have paid if all of the HTLCs had succeeded. + +Speaker 2: Right. + +Speaker 7: So, is 75 a number that you'll feel okay with for the experiment? + +Speaker 3: Yeah, I guess. Okay. + +Speaker 6: I mean, you have historical records with your peers, wouldn't you be able to just run this at one point in time for us and get probabilities for everyone? Then, we could get an idea of where that threshold sits. It's not perfect, but this doesn't need to be perfect because it is an experiment. + +Speaker 3: We could also measure what's the range of priorities that we get and instead readjust it so that like half means not a priority of half of this succeeding, but that it's exactly in the median of what we've seen so far? + +Speaker 7: Maybe, but I think like if you run the Times of Peace version, there will be some kind of threshold that most of the time it's above. + +Speaker 3: Yeah. Once we deploy the version, we can measure it and we'll tell you what's the number. + +Speaker 6: Yeah. I mean, that would be perfect. As long as we know where to split that range reasonably. I don't think 50-50 is a great split point for us. But if that's anything greater than 6, and you can just tell us based on your history, I think that that gives us a good shot of supporting both things. + +Speaker 3: I was thinking 50-50 because that's the bucket that we then use. I mean, do you assign 50-50 buckets to the unendorsed and endorsed? + +Speaker 6: Yeah, but that's unrelated to what good reputation means. + +Speaker 7: It's a very, very different meaning. So just for us to be able to move forward, when do you think you'll be able to have numbers? + +Speaker 3: Well, the code is almost ready. We just need to fix a few things. And then, I don't know, [redacted], what do you think? + +Speaker 1: I think it's mostly blocked right now on the question of what to do when we are not running a reputation algorithm and whether we should forward the endorsement value we receive or not. Because that's one of the outstanding questions on the bLIP. + +Speaker 3: Yes. So, the answer was that it shouldn't be used for decisions. Like, it's just an experimental field. + +Speaker 6: So this is a read-only thing. I don't expect anyone to be actually bucketing things on this yet. It's just to figure out whether these reputation algorithms actually work. So, the idea was that you just forward it on with the signal that you would have set, but you don't make any forwarding decisions, right? Because we don't know how these things operate in mainnet. But I do think one question that also comes up with the multi value range is we would only want to have a default where you forward on as endorsed if it's above that threshold and otherwise, set to 0. Because I'm a bit worried about getting the step-down effect if we just copy the incoming value. So I do think a default behavior needs to be that we shut that down to 0 very quickly if it doesn't have a value above this threshold. + +Speaker 3: Why? + +Speaker 6: Because I think that if you're running a 0 or 1, you're really not leaking any information about your location in the path. But if you are running a range of values, you risk getting something like 7, 6, 5, 4. And I think that that's fine if you're the one running that code, that's like your choice to do that. But if you're a random node in the network and someone forwards you a 4, you don't want to forward on a 4 because you're revealing more information about where you are in that path than you would like, so if you get a 4, you just round it down to 0 by default. + +Speaker 3: Okay. + +Speaker 6: That make sense? + +Speaker 3: Yes. + +Speaker 6: Okay. So we'll wait on you to get numbers for — we also need to brush up our implementation. But just to sort of summarize that: It's only forward on as endorsed if it's fully endorsed; otherwise, drop it to 0. I think in the bLIP, what we have now is just leaving it up to interpretation is fine. So, 7 is endorsed, 0 is unendorsed, and your algorithm can choose the interpretation in the middle. Is that fine? + +Speaker 3: Yes. + +Speaker 6: Okay, cool. Then, we'll grab that number from you, and that's what we'll actually choose as our threshold to relay so that we can get some meaningful numbers. + +Speaker 3: Okay. + +Speaker 6: Cool. Thanks for taking a look at it. I appreciate it. + +Speaker 0: Okay. Ten minutes left. Anything popped on the agenda or people have burning questions of? + +Speaker 1: Yeah, there are two things I wanted to mention. First, [redacted], I pinged you on a PR, where I used the official spec version for splicing so that you can start doing cross-compat tests with CLN, and we got... + +Speaker 8: Awesome. Perfect. + +Speaker 1: Regarding async payments and Trampoline, I've also created a commit that details — we had some discussions with [redacted], [redacted], and [redacted] about how to combine the Trampoline and blinded path. I have a data commit that does a rough spec of that. [redacted] and [redacted], you probably want to take a look at it for the ECDH thing I've been doing to include the payer ID and to be able to make sure that the payment really comes from the node that received the invoice and generated the invoice request basically. + +Speaker 9: I think it looks good to me. [redacted], did you have a chance to look at it yet? + +Speaker 4: No, I haven't looked at it yet. + +Speaker 1: Okay. So basically, I'm just using the almost the normal Sphinx, but when we derive the row and mu key to encrypt and do the MAC — instead of deriving this key based only on the shared secret that is using the normal Sphinx ephemeral pubkey that comes from the header — we also add another shared secret which is ECDH between the invoke request player key and the node. + +Speaker 4: Yeah, I think that makes sense. I think I was happy with that, and I think that's basically what I was thinking. + +Speaker 1: Okay. It's just a bit annoying to write in the spec because I realize now that [redacted] has started reworking the BOLT 4 spec to make it much better and much more readable in terms of what we actually do in terms of cryptographic operation, I re-read the Trampoline spec, and it's really not explicit enough. So, I want to rewrite it to be clearer, like what has been done in BOLT 4. I'll do it at some point, but I just wanted to get a rough consensus that this was an okay way to do it before. + +Speaker 2: Are we okay to merge the BOLT 4 rewrite in that case once we've had a bit more time? We don't need another meeting. We'll just make sure we've got it. I think we're pretty close. + +Speaker 0: Yeah, I have it marked as high priority. I should be able to get a pass through today, if not tomorrow. Basically, just to avoid rebasing because it's going to touch a lot of stuff. + +Speaker 2: Yeah. It's a world of pain for everyone. So yeah, [redacted] has a comment about it being a little bit unclear at one point. so I will try to… + +Speaker 1: Also, one about updating the route-blinding test JSON file that doesn't refer to the right name, but apart from that, it's fine to me. Once that is fixed, it's an ACK from me. + +Speaker 2: Yeah, cool. Okay. I'll get on that today. + +Speaker 5: [redacted] sent me a note earlier saying they were updating the Trampoline stuff according to the [redacted]’s changes from earlier today. So, I just want to pass that on. + +Speaker 1: Okay, cool. Perfect. Then we can continue discussing it directly on GitHub and offline. Liquidity ads. I updated the spec based on the feedback we had from the last meeting. I quite like it. It's ready to review whenever people have time. + +Speaker 10: Hey, everyone. If no one else has something to say, I would like to introduce myself. I just got a grant from OpenSats. I'm implementing the Lightning specification in .NET C#. It's called N’Lightning. I'm pretty advanced on this. I'm doing BOLT 2 and 3, but I stopped it to do BOLT 11, so people can already use it. Like, everybody uses C# in their back-end, they will be using the library. It should be a library and a full implementation. So I expect to have a node by the end of this. I already have BOLT 1, 8, 10, 9, and 7 implemented, and I can connect to other nodes and start doing the feature bits and other things, starting the communication. Now, I'm doing the transactions and just relaying the HTLCs. + +Speaker 0: Cool. + +Speaker 2: Nice. + +Speaker 0: Definitely open issues if you find that stuff sucks. I think we know some stuff does. We're trying to fix it. + +Speaker 2: If it's not clear, then yeah. + +Speaker 10: I'm having some issues. It's not clear in some places. Then it's just a matter of — I was trying to follow from 1 to 11, and it doesn't work that way. Because for 1 to work, you need to go to 8, and then you implement 8, and then you go back to 1, and you can send messages. Then, I would like to implement 2, but then I need feature bits, so I went to 9. Then I went to 10, and so on. So it's not straightforward to implement, but I've been working in the field for five years, so I got a feel of how to do this. But other than that, everything is very clear what's happening. I guess when I got to implementing not only the library but communicating to other nodes, I might have some issues. + +Speaker 0: Have you done BOLT 4 or the state machine? I'm assuming no. + +Speaker 10: No. BOLT 4 not yet. + +Speaker 0: Okay. Yeah because we're working on BOLT 4. I think BOLT 2 could definitely have a revamp, particularly [redacted]’s state machine stuff too. But you always get to have some new eyes looking at stuff because we have code at this point. + +Speaker 10: Yeah. It's been some years since someone got from the ground up running this. It's been fun. + +Speaker 2: Yeah, welcome. + From dda4d2c4129eb7ef7d7c0b9a3f6805ac413579e2 Mon Sep 17 00:00:00 2001 From: Andreas Date: Fri, 6 Sep 2024 01:04:01 +0300 Subject: [PATCH 2/5] Add new AI-generated transcripts (#520) * ai(transcript): The Great Consensus Cleanup Revival (bitcoin-explained) * ai(transcript): Discussing 0.21.0 Bitcoin Core Vulnerability Disclosures (brink/the-bitcoin-development-podcast) * ai(transcript): The Politics of Bitcoin Development (bitcoin-magazine) --- .../the-great-consensus-cleanup-revival.md | 1287 +++++++++++++++++ .../the-politics-of-bitcoin-development.md | 142 ++ ...-bitcoin-core-vulnerability-disclosures.md | 544 +++++++ 3 files changed, 1973 insertions(+) create mode 100644 bitcoin-explained/the-great-consensus-cleanup-revival.md create mode 100644 bitcoin-magazine/the-politics-of-bitcoin-development.md create mode 100644 brink/the-bitcoin-development-podcast/discussing-0-21-0-bitcoin-core-vulnerability-disclosures.md diff --git a/bitcoin-explained/the-great-consensus-cleanup-revival.md b/bitcoin-explained/the-great-consensus-cleanup-revival.md new file mode 100644 index 000000000..4b7790ee9 --- /dev/null +++ b/bitcoin-explained/the-great-consensus-cleanup-revival.md @@ -0,0 +1,1287 @@ +--- +title: "The Great Consensus Cleanup Revival (And an Update on the Tornado Cash and Samourai Wallet Arrests)" +transcript_by: kouloumos via tstbtc v1.0.0 --needs-review +media: https://bitcoinexplainedpodcast.com/@nado/episodes/episode-93-the-great-consensus-cleanup-revival-and-an-update-on-the-tornado-cash-and-samourai-wallet-arrests-5bbxi +tags: ['wallet', 'consensus-cleanup'] +speakers: ["Sjors Provoost", "Aaron van Wirdum"] +categories: [] +summary: "In this episode of Bitcoin, Explained, Aaron and Sjors discuss the Great Consensus Cleanup Revival soft fork(s). This proposal would fix some known bugs in the Bitcoin protocol, specifically the timewarp vulnerability, large block validation times, 64 byte transactions and BIP 30 verification." +episode: 93 +date: 2024-05-29 +additional_resources: + - title: CoinKite + url: https://store.coinkite.com/promo/BITCOINEXPLAINED + - title: https://bitcoinexplainedpodcast.com/ + url: https://bitcoinexplainedpodcast.com/ +--- +Speaker 0: 00:00:19 + +Life from Utrecht, this is Bitcoin Explained. +Sjoerds, it's been a month. +That means you had a whole month to think about this pun that you told me you're going to tell our dear listeners for this episode. +Let's hear it. +Let's hear it. + +Speaker 1: 00:00:35 + +That's right. +So it's cold outside. +The government is cold. + +Speaker 0: 00:00:39 + +You know what else is cold? +Sure. +Our sponsor. +That's right. +The cold cart. +The cold cart. +If you have coins, you want to store them. +Cold car is the place for that It's the audio. +Okay, are we too loud? +It's too much echo too much echo Okay, cold card cold card cold card cold card cold card cold card. +I think that was like our 20 seconds that we're obligated to talk about the coldcard. +What do you think? + +Speaker 1: 00:01:09 + +I think it's great, but it's a hardware wallet for people who don't know. + +Speaker 0: 00:01:12 + +Yes, why did you say the government is cold? + +Speaker 1: 00:01:15 + +Well, that's a segue to our next section. + +Speaker 0: 00:01:19 + +So this episode we're going to talk about the Great Consensus Cleanup Revival, which is a proposed soft fork, which sort of includes several soft forks into one, you could kind of argue, right? +Basically, that's what it comes down to. +But before that, a lot has happened in the Bitcoin and Ethereum space in a way that's relevant to Bitcoin as well. +So you want to touch on that a little bit. +First, you've been following it pretty closely. +Let's start with... +Where do we start? + +Speaker 1: 00:01:52 + +Let's start with what happened with tornado cash in the netherlands yeah in case anybody was living under a rock the tornado cash we talked about that in episode 69 but he got convicted. +So that's bad. + +Speaker 0: 00:02:08 + +Yeah, Alexey Pertsev, one of the Tornado Cash developers got convicted for 64 months in prison. +Yep. +Which does seem to have a lot of relevance for Bitcoin because really he was just writing codes. +You know, he was writing privacy code, but he was never, maybe you should give the context. +Why do you think it's relevant for Bitcoin? + +Speaker 1: 00:02:30 + +Well, the main point of relevance for us, I think, is the fact that he was building a non-custodial system. +So a system that does not hold the coins yourself. +I mean, there is a website and those kind of tools. +So That's a very dangerous precedent, I think, because it's not very clear where that line is. + +Speaker 0: 00:02:49 + +Yeah, we already knew that running a custodial mixer, which a lot of other mixers were, where you just send coins to someone and that someone sends different coins back, that was always illegal. +And everyone knew that was illegal. +If you're doing that, that's basically money laundering and that is illegal. + +Speaker 1: 00:03:05 + +Well I think you can narrow it down slightly it's not illegal to mix the coins but it is when you don't do KYC I guess that's maybe a different interpretation. +Right. +But for the you know if for all practical purposes you can't build a mixer with KYC in an ethical way anyway. +So effectively, mixes are illegal, but technically, I think the non-KYC part of the mixer is what makes it illegal. + +Speaker 0: 00:03:30 + +Fair enough. +In either case, so far it was generally assumed that yeah, if you're taking coins and they're sending other coins, then you're at risk. +But if you're just developing software, which allows other people to send their coins to other people, then you're not the one money laundering. +However, the Dutch court just struck that down, and now it looks like, nope, just developing code can make you responsible for how other people use that code, right? + +Speaker 1: 00:03:58 + +Well, probably, but We don't really know because this verdict was extremely unclear about that. +So we don't know if it's simply the act of writing code or it is the, you know, making that code available on your own website or, you know, making that code available on some automatic website-like system or whether it's about maintaining this code after you've written it once, or if it's about promoting the code or making money from the code, it's very unclear. +And in fact, the prosecutor seemed to emphasize making money from the code, but the judge much less so. + +Speaker 0: 00:04:34 + +Yeah, the prosecutor really hones down on it essentially being a business. +And that's why you say the making money part was important, but the judge didn't even really seem to focus on that. +The judge just said, look, if you write this code, knowing that it can be used for this purpose and you don't do anything to stop that then you're responsible if it's really used for that purpose right yeah pretty much and what was the purpose especially of course being money laundering yeah what was especially interesting though not clear entirely how that's going to apply to Bitcoin, was the argument that he made the whole thing unstoppable. + +Speaker 1: 00:05:10 + +So in Ethereum, part of the system at least is unstoppable. +It's a smart contract, unless you stop Ethereum itself, of course. +And the fact that he did that where the prosecutor just tried to argue well it's not all decentralized some of it is is fake decentralization others is real the judge completely ignored that and basically said well the fact that you even tried to make it decentralized that is actually making it worse so that that argument of course can apply extremely broadly because you could say well if you just publish source and you know that other people are using that source and you just keep updating that source code, well, that's also kind of unstoppable in a way. +So that might also be a problem. +And of course, we all know somebody, or we don't know them, somebody who created an unstoppable system a long time ago and kept working on it. + +Speaker 0: 00:05:59 + +You're referring to Satoshi Nakamoto. + +Speaker 1: 00:06:01 + +Exactly. +So we're waiting for his arrest warrant, I guess. + +Speaker 0: 00:06:04 + +Yeah, well, the short way of looking at it, I would say is we all thought so far that there was a fairly clear line of what would make you responsible, which is custody in a way. +And now it's kind of a all bets are off type of situation. + +Speaker 1: 00:06:24 + +Yeah, and this creates a bit of a problem because we assumed that this line existed, we did not do much to defend people who built custodial mixtures. +And in retrospect, that was probably a mistake, because as soon as you lose that line of defense, now, you know, I guess the only way to win now is to go all the way back and say, no, all mixtures should be legal, including custodial ones. +But now you have all this precedent that wasn't stopped. +So that's a problem. + +Speaker 0: 00:06:51 + +Right. +OK, let's move on to the actual Bitcoin case, which is the Samurai devs. + +Speaker 1: 00:07:00 + +Just to add one little detail, as far as I know he is going to Appeal, so we'll see what happens. +And Appeals can quite dramatically change things. + +Speaker 0: 00:07:09 + +Yeah, is there any timeline for that? +I don't know. +No. Okay, so let's move to the more Bitcoin relevant case or I mean... +The more direct Bitcoin case. +Yeah, exactly. +So the Samurai wallet developers Keone Rodriguez and Bill Hill William Hill both of them you know right yep yeah I used to work with them when I was at blockchain.com, so back in time, blockchain.info. +Right, so they were arrested as well, one of them in Portugal, one of them in the United States, but both on behalf of the Department of Justice, DOJ. +So what do you want to say about that, if anything? + +Speaker 1: 00:07:53 + +Well, I'm not surprised that this happened, because the fact that they were going after Tornado Cash made it clear that they would go after non-custodial systems, after non-custodial mixes. +So it seemed like a matter of time before they would go after it and then obviously they always go after the biggest or at least a big one. +So the only question was, were they going to go after Wasabi or were they going to go after Samurai? +Samurai has some interesting marketing that maybe made them more interesting to prosecute, but I don't know if the difference, you know, and of course we know that Wasabi was doing some proactive compliance-ish things, But I don't know why they picked one and the other. +Ultimately, we'll find out. +What else was I going to say about it? + +Speaker 0: 00:08:40 + +Well, it was my suggestion to just sort of explain how the Samurai Mixing actually works. +But at this point, should we just move on to the main topic of the episode? + +Speaker 1: 00:08:52 + +No, I think it may make sense to briefly explain a little bit. +So there's three aspects to Samurai Wallet, I think, that are relevant. +One is It's not just a mixer, definitely not. +It's a wallet, right? +It's a non-custodial wallet. +And so far it seems that that wallet was taken down mostly as a side effect of taking the mixer down, not as a direct target. +But it is down. +But fortunately it was a non-custodial wallet and people wrote down their 12 words, hopefully. +And so they should be fine because they can just import it into another wallet. +But there was also a mixer component. +And I think the two most important parts of that are something called the Whirlpool, which is a 5 input, 5 output mixer that you can use multiple times. + +Speaker 0: 00:09:37 + +Yeah it's just a coin join which uses equal amounts. + +Speaker 1: 00:09:41 + +Yeah and then there is something called Ricochet which basically just as far as I understand it just forwards your coins a couple of times. +So you're making a couple of unnecessary transactions and then you send the email that you want to send and that might help when you're dealing with an exchange that only looks at say five hops ago or two hops ago and then maybe you can get around that. +I don't know how effective any of these things are. + +Speaker 0: 00:10:06 + +Yeah, you're basically making transactions to yourself a couple times. + +Speaker 1: 00:10:09 + +Yeah, now it should be noted that from my reading of the indictment, they don't even talk about whether or not these tools, these mixing tools were effective or not. +The fact that it's doing any mixing, that is the problem. +So that's something to keep in mind. + +Speaker 0: 00:10:27 + +Yeah, I would say the Ricochet one, The fact that that one is even mentioned is blatantly absurd. +Like every wallet, with every wallet you can send coins to yourself. +There's just a button that just sort of automates that you do that a couple of times. + +Speaker 1: 00:10:42 + +Exactly. + +Speaker 0: 00:10:43 + +That this is even, Like the other, the Whirlpool, I can sort of at least understand why it's seen as some, I mean, I don't agree with the rest of the course. + +Speaker 1: 00:10:52 + +Well, the Whirlpool requires coordinating with other users, right? +Whereas the Ricochet thing does not. +It's just your wallet sending a transaction to itself, essentially five times in a row. + +Speaker 0: 00:11:01 + +Yeah, which again literally every wallet can do. + +Speaker 1: 00:11:05 + +But I would be very surprised if in the court case they're going to debate the specific details of what is and what is not mixing. +My guess is they just go with the marketing. +They say, well, you guys called it a mixer and that's all we care about. + +Speaker 0: 00:11:23 + +Right. +Anyways, yeah, seems like a new era in Bitcoin and Bitcoin development to me. + +Speaker 1: 00:11:32 + +Yeah, and I think we could briefly do a recap of the differences, how these cases relate to each other. +So we brought up most of the things. +So the interesting thing about Samurai is that it's only happening in the US, whereas The Tornado Cash trial is happening in the US and the Netherlands in parallel, which is interesting. + +Speaker 0: 00:11:50 + +Yeah, you didn't mention that yet, but yeah, one of the other Tornado Cash co-founders was arrested in the US and will be on trial there. + +Speaker 1: 00:11:59 + +Yeah, and this is interesting because the Dutch court system is not very transparent. +You can go to the court hearings but you don't get to see any of the dossier. +Whereas in the US it's much more transparent so we'll probably learn much more about the Dutch case through the US case. +Both of them are non-custodial. +Both of them use a, well no, so the samurai uses a central coordinator, so that might be a service, whereas in Tornado Cash it's a smart contract, so that's not really a service, although the prosecutor argued that it's a service anyway. + +Speaker 0: 00:12:36 + +You mean the main smart contract? + +Speaker 1: 00:12:39 + +Yeah, the main smart contract and everything around it. +You could argue like it's an autonomous system, so it's not really a service, but that's what they're arguing, I think, in both the Netherlands and the US, against or for, depending on which side you're at. +I'd say Samurai used fees, fairly pretty direct fee system, whereas The Tornado Cash system did not charge fees directly, at least the fees don't go directly to the developers or operators. +They have a more convoluted tokenomics system where at least the prosecutor argued that these tokenomics are, you know, how it is, how the business works. + +Speaker 0: 00:13:21 + +I think the short summary I would give is if the Tornado Cash developer is guilty in the Netherlands, which he is, then the Samurai developers have to be as well. +So it's sort of even more straightforward. + +Speaker 1: 00:13:34 + +Exactly. +It's a simpler case. + +Speaker 0: 00:13:37 + +Right. +So, yeah, bad news. +Let's move on to our actual topic for the podcast. +What do you think? + +Speaker 1: 00:13:45 + +Yeah, also some bad news in a way. + +Speaker 0: 00:13:48 + +Yeah, but bad news that we're going to fix, right Sjoerd? + +Speaker 1: 00:13:50 + +Yeah, exactly. +That we hopefully fix in time. + +Speaker 0: 00:13:54 + +So we're going to talk main topic of the podcast. +Finally, we're here. +We're here, ladies and gentlemen. +We're going to talk about the Great Consensus Cleanup, or maybe more specifically the Great Consensus Cleanup Revival. +That's right. +Because the Great Consensus Cleanup was proposed by Matt Corello a couple of years ago, and it was recently revived by Antoine Ponssois. +Am I saying that right? +Probably. +It was him, right? +I got the person right at least. +Whether I got the name pronunciation right or not sure about that one. +And The Great Consensus Cleanup revival, maybe what's the difference between the original and the revival? +Is there a difference? + +Speaker 1: 00:14:39 + +Yeah, there is. +So the revival adds something and I guess I'll let you know when we get to that due bit. + +Speaker 0: 00:14:46 + +Okay, And as far as I understand, the great consensus cleanup would be, well, it would basically be one soft fork that bundles several soft forks and these soft forks sort of fix existing bugs in the protocol. + +Speaker 1: 00:15:01 + +Yeah, that could be individual softworks and you know in the worst case maybe out of the four components people really like three of them and are kind of arguing about the fourth one then you can simply do three and not do the other one. + +Speaker 0: 00:15:14 + +Okay and if I understand correctly basically everyone and when I say everyone I mean everyone that's you know has enough expertise to have an opinion in the first place, agrees that at least the bugs are problems. +There's maybe at most like some conversation about the best way to solve these problems, whether these are the best ways. +But the problems are real. +There's no one that says, no, these are actually futures, right? +These are just real problems, bugs that exist in the Bitcoin protocol. + +Speaker 1: 00:15:45 + +I think when it comes to the Time Warp attack, there might have been someone who could think of some interesting schemes that you can do using a Time Warp attack. + +Speaker 0: 00:15:53 + +That's right. +You're thinking of Mark Friedenbach, who had some sort of proposal years ago to sort of increase the block size. +Yes. +Yeah, You're right. +But let's... + +Speaker 1: 00:16:03 + +Every bug is a feature. + +Speaker 0: 00:16:04 + +Yeah, let's table that for a second. +Although, I mean, it is interesting that you bring that up. +But... + +Speaker 1: 00:16:09 + +Well, I mean, that won't work if somebody exploits the time warp maliciously before the legitimate use case happens, I think. + +Speaker 0: 00:16:20 + +Well, is the legitimate use case still possible after this bug would be fixed? + +Speaker 1: 00:16:25 + +Actually, I'm not sure. + +Speaker 0: 00:16:27 + +Probably not, right? + +Speaker 1: 00:16:27 + +We'll shelve that. +So there may be a, you know, As always, there may be some ways that you could use this to your advantage. +I think it's better to fix them. + +Speaker 0: 00:16:35 + +Yeah, okay. +There are basically four bugs, right? +There are four bugs, there are four things that this would solve. + +Speaker 1: 00:16:43 + +That's right, plus an open invitation to anyone who knows another bug. + +Speaker 0: 00:16:48 + +Okay, so four. +Let's start with the first one. +So the first one, you already mentioned it, the time warp attack, the time warp problem, what do we call this? + +Speaker 1: 00:16:58 + +Yeah, the time warp attack. + +Speaker 0: 00:17:00 + +Yeah, and so it's about the time warp attack is possible now, and we're talking about fixing that, that it's possible. +Like that shouldn't be possible, essentially, right? + +Speaker 1: 00:17:10 + +That's right. +And we did an earlier episode about the time warp attack. +It's episode number five. +So scroll all the way back. + +Speaker 0: 00:17:17 + +That's a long time back. + +Speaker 1: 00:17:18 + +Where we explain how it works, I think. +I didn't listen back to it. +But basically, I mean, the deal there is that you can mess with the timestamps in every block so miners can, you know, Bitcoin is not a clock, contrary to popular belief, but blocks do have a timestamp in it. +And this timestamp cannot... +I mean, the miner can pick this timestamp however they want, but there are a few restrictions on it based on earlier possible attacks. +One of the restrictions is that it cannot be more than two hours in the future, as determined when you receive the block. +The other rule is that every, I think it's a rolling average or the median, I should say, of the last 11 blocks has to go up by one second every block. +And so basically, you know, the block time has to go up a little bit and it can't be too far in the future. +Those are the only two restrictions, but it turns out you can still mess with the system with those two rules. + +Speaker 0: 00:18:17 + +How so? + +Speaker 1: 00:18:19 + +Well, you can basically fool the system... +I think we need to explain another related bug here first, which is that the difficulty adjustment, how the difficulty adjustment works. +So the goal of the system is to keep one block every 10 minutes and this is achieved by looking at the last block of the difficulty adjustment period and comparing it to the first block in that period and then dividing it by 2016. +And there are multiple problems with that, but the biggest one is that you are not comparing the first block of each period to the first block of each last period. +You're comparing the first block of a period to the last block of a period. +And that allows you to kind of mess around the edges. + +Speaker 0: 00:19:09 + +Oh yeah, okay. +So how do you mess around the edges? + +Speaker 1: 00:19:12 + +Well, one thing you can do here is you can increase the timestamp of... +Basically, you increase the timestamp of every block as little as possible. +So the entire two-week period will look like it's only a few minutes basically. + +Speaker 0: 00:19:28 + +Yeah and well to be clear this would require a majority of miners to collaborate. + +Speaker 1: 00:19:34 + +Yeah, the time warp attack is a 51% attack, basically, or requires a 51% attack. + +Speaker 0: 00:19:39 + +So miners, a majority of miners is faking the timestamps, and all nodes on the network will accept this, because it's not breaking the rules. +The nodes are just looking is this block mined in the future and is it mined at least one second previously later than like the 11 blocks before it's offline. +Exactly. + +Speaker 1: 00:19:59 + +So then you can mine, you can fake the timestamps to make every blocks look like it was all mined within the same minute basically yeah and then you might think it's mined within the same minute why would you want to do that well there's another part of this attack which is where you take the last block of the difficulty adjustment period and there you don't lie You just put it two hours in the future or right now, it doesn't really matter. +If you do that in just one difficulty adjustment period, it really has almost no effect, right? +Because the first block in that period had a real time because you weren't lying. +The last block in the period has a real time because you weren't lying. +You were only lying for the other blocks. +So the difficulty will just stay the same because it took you two weeks to make these blocks. +But the attack has already begun even though it doesn't have any visible effect yet. +For the next two weeks, you do the same thing. +So the first block, you set a fake time as low as possible. +So much older than the last block of the previous period. +You just keep that original clock going. + +Speaker 0: 00:20:59 + +Right. +So now you're back in the original minute, so to say. + +Speaker 1: 00:21:04 + +Yes, and now the last block, you're speaking the truth again, the last block of the period. +And now if the blockchain is looking at what to do with the difficulty, it's seeing the last block of the period, which is real, and it's seeing the first block of that new period, which is now four weeks ago. + +Speaker 0: 00:21:23 + +Right. + +Speaker 1: 00:21:23 + +Because we've only increased that timer very slowly. +Yeah. +And so that means the difficulty can be cut in half now. +Yeah. +And then you repeat this little trick. + +Speaker 0: 00:21:32 + +Yeah, the rest of the network, all nodes are looking at these two blocks and they're thinking, wow, it took a whole month to mine 2016 blocks. +It's way too long. +We got to decrease the difficulty by half. +Exactly. +So now the difficulty is divided by half. +Even though that was not really necessary, it's just the timestamps were all being faked. + +Speaker 1: 00:21:50 + +Exactly. +So now you can make two weeks worth of blocks in just one week. + +Speaker 0: 00:21:57 + +Assuming that all the hash power is still the same, now you can mine two weeks of blocks in one week yep yeah and because again and then at the end of that one week you're still faking the timestamps so we're still sort of back mining in the first minute or you know yeah so at the end of that of that week which you know for the blockchain is two weeks you're like okay this was five weeks This took five weeks to produce this block, so I'm gonna decrease the difficulty even more. + +Speaker 1: 00:22:23 + +And then, so it gets cut in half again, so now you can mine in about two and a half days, the equivalent of two weeks, and the blockchain is like, whoa, that took five weeks and two days. +I got to reduce the difficulty again. +And so the difficulty goes to one very, very quickly in a matter of about 40 days according to Antoine's calculation. + +Speaker 0: 00:22:44 + +Right. +So yeah, miners, like you said, it's basically 51% stack where miners can drive the difficulty down to one. +And then they can mine all remaining coins that are still to be mined over the next century. + +Speaker 1: 00:22:59 + +They mine the equivalent of until the year 2106. +We've got every last set. +We've got millions of blocks in a very short period of time. +And then they probably stop the attack, because there's no need to do it anymore. + +Speaker 0: 00:23:13 + +Yeah. +And then on top of that, that would mess up probably a bunch of like smart contract things, time lock types of things. + +Speaker 1: 00:23:23 + +No, well, time locks are, well, they might be affected, but because time is moving more slowly, your time locks would indeed not expire, but that's probably not a big deal. +Like during this attack, because the attack takes five weeks plus a little bit to suck all the coins out. + +Speaker 0: 00:23:39 + +Well, it could definitely, the time locks that are locked on a certain block in the future. + +Speaker 1: 00:23:43 + +Yeah, so if you're looking at hide locks, I guess you'd call them, hide locks are definitely affected because if you have a contract that expires in block one million, well, guess what? +That happens immediately. +But a time lock would be, kind of during the attack, it would be affected because your time lock is never happening because they keep the time behind. +But once they stop the attack, it'll be fine. +So you might be unlucky if your lightning thing is in the wrong place yeah it could be bad but the the worst aspect of this attack other than the five-week disruption is simply that they have now exhausted the full subsidy. +And so we were hoping to not have to deal with a no subsidy world only 20, 30 years from now, but we have to deal with it in, well, 40 days, worst case, if this happens. + +Speaker 0: 00:24:31 + +If this attack is exploited, yeah. + +Speaker 1: 00:24:32 + +And it could happen at any moment. + +Speaker 0: 00:24:34 + +Okay, so... + +Speaker 1: 00:24:35 + +And a majority of miners, you know, might think, well, you know, why not? +We're the majority of miners. + +Speaker 0: 00:24:41 + +Well, I mean, one reason why not is that it would probably undermine trust in the protocol. +But let's ignore that. +Let's see if we can fix the protocol instead of relying on that kind of stress. +So what's the fix here? + +Speaker 1: 00:24:52 + +The fix is actually fairly simple. +The ideal fix would be that we just compare every block to the same block in the last period, +but that's a hard fork. + +Speaker 0: 00:25:04 + +Okay. + +Speaker 1: 00:25:04 + +So instead, at least I think it's a hard fork. +So instead... + +Speaker 0: 00:25:07 + +So by that you mean instead of comparing the first to the last block within the same period, you know, and checking if that's two weeks, you should really just check the first block to the next first block. +Yeah. +But that's not possible, right? + +Speaker 1: 00:25:22 + +As far as I know that's a hard fork, so can't do it. + +Speaker 0: 00:25:25 + +But also how is that even possible? +Because by then the difficulty should have already adjusted, right? +By the time the first block of the next period is marked. + +Speaker 1: 00:25:34 + +Well obviously you'd have to change exactly how the difficulty adjustments happen but you should just do the difficulty adjustments correctly. +But the simplest solution here is that every first block, or block 0 of every period, needs to be in the present, or two hours ago, but no more than that. + +Speaker 0: 00:25:52 + +Every what? + +Speaker 1: 00:25:53 + +Every first block of every period, so block 0, block 216, etc., has to be in the present, the timestamp. +And it can be two hours ago for weird mining-related reasons, and it can, of course, not be more than two hours in the future. +But basically, it has to be in a four-hour window between two hours ago and two hours in the future. + +Speaker 0: 00:26:14 + +Every first block has to be? + +Speaker 1: 00:26:16 + +Yes. +Right. + +Speaker 0: 00:26:18 + +Okay, yeah, that sounds like a pretty simple fix. + +Speaker 1: 00:26:20 + +Yeah, because remember the attack involved comparing the last block to the first block, and really messing with the first block. +That's the part of the messing that you weren't messing with the last block already, But you were messing with the first block and this fix basically makes that impossible and therefore the difficulty adjustment will be correct and solved. + +Speaker 0: 00:26:39 + +Okay, makes sense. + +Speaker 1: 00:26:40 + +Yeah and as far as I know that's still the going, the proposed fix that hasn't changed. + +Speaker 0: 00:26:47 + +Okay, that was a time warp attack fix, what's the next one? + +Speaker 1: 00:26:52 + +Slow scripts. +So as you know it takes a while to validate the whole blockchain and Some blocks take a bit longer than others. +That can be because there's tons of tons of transactions in them, but there's certain, you know, at least we have a limit on the block size. +A block can be more than four megabyte. +So there's some limit to how much you can do in a block, but it turns out you can make some special transactions that are really quite slow to verify. +And that's usually a combination of lots of signature checks, because signature checks take a while, you have to do the ECDSA thing, and hashing. +So we talked about this signature checking speed problem back in episode... +Let me see... +I think episode 32 and episode 76. + +Speaker 0: 00:27:44 + +Yeah. +Yeah, so from what I understand, the problem here essentially is like every transaction includes scripts and for many transactions that's just a straightforward, you know, check that the signature is valid type of thing. +But you can make more complex transactions that include, like you say, hashing or more signature validation. +Yeah. + +Speaker 1: 00:28:08 + +So Stoichi, for example. + +Speaker 0: 00:28:09 + +And if you would intentionally want to design a transaction or maybe even a block full of transactions with complicated stuff, then that could in the worst case lead to blocks that take minutes to actually validate. + +Speaker 1: 00:28:25 + +Yeah, and so, you know, people have been, Antoine, I believe, has been doing some math on seeing what is the absolute worst you can do? +And he came up with something that took more than one hour to validate on a Raspberry Pi 4. + +Speaker 0: 00:28:37 + +Right. + +Speaker 1: 00:28:38 + +And that's not good. +Now you could say, well, it sucks to have a Raspberry, but it'd be nice if it didn't. + +Speaker 0: 00:28:45 + +And even on a fast laptop, it took several minutes. + +Speaker 1: 00:28:49 + +Yeah, and several minutes would be bad, right? +So if you are a miner and you receive that block that takes you several minutes to validate, well, now your competitor can do all sorts of shenanigans because you're kind of stuck validating. + +Speaker 0: 00:29:02 + +Yeah, or not shenanigans, just get a head start on finding a nice block, for example. + +Speaker 1: 00:29:08 + +Right, that's one shenanigan, but I think there might be other things you can do. + +Speaker 0: 00:29:12 + +Yeah, it would be a disruptive thing for the network if blocks take minutes or even longer than that to validate. +Yeah, + +Speaker 1: 00:29:17 + +And so the question is, how do we prevent those blocks from being created? +Now, for now, + +Speaker 0: 00:29:24 + +Just to give a comparison, how long does it take to validate average block right now? + +Speaker 1: 00:29:31 + +I think on a good laptop a fraction of a second. + +Speaker 0: 00:29:33 + +Yeah and on like a Raspberry Pi? +Probably one second. +Yeah okay just to sort of paint the context there. +Okay so the solution? + +Speaker 1: 00:29:45 + +Well the solution is in the original proposal by Bluemat, there was a solution which was just changing a few rules. +I think now there's discussion about a slightly different solution. +So that's actually still ongoing research, what is the actual best solution. +But the gist of it is that there are certain extra rules in SegWit and in Taproot that make the script safer. +This was why the block size could be increased with SegWit because any of these extra SegWit transactions would not be as expensive and as slow. +These worst case couldn't happen. +But it looks like some of these rules should also be applied to legacy scripts, to legacy transactions. +And then the problem is you can't just apply all of SegWit's rules to legacy transactions, so you have to be very careful which ones you'd want to apply. +Main problem there is, you know, somebody might have a transaction that they put in a cold wallet and or like offline wallet, right? +So we don't see it on the blockchain and now they want to broadcast it, but we changed the rules and now they can't spend it anymore. +Now the changes that people have in mind would only impact the most bizarre, unrealistic transactions that you can possibly imagine, but still that could still be controversial. +So the key is to find the absolute minimum extra rules that you need in order to fix the problem and no more. +Because the simplest solution would just be to say, hey, you know what, you can only make TAPO transactions. +That would fix the problem, but it would make a lot of people very angry. + +Speaker 0: 00:31:20 + +Yeah, I thought the idea was also to only apply these new rules from a certain block height. +So if you already had your coins in some... + +Speaker 1: 00:31:32 + +So those are other things you could do to restrict the possible damage that a rule could do. +But the trade-off there is complexity. +So a rule that says only do this after this block, or only when the coins you're spending is from this block. +That's extra complexity that you'd prefer not to have. +Plus, you know, if the attack, this is one of the problems, once you publish the exact fix somebody might come up with what it is fixing and then do the attack before the soft fork is activated. +That's probably inevitable anyway, just like the time warp attack, everybody knows what to do there. +Yeah. +So there's that. + +Speaker 0: 00:32:13 + +Yeah. +Well, you really want to avoid that people lose their coins, right? +That's kind of a non-negotiable, I would say. + +Speaker 1: 00:32:17 + +Yeah, so realistically, even the original proposal by Bluemet, I think it was changed a bit by him because there were several things that he wanted to change for this problem. +And I think they ended up dropping one of these things. +So hopefully there's a way to make sure that you can like there's nothing gets unspendable. +It might just take more fees for example. + +Speaker 0: 00:32:42 + +Right. +Okay So that was slow scripts. +Are we done with slow scripts? + +Speaker 1: 00:32:49 + +Yep, we are. + +Speaker 0: 00:32:50 + +All right, and the next point is about banning 64 byte transactions. +Is that right? + +Speaker 1: 00:32:55 + +Yes, 64 bytes, bad. +Why? +Well, We mentioned this a few times in other episodes, I don't think we've done an actual episode about it, but in our episode 81 we talked about a change to Bitcoin Core 25 that makes transactions that are 65 bytes or greater, I think they make them illegal again or something weird about that. +I forgot what exactly we discussed. +The point is 64 byte transactions are bad and the reason they're bad is because they look the same as 232 byte transactions next to each other in the block. +Because of the way the Merkle trees are made. + +Speaker 0: 00:33:36 + +Sorry, we have to take a step back here, Sjoerd. +What does it mean? +Why is there such a thing as a 64 byte transaction and also such a thing as a 32 byte transaction? +Why aren't all transactions the same number of bytes? + +Speaker 1: 00:33:49 + +Because the size of a transaction depends on the number of inputs, the number of outputs, what kind of script you have in those inputs and outputs and whether it has a witness or not. + +Speaker 0: 00:33:57 + +Okay and then 64 but a 32 transaction would also look like two 16 byte transactions, right? + +Speaker 1: 00:34:09 + +Yeah, but I don't think you can make a 16 byte transaction because simply it wouldn't fit. + +Speaker 0: 00:34:15 + +Okay, and a 128 byte transaction would look like 4, 32 bytes. +Why is 64 singled out is my question. + +Speaker 1: 00:34:23 + +Okay, so the Merkle tree that the Bitcoin transactions are stored in takes the SHA256 hash of every transaction and then puts that next to the shot to 56 hash of the next transaction. +So you take all the transactions and you take their shot to 56 hashes and then in pairs you put those hashes next to each other. +And the size of a hash is 32 bytes. + +Speaker 0: 00:34:49 + +Right, that's always 32 bytes. +Yes. +Yeah. +So two hashes next to each other. +I vaguely remember this problem. +We discussed it. + +Speaker 1: 00:34:58 + +So two hashes next to each other is 64 bytes. +And so then the question is, when you are, so I guess it's not two 32 byte transactions because you can't have 32 byte transactions, too small. +Because the minimum size of a transaction, keep in mind that a transaction has an input, at least, and the input is already 32 bytes plus a little bit more because the input of a transaction refers to the hash of a previous transaction. +We just set the hash to 32 bytes. +So then it has to have a number and a few other things. +So yeah, a transaction cannot be 32 bytes, But it can be 64 bytes. +It would be a pretty nonsensical transaction, but it can be 32 bytes. +And so... + +Speaker 0: 00:35:36 + +64. +64, yeah. +But that would look like two hashes that are both 32 bytes. +And why is that a problem? +Because... +Where are these hashes in the blockchain? +It's caused multiple problems in the past. + +Speaker 1: 00:35:48 + +Exactly. +So there is a in each block is a Merkle tree of all the transactions in that block. +And all the leaves of the tree are 32 bytes, these transactions. +And then you go one level up and it's 32 bytes again, it's 32 bytes again. +And now what you can do is you can give somebody a block and say, here's a block and here's all the transactions in this block. +And then you verify it and you see these 32 transactions. +Sorry, you see these two times 32s and you combine them and it looks all good, but somebody could leave out the actual transactions and just pretend that it's only a 64 byte transaction instead of two separate ones. +But then you validate the 64 byte transaction and you say hey this is an invalid transaction so the whole block is invalid and now you think this block is invalid and the next time you see this block because somebody gives you the same block hash you're like I don't you know I'm not gonna check this block it's invalid but actually it's not invalid because somebody sent you because now you got the real one where you actually have the two separate transactions in it. + +Speaker 0: 00:36:55 + +I'm lost. +Who's the target here? +What's the problem and who are we targeting? + +Speaker 1: 00:37:02 + +Well, there are different targets. +So this example, I think, could be used to make a network split where you would make a real block with two 32-byte transactions in it, but that when you combine those two 32-byte transactions, it would also make a real 64-byte transaction. +So the hash of those two transactions, not 32-byte transactions, but the hashes of those two transactions, if you add them together, look like a real transaction, but it's an invalid transaction. +So now you are, or the other way around, the 64 byte thing is valid, but the two individual transactions are invalid. +So if you give somebody a block, it will have the same hash at the top because the Merkle tree is the same at the top and that's the only thing you're communicating when you're communicating a block hash. +So I'm giving you a block hash and I'm giving somebody else the same block hash but I'm going to give you the two transactions And I'm going to give this other person the one 64 byte transaction. +And now one of you is going to say this block is invalid, and the other is going to say this block is valid. +Now you have a network split. + +Speaker 0: 00:38:13 + +Yeah, okay. +I kind of get that now. +Except, what do you mean? +Why would they check for different things? + +Speaker 1: 00:38:20 + +Because I've given you the the block hash the root of the Merkle tree I've also given you all the transactions individually okay so you're actually putting those back in a tree But I'm giving you a different set of transactions than I'm giving the other person. +They get the same root of the tree, but one of them will say, hey, this transaction is invalid, because I don't know, it's spending more money than it's earning some other rule that's violated. + +Speaker 0: 00:38:43 + +Right. +And that's Because it's not really a transaction, it's really two 32-byte hashes. +Yeah. +Am I saying that right? + +Speaker 1: 00:38:51 + +Of real transactions. + +Speaker 0: 00:38:52 + +Of actual transactions. +Yeah. +So for one person... + +Speaker 1: 00:38:55 + +One person sees a 64-byte transaction. + +Speaker 0: 00:38:57 + +One person sees one invalid 64-byte transaction. + +Speaker 1: 00:39:00 + +Or valid. +One person sees one 64-byte transaction. +The other person sees two other transactions doesn't matter what size they are yeah and right if these two transactions are invalid but the 64-byte one is valid yeah then you come to a different conclusion at the block. + +Speaker 0: 00:39:19 + +And this depends on which transactions you saw earlier, essentially, kind of. + +Speaker 1: 00:39:25 + +Well the rest of the block is the same, right? +So It's just that one of these transactions is actually invalid. +So the 64 byte transaction might be invalid or it might be valid. + +Speaker 0: 00:39:37 + +Yeah, I think... + +Speaker 1: 00:39:37 + +That has nothing to do with what you've seen before. +You're basically just giving two versions of the same block that you know think is the same block because it only remembers the hash and it's not. +So that bug has been fixed by simply not storing the block if it's invalid. + +Speaker 0: 00:39:53 + +So- +No, hang on. +Okay. +I have a question. +I still have one question. +All right. +You and I are both running a node, okay? +Yeah. +Now some Joker sends us a transaction, sends us a block that has this 164 byte transaction in it. +Why would my nodes look at this like 232 byte transactions while your node is looking at it like a 164 byte transaction. + +Speaker 1: 00:40:21 + +Because as the joker is sending you the hash of the block and it's sending you all the individual transactions. +So he's sending you two individual transactions at the end of this block and it's sending me one individual transaction of 64 bytes. +So they're sending us two different things. + +Speaker 0: 00:40:40 + +Isn't that just in the block? +Isn't that just the block that he's sending? +That's the block, right? +The In the block is the transaction. + +Speaker 1: 00:40:48 + +When you receive a block, what it really is, is a message. +And the message starts with the header, and it's followed by the list of every single transaction. +And so that list of transactions, it's different. +So if you printed it out on a piece of paper, you would see that at the end of the piece of paper, it's different. +You and I got a different block. + +Speaker 0: 00:41:07 + +We got a different block. +It just has the same hash. +Yes. +It hashes to the same hash. + +Speaker 1: 00:41:12 + +And because you say it's invalid. + +Speaker 0: 00:41:14 + +Yeah, because it is invalid. +The one you sent me is invalid, of course. + +Speaker 1: 00:41:17 + +Exactly, but now if somebody else sends you the correct one. + +Speaker 0: 00:41:20 + +Yeah, then I'll be like, no, I already saw this and it was invalid. + +Speaker 1: 00:41:23 + +Yeah, and so that problem, you know, keep in mind that this problem was discovered in 2012 or something, so back then that attack was cheap. + +Speaker 0: 00:41:30 + +Right. + +Speaker 1: 00:41:30 + +Right now this attack would be expensive but the attack was fixed because basically when this happens to you, you say hey this block is invalid, you just forget it. +And so the next time somebody sends you the correct one, you're fine. +So that attack is fixed. +But then there was other ways that you can fool light clients like SPV wallets using the same trick because they are asking just for an SPV proof. +So they just want proof that a transaction was included and you could now give them a transaction that they think is included because you gave the SPV proof, but it wasn't included because the real block had two separate transactions that happened to combine to this one fake transaction. +And this could be used to steal Lite wallets, but possibly also to rob sidechains if those sidechains only use SPV proofs for peg ins and peg outs. +And that problem, I think was solved by telling Lite clients to be careful. +I don't think it was actually solved. + +Speaker 0: 00:42:19 + +Okay, back to the great consensus cleanup revival. +What's the solution here? + +Speaker 1: 00:42:24 + +Don't allow 64-byte transactions. + +Speaker 0: 00:42:25 + +Well, what if my transaction is 64 bytes though? + +Speaker 1: 00:42:28 + +Then you are out of luck. +So if you still have one of those in the safe, you better spend it. + +Speaker 0: 00:42:34 + +So, if I create a transaction that consists of 64 bytes, because I want to pay exactly this many people, this many coins with these many UTXOs, then the Bitcoin network says no, your money is not valid here. + +Speaker 1: 00:42:49 + +Yeah, I think the actual examples would be burning coins. +So you can make an OPRETURN transaction that burns your coins, doesn't send it anywhere. +And that can be shorter than 64 bytes, but it could also be 64 bytes. +So if you want to burn your money using a operator that is exactly 64 bytes in total, then yeah, you can do that. + +Speaker 0: 00:43:10 + +Are there no normal transactions that are exactly 64 bytes? + +Speaker 1: 00:43:13 + +I believe not. +So You can already not send those in the mempool today. +It won't be relayed. + +Speaker 0: 00:43:20 + +Okay. + +Speaker 1: 00:43:21 + +I think that was the change in version 25. +I think there was a rule that says nothing under 64 bytes, or sorry, nothing under 65 bytes. +That was the mempool rule. +And then people were like, well, but it could be useful to have a 63 byte or 62 byte transaction to burn your coins. +And so I think the rule was changed to no 64 bytes. +So the difference is make this consensus rather than policy. + +Speaker 0: 00:43:46 + +Okay. +So most transactions are well over 64 bytes or at least more than 64 bytes. +That's normal for a transaction to be more than 64 bytes. +If you see a 64 byte transaction, it's kind of something special. + +Speaker 1: 00:43:59 + +Yeah, then it's probably an attack. + +Speaker 0: 00:44:00 + +Okay, right. +And now the great consensus cleanup says let's just get rid of that altogether. +However, 63 or 62 that's still okay. +If you really do like if you're not attacking but you're burning coins that that should work. +But yeah, so basically if people make 64-byte transactions in the future and the soft work happens, then their transaction wouldn't be confirmed. +Then they have to make a new transaction that's either 63 or 65 or something else. +As long as it's not 64. + +Speaker 1: 00:44:31 + +And you can probably malleate it. +So I think we talked about transaction malleation, where you can like mess with another transaction. +So you might, even if you lost the original coin that you used to make this thing, I think you might be able to just make it one byte longer, but I'm not entirely sure about that. + +Speaker 0: 00:44:48 + +Right okay got it sounds like. + +Speaker 1: 00:44:52 + +But this is another case of like yes it would be you know you could just ban everything anything under 64 but or anything under 65 but you want to make the minimum change possible to reduce controversy that's not too complicated. + +Speaker 0: 00:45:04 + +Okay last one BIP 3034. + +Speaker 1: 00:45:08 + +Yeah we did a whole episode about this called episode 87. +It was called the block 1, 983, 702 problem. +Right. + +Speaker 0: 00:45:18 + +What was that problem again? +It was about two transactions that look similar, right? + +Speaker 1: 00:45:23 + +Yeah, so the TLDR of this one is that there was a BIP30 that prevents duplicate transactions. +Because having duplicate transactions, transactions with the same hash, it causes problems. +You can override coinbases, do all sorts of weird things. +It happened a few times in the beginning of Bitcoin. +It was fixed. +The problem of this fix is that it was a slow fix. +So every time there's a new block coming in, you have to check every transaction to make sure that it doesn't already exist and this check is expensive, requires a lot of disk reading. +Unfortunately and so there was a way to speed it up, the way to speed it up was to make, to force the Coinbase transaction to have the block height in it. +So that makes every Coinbase transaction unique, and since every transaction eventually descends from a Coinbase transaction, every descendant is unique. + +Speaker 0: 00:46:12 + +Yeah, that way you can't have duplicate transactions anymore. + +Speaker 1: 00:46:15 + +Yeah, and so then people thought, okay, so we can turn off this expensive check. +But it turns out you can't, because there are some very old transactions before this BIP34 rule was introduced, that if you read them, you could interpret the first bytes of those transactions as a version, sorry, as a block height. + +Speaker 0: 00:46:36 + +Yeah. +And- +So there's something in these old transactions, in these old UTXOs, I guess we should say. + +Speaker 1: 00:46:41 + +Yeah, that is effectively the same as putting a block height in there, but the wrong one. + +Speaker 0: 00:46:45 + +Yeah, yeah, Yeah. + +Speaker 1: 00:46:47 + +And so these ones are gonna start, we're gonna start encountering these and we've already encountered a few, but they didn't cause problems. +So we got lucky. +And so as of the first one we're going to encounter again is block 1, 983, 702. +So there is an old transaction out there that looks like it's at that height. +So in theory somebody could then make a could make a coinbase transaction that's a duplicate of that old one and we don't want that so the pip 30 check the slow check is re-enabled from that hide on. +That's annoying because that check as we said is slow, so the proposal here is to do something else that makes sure that this duplication cannot happen. +So not just putting the height in the Coinbase but also putting something else in it. +What that something else is we don't know. +My favorite is to make SegWit mandatory as in the SegWit commitment because every SegWit block has an OP return and followed by the hash of the witness data. +And right now, if there is no transactions in a block, including if there's no segwit transactions, even in the Coinbase, well then there's no witness commitment. +And so that opportunity is not present, but you could make it mandatory from off. +Basically you could make it mandatory starting at block 1, 983, 000. +And so people will have 20 years to upgrade. +Yeah. +But if they don't, they could accidentally mine an invalid block at that height. +Right. +There's different ways to do it. + +Speaker 0: 00:48:16 + +We discussed this at length in the other episode, of course, which was 87, for anyone who wants to know more about this problem. + +Speaker 1: 00:48:24 + +So that's roughly the... + +Speaker 0: 00:48:24 + +And then also the potential fix, 87. + +Speaker 1: 00:48:27 + +So that's the whole great consensus cleanup. +And so as you can hear, some changes are very straightforward, there's not really any discussion. +Some, there is discussion. +And so we'll have to figure that out. +And then at some point, somebody will have to take the initiative to actually propose this as a soft fork, do activation parameters, hope there's no drama. + +Speaker 0: 00:48:49 + +Well, that is kind of one of the side goals of this proposal, I would say, is figuring out how we actually do soft forks and how we actually do Bitcoin upgrades. + +Speaker 1: 00:49:02 + +Exactly. +This was proposed long before Taproot as a way to sort of get over the SegWit trauma. + +Speaker 0: 00:49:07 + +Yeah. +Like we're still, it's still not clear how we're supposed to do these kinds of things. +So then the idea was let's do something that's very uncontroversial, that everyone should or does or will agree on. +There's nothing, like it's just very obvious bugs that we're going to fix. +And then we can figure out how we're actually supposed to do these soft forks. +And then, you know, it's sort of a good trial run for, you know, future software, I guess. + +Speaker 1: 00:49:37 + +Yeah, now we've already done Taproot, but of course there was still discussion about how that software was activated. +So I don't know if we really now have a, you know, have broad consensus on how to do this. + +Speaker 0: 00:49:46 + +Oh, we definitely don't, sure. + +Speaker 1: 00:49:47 + +But this may be another case of like, nobody cares what the activation mechanism is, just activate it. +The main thing is, of course, this takes away the options of miners to do a time warp attack. +So if they actually like to keep that option, they might veto it, and then you get into more difficult territory. + +Speaker 0: 00:50:07 + +Well, I don't know if we want to get into the whole activation discussion in this podcast episode. + +Speaker 1: 00:50:14 + +We do not. +I'm just saying like it might be straightforward, it might not be and we'll have to we may have to I'm telling you it will not be okay I'm more bullish and of course we keep in mind that you can deploy multiple soft forks in parallel so This doesn't have to be before or after your favorite feature X. +You can activate 10 soft forks at the same time. + +Speaker 0: 00:50:38 + +Yeah, remember when people thought that would actually happen? +Good times. +Good times, + +Speaker 1: 00:50:44 + +indeed. +I'm just saying, don't worry about that aspect. +Okay, I think that's all we've got. +Thank you diff --git a/bitcoin-magazine/the-politics-of-bitcoin-development.md b/bitcoin-magazine/the-politics-of-bitcoin-development.md new file mode 100644 index 000000000..fbbe8252c --- /dev/null +++ b/bitcoin-magazine/the-politics-of-bitcoin-development.md @@ -0,0 +1,142 @@ +--- +title: "The Politics of Bitcoin Development" +transcript_by: kouloumos via tstbtc v1.0.0 --needs-review +media: https://www.youtube.com/watch?v=NrrD6ufaSrM +tags: [] +speakers: ['Christian Decker'] +categories: [] +date: 2024-06-11 +--- +## Introduction and Rusty's Proposal + +Speaker 0: 00:00:01 + +Hi everybody, I'm Shinobi from Bitcoin Magazine and I'm sitting down here with Christian Jecker from Blockstream. + +Speaker 1: 00:00:07 + +I am. + +Speaker 0: 00:00:08 + +So Rusty dropped an atom bomb yesterday with his proposal to turn all the things back on just with the kind of VerOps budget analogous to the SigOps budget to kind of rein in the denial of service risks as just a path forward given that everybody's spent the last few years fighting over their narrow little change they want to get in. +How do you feel about this potentially as a path moving forward? + +Speaker 1: 00:00:43 + +I got extremely lucky that Rusty proposed it because otherwise my talk on the frustrations of as a bib editor would have been kind of even more depressing than it already was. +And so I saw his presentation and was like, oh, I need to change my slides now. +Because you're right, we have been trying way too long to be clever in as much that we try to sidestep the discussion of whether we want covenants, what kind of covenants we want, or introspection as we like to call it. + +## Challenges in Bitcoin Development + +Speaker 1: 00:01:26 + +And it turns out that all of our cleverness wasn't enough for us to actually sort of sneak our little change through, right? +That was always the goal. +We wanted to get here, but to get here, we needed to have this intermediate step, essentially activating a small soft fork that would enable us to build whatever cool stuff we wanted to build on top for our users and for ourselves of course. +And so everybody was sort of hung up on this activation of the enabling step there And since nobody wanted to have the discussion about, hey, do we want covenants? +What covenants do we want? +Are they safe? +We tried to make our proposals so specific that everybody needed a different one. +And so since the review cycles in the Bitcoin community are rather limited, the people that can actually look at a proposal and say, OK, yeah, that's safe or it is not safe, are very few indeed. +And so we ended up in a situation where you'd actually have to badmouth other proposals in order for your proposal to grab the attention that is needed to get your proposal through. +And that never really worked. +It also feels really bad to have to essentially badmouth somebody else's proposal just because you needed it to work, right? + +## The Need for Honest Dialogue and Cooperation + +Speaker 1: 00:03:03 + +And then as a compounding factor, we found that many of the proposals that we tried explicitly not to make into Covenants ended up enabling Covenants anyway. +And so not only was it sort of futile, but it also ended up creating this huge tension and frustration among developers and among users, because you actually had to involve users in your propaganda to get your proposal, give your proposal traction. +And so this is, this felt very much like a liberation strike. +It felt very much like something where we could say, okay, let's approach this as engineers, which is what most of us are, and not as propagandists or salespeople trying to sort of, ah, just get your stuff done. +And the idea was essentially to, okay, let's put this on a more fundamental level. +Let's restore the script we had in the very, very early versions of Bitcoin without the issues, of course. +But let's re-enable that functionality. +Let's give everybody the tools to build whatever they want. +Let's not be patronizing them. +And essentially give them the tools to show their work, show that it is working, show that there is interest in the wider community, and that it is actually being used, right? +And so it might be inefficient, the way that you can do arbitrary things, but you can at least show your work and you can show it works. + +## Restoring Early Bitcoin Script Functionalities + +Speaker 1: 00:05:04 + +And then once that is done, then it's the time to actually optimize. +Because then everybody is interested in actually optimizing those use cases. +It's not a use case you're interested in, but it is taking up a bit of blockchain space. +So by enabling more efficient opcodes based on our prior experience, we can then all have the upside of the performance improvement. +And so I think that is a much more honest dialogue to have. +And it's also a much more, much less noisy sort of way of working towards a common goal, which is enable programmable money on Bitcoin. +And so I was incredibly happy when Rusty came up with his presentation and I sort of tweaked my presentation because it was sort of this light at the end of the tunnel for me. +And it felt good seeing that there is this possibility of getting back the script and its flexibility in the way it originally was, and as well solve some of this friction we have inside of the Bitcoin developer community. + +Speaker 0: 00:06:32 + +And I think you make a really important point as far as the involvement of users. +I think regardless of whether this actually moves forward and it's the direction we choose to go in, if it's just seriously discussed, I think that can be an incredibly healthy thing for the larger and wider ecosystems involvement because the way a lot of people approach these discussions when the actual subject matter is above their head is just look at like associations that people who are pushing for a specific thing have and is that a good thing to be Associated or a bad thing and then just transitively apply that to whatever proposal they're pushing for. + +## The Impact of Enabling Diverse Tools + +Speaker 0: 00:07:17 + +Whereas if we move in a more cooperative direction where everybody just openly discusses like the complete set of things that we want enabled, and you know, is this good, is this bad, is the good worth like taking some of the bad for the gains we can get from it? +That makes it a lot more difficult for, you know, outside of observers to just associate a single aspect of something and go, well, this person does this thing that I don't like, so therefore I don't like that proposal, because everybody would be just working towards that singular consensus view on things rather than the politicking we've been dealing with. + +Speaker 1: 00:08:00 + +Yeah, absolutely. +It's obvious that we need to defer to experts. +I'm not an expert in some subject matters and I will defer to those experts. +But if those experts are themselves incentivized to present a one-sided picture, because it's holding up their progress, it's holding up the possibility of actually getting their application working. +Then the community as a whole also gets a very, very skewed image of what is actually going on. +In Bitcoin, until now, you always had to be very loud, you had to be very salesy, and you always had to present this, oh, this is the upside of mine, but there's the downsides of everybody else right. + +## Moving Away from Propaganda and Infighting + +Speaker 1: 00:08:51 + +And so you never had an incentive of being honest when talking about the upsides but also downsides of your proposals because whenever you mention a downside it could be twisted in this marketing machine against you. +And I find that just very dishonest. +And why did we do that? +Because ultimately it's the community that gets to decide. +It's everybody put together that gets to decide. +And you had to do marketing at that point. +I'm not a marketing person. +I like to discuss downsides as much as I like to discuss upsides. +And I think with a more objective approach to the tradeoffs that are involved, we can make better progress, we can come to proposals that are ultimately better engineered, that had more review, that are safer than if we all try to do some piecemeal little changes. +Because as much as we try to bolt those down, the combination of multiple of these very targeted changes could still open up functionality in their combination. +And so it's a very nuanced discussion to have. +And if we throw propaganda in the mix, then all we get is noise at the end. + +Speaker 0: 00:10:28 + +So overall, you feeling positive about the directions things are going? +Like this might actually kind of set us back on course to being more productive rather than the infighting? + +Speaker 1: 00:10:41 + +It feels very much like a breath of fresh air. +We were entrenched a lot over the last years. + +## Final Thoughts and Future Prospects + +Speaker 1: 00:10:52 + +We had a lot of infighting and like I said in my talk, I'm not that good with conflict And it also affects the individuals that are having these conversations, that are having these discussions. +And it just feels good to have a perspective that we could make progress soon again and get everybody on at the table and give them a voice and be able to have the technical engineering discussions rather than the propaganda discussions that we've had for the last couple of years. +So it's very refreshing. + +Speaker 0: 00:11:39 + +All right, well, I'd like to thank you for sitting down with me, Christian. + +Speaker 1: 00:11:43 + +Hey, thank you so much, Shinobi. + +Speaker 0: 00:11:44 + +All right, and I hope everybody enjoyed. diff --git a/brink/the-bitcoin-development-podcast/discussing-0-21-0-bitcoin-core-vulnerability-disclosures.md b/brink/the-bitcoin-development-podcast/discussing-0-21-0-bitcoin-core-vulnerability-disclosures.md new file mode 100644 index 000000000..103dbd2eb --- /dev/null +++ b/brink/the-bitcoin-development-podcast/discussing-0-21-0-bitcoin-core-vulnerability-disclosures.md @@ -0,0 +1,544 @@ +--- +title: "Discussing 0.21.0 Bitcoin Core Vulnerability Disclosures" +transcript_by: kouloumos via tstbtc v1.0.0 --needs-review +media: https://podcasters.spotify.com/pod/show/bitcoinbrink/episodes/Discussing-0-21-0-Bitcoin-Core-Vulnerability-Disclosures-e2mm5sr +tags: ['bitcoin-core'] +speakers: ['Gloria Zhao', 'Niklas Gögge'] +categories: [] +summary: "Brink engineers Gloria Zhao and Niklas Gögge talk through the recently disclosed Bitcoin Core 0.21.0 vulnerabilities." +date: 2024-07-31 +additional_resources: + - title: Episode 4 + url: https://brink.dev/podcast/4-bitcoin-core-pre-21-disclosures/ + - title: Disclosure of remote crash due to addr message spam + url: https://bitcoincore.org/en/2024/07/31/disclose-addrman-int-overflow/ + - title: 'Bitcoin Core #22387' + url: https://github.com/bitcoin/bitcoin/pull/22387 + - title: Disclosure of the impact of an infinite loop bug in the miniupnp dependency + url: https://bitcoincore.org/en/2024/07/31/disclose-upnp-oom/ + - title: 'Bitcoin Core #20421' + url: https://github.com/bitcoin/bitcoin/pull/20421 +--- +## Introduction + +Speaker 0: 00:00:00 + +Hello, Niklas. + +Speaker 1: 00:00:02 + +Hi, Gloria. +We're here to talk about the next batch of disclosures for Bitcoin Core. +And this time there's only two bugs and they were fixed in version 22. +So that means 21, version 21 was still vulnerable to these two bugs. +If you're running version 21, you should upgrade. +I mean, you can listen to this podcast and decide for yourself if you want to upgrade, but my recommendation, our recommendation would be that you upgrade. +Next month, we'll be doing bugs for version 22. +So ideally, you upgrade to the latest maintained versions, which the lowest one currently is 25. +So you should upgrade to 25, 26, or 27. + +Speaker 0: 00:00:50 + +Right. +So yeah, spoiler, but don't just upgrade to 22. + +Speaker 1: 00:00:58 + +Yeah, because you're just doing the same thing every month. + +Speaker 0: 00:01:02 + +OK, great. +So why don't we dive into the disclosures. + +## Background on Bitcoin peer-to-peer address relay + +Speaker 0: 00:01:07 + +The first one we wanted to talk about was the Adder Relay one, right? +So let's give a bit of background for address relay. +So the problem here is when you start up your Bitcoin node, you need to connect to the network and the network is consisting of anonymous, pseudonymous nodes. +And there's a few things that make this kind of difficult. +One is that the active nodes on the network and their IP addresses or onion addresses, it changes on like a per second basis, right? +So if we tried to release software where we went and scraped all of the addresses of the active nodes on the network and tried to publish that along with the Bitcoin Core software, that would be outdated really, really quickly. +And the second thing that makes this really difficult is, of course, like, because these peers are anonymous, you might imagine that there are malicious peers and people that are going to tell you about addresses, they may give you the addresses of just nodes that they control. +And that can be really, really dangerous because if you join the network and let's say you connect to 20 other nodes and all of them are controlled by this one person who is say trying to attack you, you've been eclipsed. +And something that they can do is they can either withhold the current main chain from you so you're not aware of new transactions and new blocks that come out, or they can even feed you an alternative chain where, For example, you got paid when you didn't actually get paid in the real Bitcoin blockchain. +And so it's very important that your contact book, your address book, has hopefully honest, good peers in there. +And so, on the node, sorry, on the network, nodes will gossip adders to each other, addresses. +So this is different from your Bitcoin address, like BC1, blah blah blah. +This is the addresses, network addresses, like IP addresses or onion addresses. +So just make sure that you don't confuse those. +We're going to call them adders. +We have adder gossip. +And like I'm alluding to, it's an example of, you know, data that's really crucial, really important to the functionality of your node. +But there's no meaningful way for us to, say, attach a proof of usefulness or proof of correctness to these pieces of data. +So unlike blocks that all have proof of work on them, someone can send you, like you'll say, thousands of adders that are all incorrect. +They don't actually correspond to real nodes or they correspond to malicious nodes, et cetera. +But we still need to make sure that we optimistically kind of download this information and handle it in some way that allows us to still connect to the honest part of the network and hopefully damage control if there is someone spamming incorrect or malicious adders. +So do you wanna continue with Adderman? + +Speaker 1: 00:04:28 + +Sure. + +## Bitcoin Core's AddrMan (address manager) data structure + +Speaker 1: 00:04:29 + +So One part of the solution that Bitcoin Core has is a data structure called the AdderMan, which basically is a database for addresses you've seen, and it also sort of has some heuristics for deciding which addresses are good, which addresses you've tried to connect to. +So it doesn't just keep around all addresses that you've seen ever. +But rather tries to keep around a selection of good addresses and potential addresses to try in the future to connect to. + +Speaker 0: 00:04:59 + +Right, and we're not going to immediately try adders that are sent to us. +A, because it's quite expensive and B, it could be a perfectly good address, but they just happen to not be online right now. + +Speaker 1: 00:05:13 + +Yeah, so over time as we have a need for new connections. +We occasionally try connecting to addresses stored in the AdderMan. +I think there's actually a specific connection type for this, right? +The feeler connections? +Right. + +Speaker 0: 00:05:32 + +Yeah, feelers. +Yeah. + +## Disclosure of remote crash due to addr message spam + +Speaker 1: 00:05:36 + +Anyway, this bug is concerned with some internals of the Adderman. +So it has this internal count of how many addresses have been inserted into the AdderMan, like in total, and basically this variable is increased every time you insert an address. +And it's a 32-bit integer, which means at most you can insert 2 to the 32 adders into Adderman before this variable overflows. +Now why is it bad if that variable overflows? +Adderman has internal consistency checks, which basically all the state it has, it'll make sure that it's all consistent and doing the right thing. +But if this ID count overflows, then the consistency checks fail. +And the way Bitcoin Core handles the consistency checks failing is crashing the node. +And I think you could have a discussion around if that's the right approach, but I think with regard to like Eclipse attacks or whatever, it's probably good that you just crash instead of continuing to run with like an inconsistent Adder database. +But yeah, so essentially if you're an attacker, you could spam a node with a bunch of addresses. +Pretty much, you know, two to the 32 adders you would have to send, which is, I'm not sure how many gigabytes, but like multiple. +I should probably know how many gigabytes. +It's like 10 to 20 gigabytes or something, I think, that you have to send. +And then your victim would overflow its counter and crash. + +Speaker 0: 00:07:16 + +So what's, so this is, yeah, 2 to 32 is a really big number. +How would you contrast that with what the expected amount of Adder gossip you'd receive? + +Speaker 1: 00:07:28 + +Yeah, so If you establish a connection initially, you'll ask your peer for addresses using a get adder message. +So you send the get adder and then you get a bunch of addresses in return. +I think that's limited to a thousand addresses and that only happens once per connection at the start of the connection essentially. +And then there's also this like casual adder gossip, which if you receive addresses, you will relay some of them to a few of your peers. +And I'm not sure what the average or expected number of this casual relay is. +But prior to the fix for this bug, there was no rate limiting on this. +So you could just spam as much as you want. + +Speaker 0: 00:08:19 + +Well, I think there was rate limiting for how much we would forward. +Yeah. +But yeah, anything that was sent. + +Speaker 1: 00:08:25 + +You would just process anything that you get. + +Speaker 0: 00:08:28 + +Right. +Right. +And there were other things in place to try to balance between, to protect against just being spammed with malicious data, of course. +But in terms of this number, we were okay with being sent a lot of adders. + +Speaker 1: 00:08:46 + +Yeah. + +## Address spamming observed on the network + +Speaker 1: 00:08:46 + +And I think what's interesting is the fix basically introduced the rate limiting, but then once the PR was opened, we saw someone starting to spam addresses on the network. + +Speaker 0: 00:08:57 + +Right. +Yeah, yeah, + +Speaker 1: 00:08:58 + +yeah. +Which at the time, the people handling this issue weren't sure if someone was trying to exploit the crash bug or if there's some other behavior that they were trying to abuse. +And they saw like, basically, we were wondering if the rate limiting PR triggered someone to abuse something that they would no longer be able to use after the PRs merged. + +Speaker 0: 00:09:20 + +Right, I think I remember, was it, I think Martin was talking about it, right? +And was it just like a coincidence? +Like, wasn't it Katsuo doing research? + +Speaker 1: 00:09:33 + +Well, I think the conclusion was that someone was doing research and someone made a guess as to what it might be and it has something to do with estimating the number of actions a node has. + +Speaker 0: 00:09:47 + +Right. +Yeah. +Yeah. + +Speaker 1: 00:09:49 + +Like estimate the degree of a node. + +Speaker 0: 00:09:53 + +Yeah. +I think if you go to the KIT node stats website, they have all kinds of stuff like all of the adders that are reachable on this day or something like that. +Or, you know, the number of adders that people are talking about that day. +I'm not sure. +But so, sorry, I still don't understand. +Was it a coincidence or was it? + +Speaker 1: 00:10:18 + +I don't think we know exactly who did it. +We only have like a guess as to what it was for. + +Speaker 0: 00:10:25 + +Okay. + +Speaker 1: 00:10:25 + +But I don't think there was ever any. +So there was a small paper published by someone trying to make a guess. +I think that was the KIT people. +They were trying to guess what was happening. +But the actual, whoever did it never released anything as far as we know. + +Speaker 0: 00:10:44 + +Kaitlin Luna, Ph.D.: Nate, was it just somebody testing the PR? + +Speaker 1: 00:10:47 + +It could also be. +Well, maybe. + +Speaker 0: 00:10:50 + +No, that seems like a weird way for someone to test it. + +Speaker 1: 00:10:53 + +But yeah, that was kind of a fun fact about this fix. + +## Bitcoin Core #22387 PR to fix addr message spam + +Speaker 0: 00:10:56 + +Okay. +Do we want to talk more about the PR that fixed it? + +Speaker 1: 00:11:01 + +Sure. +I think you might be better to lead on that because I did not. + +Speaker 0: 00:11:07 + +I think I remember us reviewing this PR actually, but it was like us together. +Yeah. +With what was it not? +I mean, + +Speaker 1: 00:11:14 + +it's a long time ago. +Yeah. +I do think I remember looking at it. + +Speaker 0: 00:11:19 + +Me too, but I don't really remember much in it. +It's like a token bucket style rate limiting for adders that people send to us. +So as Nicholas already enumerated, we have kind of solicited adders. +When we connect, we're like, oh, we're friends now. +Who are all your friends? +We have kind of unsolicited, random, casual gossip, as you said, and then we also have self-advertisements. +And I think that covers all of the Adder announcements that we'll send, at least as an honest Bitcoin Core node. + +Speaker 1: 00:11:59 + +Actually, in the PR description, Peter has an estimate for like expected or average address per second. +And he says it seems to vary for like 0.005 to 0.025 addresses per second. +Right. +Which is obviously pretty low. +So the PR puts a rate limit of 0.1 address per second, but it also allows a burst of a thousand addresses at once to allow for the get adder response. + +Speaker 0: 00:12:37 + +Right, I think the token bucket stuff doesn't start until that. +So we do keep track of whether or not we've sent and received a response for a get adder. +Right, so as any token bucket mechanism works, each peer is given a token, well, it's just a counter. +It's just a counter and a map. +An amount of tokens for adders you can send. +Each time you send us an adder, we take tokens out of your bucket. +When you're out of tokens, any adders you send, we just drop on the floor. +And more importantly, we don't increment this 32-bit counter. +And That's it. +I think it's fairly simple, I think. +**JASON LENGSTORF** Yeah. +**MARCEL MANCINO** Okay. +Should we move on to the next one? + +Speaker 1: 00:13:27 + +**JASON LENGSTORF** Sounds good. +**MARCEL MANCINO** Oh. + +Speaker 0: 00:13:32 + +I think before we move on, we should do the credits. + +Speaker 1: 00:13:35 + +Oh, yeah. + +Speaker 0: 00:13:35 + +Just to make sure that we credit everyone. +So credits to Eugene Siegel for discovering and then Peter Willa for fixing the bug. + +## Background on Miniupnp, the UPnP library used by Bitcoin Core + +Speaker 0: 00:13:46 + +Why don't we move on to the UPnP one, which if you listened to our last episode, is our favorite dependency of Bitcoin Core. +Let's see, so yeah, We gave some background in the last episode, but in order to receive inbound connections for a Bitcoin Core node, we have to set up port forwarding. +And we have MiniUPNPC as a dependency to help do that automatically. +It's off by default because of the disclosure from last episode. +But it's today, even. +It is a dependency of Bitcoin Core. +So what needs to happen before you set up port forwarding is you have these two devices, you have your router and you have your Bitcoin Core node that are on the same local network, and they need to talk to each other to say, hey, can you set up, you know, port forwarding for 8333 for me? +Before that, they need to discover each other. +So, I think part of the UPnP stuff is, what will happen is they'll send out an mSearch announcement, and then devices on the network will see that announcement and reply with like, hey, I'm this device, here's my something number and some information about me. +And then hopefully that's how we discover the router and then we'll be like, okay, I'm talking to you, please do this for me. + +## The bug in Miniupnpc + +Speaker 0: 00:15:18 + +However, there was a bug in mini-UPnPC where this loop, there's this loop where it listened for responses to the msearch and it would just add new devices to its list of devices. +And I think it's like the way the loop is written, it kind of like assumed that it would like stop, and then you could, it was assumed that the loop would terminate. +But I think... + +Speaker 1: 00:15:45 + +I think the assumption was that you stop receiving data at which point the loop exits. + +Speaker 0: 00:15:51 + +Right. +Yeah. +Or I think I want to say it's on some kind of time interval as well. +So it was like, we're not going to receive a million in one second. +I can't remember. +Anyway, someone upstream discovered that this can loop infinitely. +I think they plugged in like a mouse or something that was just very, very aggressive in broadcasting their device info or something. +And they discovered that this looped infinitely. + +## Disclosure of the impact of an infinite loop bug in the miniupnp dependency + +Speaker 0: 00:16:31 + +And so, Michael Ford, Vanquick, looked at, he was monitoring upstream where this bug was discovered and fixed and was like, okay, the implication for Bitcoin Core here is when Bitcoin Core kind of does this, if there's a local device on the network, any local device, that does kind of the same behavior where it's just like spamming these msearch responses, then the Bitcoin Core, because it uses this library, will also go in this infinite loop. +And within this infinite loop, each time you add a device to your list, you're going to allocate some space on the heap to store the strings and whatnot, the data that was in the reply. +And so I think FanQuake wrote a script to do this with like unique numbers and like a very large string, something like that. +And then eventually you would oom within this infinite loop where you're continuously allocating space. +And so put this all together, upstream vulnerability means that your node may crash if there's something on the local network that is doing something like this. + +## Bitcoin Core #20421 PR to fix the infinite loop bug in the miniupnp dependency + +Speaker 0: 00:17:49 + +So yeah, the fix, of course, because this was fixed upstream, was to update the dependency to use the fixed version of it, which Netquick also did. +And that's it. +Anything to add? + +Speaker 1: 00:18:05 + +Well, I guess we can give credits to Ronald Hoveniers, who initially discovered the infinite bug and reported it to the Mini-UPNP Project. +Yes. +I hope I pronounced the name correctly. +And then Michael for realizing what the impact on Bitcoin Core is and providing a proof of concept. + +Speaker 0: 00:18:25 + +Right. +So thanks. +Thanks to everyone who did that. +All right. +Is that the end of this episode? + +Speaker 1: 00:18:35 + +I think so. +Yeah. +Did we learn anything? + +## Lessons learned + +Speaker 0: 00:18:47 + +So I think following on the themes of last episode, I remember we talked a lot about kind of lower hanging fruit, such as, oh, like there's no bounds on this data structure. +And I think the rate limiting here, it's not really low hanging fruit, but it is along those lines of, at least I remember when I was thinking about orphanage for my current project, like kind of a very similar idea where we have this data structure and like we want to make sure honest peers use it, but we're also fully aware of there potentially being malicious peers that send completely unverifiable data. +Like we have no idea whether this is valid data or not. +We just have to kind of allow it where the solution is to kind of have this token bucket style per peer rate limiting. +And that's a technique that I learned from this. + +Speaker 1: 00:19:56 + +I see. +I see where that came from then. + +Speaker 0: 00:20:02 + +Your turn. + +Speaker 1: 00:20:03 + +Yeah. +I get like, I don't know. +I think for our dependencies, we could probably do a better job of trying to keep our dependencies up to the standard that we expect from the code that we write ourselves. +Yeah. +But yeah, I don't think anybody has really reviewed Mini-UPNPC, like from our side. + +Speaker 0: 00:20:26 + +Well, Fanquick has. +I'm just kidding. +It's a joke. + +Speaker 1: 00:20:29 + +But... +Well, I guess he found the issue. + +Speaker 0: 00:20:33 + +Yeah, so I asked him before we did this, how did you, are you just subscribed to everything? +And he says, well I just kind of keep tabs where I periodically look at them. +And he'll kind of flag slash complain every once in a while that certain dependencies are exhibiting some not great behavior. +Such, I mean, like this morning he was complaining that someone was opening all these refactoring PRs in LibEvent, right? +And I guess it kind of depends on what the maintenance slash contribution style or culture of the dependencies. +But yeah, I guess all we can do is minimize. + +Speaker 1: 00:21:28 + +Yeah, minimize or sort of maintain them ourselves. + +Speaker 0: 00:21:32 + +Right. +Oh, so we have a few, we can talk about, like we have some dependencies that we've subtreed. +Right, so there's like this big library, it's like a hundred thousand lines of code, and we haven't reviewed all of it. +We're not really sure as to how... + +Speaker 1: 00:21:48 + +Which library? + +Speaker 0: 00:21:50 + +I'm thinking of... + +Speaker 1: 00:21:52 + +I'm thinking of Boost. +Oh, Boost, yeah. + +Speaker 0: 00:21:56 + +But also, isn't Univalue something that we subtreed? + +Speaker 1: 00:21:59 + +Yes. + +Speaker 0: 00:21:59 + +Right, And univalue is part of a larger, no? + +Speaker 1: 00:22:03 + +But I think we've, well, I don't know. +I'm not too sure about this. +But I think we've kind of taken over the univalue. +We've made some changes that are not upstream. +So I think our subtree sort of just became, it's like integrated sort of. +It's just our code now essentially. + +Speaker 0: 00:22:21 + +Right, right. +Which I think is like other people would hate. +Like speaking of, we were talking about this earlier, it's like I was looking, I was browsing kind of engineering principles documents of various companies, where they're like, you know, move fast and break things. +And like, we deliver value to the users and stuff. +And one of the ways that one of the biggest things we'll talk about is like don't rewrite things like don't reinvent things that already exist. +Just like build upon stuff that's already there because we're not trying to we're not trying you know you don't waste time basically on things. + +Speaker 1: 00:23:01 + +I mean, yeah, if you're moving fast, or if that's your goal, then that obviously makes sense. + +Speaker 0: 00:23:06 + +Yeah. +And then here we are, where we're like, yeah, no. +Like, we took something that existed. +We decided to make a copy of it and put it in our tree. +And now we've like made our own changes and like customized it. + +Speaker 1: 00:23:25 + +Which also, I'm not sure if it's true for Univalue, but it might, like we might just be forced to do it because upstream it's unmaintained. +We need to make certain changes. +Like maybe we want to upgrade to a new C++ version and the dependency needs to move and there's no maintainer. +So we just absorb the dependency essentially and make it our own thing. + +Speaker 0: 00:23:49 + +Yeah. +Which I think is, again, I'm just saying that it's quite rare. + +Speaker 1: 00:23:54 + +I think. + +Speaker 0: 00:23:56 + +Yeah. +Welcome to security-oriented engineering. +All right. +Thank you for listening. +We'll be back again in a month for the next batch of disclosures. + +Speaker 1: 00:24:08 + +If you have any questions, let us know on Twitter or X. + +Speaker 0: 00:24:13 + +Okay. +Bye. +Bye. From 3b548c8df90da52becc2c262d71e12177bbe8d0c Mon Sep 17 00:00:00 2001 From: kouloumos Date: Fri, 6 Sep 2024 12:51:17 +0300 Subject: [PATCH 3/5] curate(transcript): The State of Bitcoin Core Development (bitcoin-magazine/bitcoin-2024) --- bitcoin-magazine/bitcoin-2024/_index.md | 5 +++++ .../bitcoin-2024/the-state-of-bitcoin-core-development.md | 8 ++++++++ 2 files changed, 13 insertions(+) create mode 100644 bitcoin-magazine/bitcoin-2024/_index.md create mode 100644 bitcoin-magazine/bitcoin-2024/the-state-of-bitcoin-core-development.md diff --git a/bitcoin-magazine/bitcoin-2024/_index.md b/bitcoin-magazine/bitcoin-2024/_index.md new file mode 100644 index 000000000..ac537f472 --- /dev/null +++ b/bitcoin-magazine/bitcoin-2024/_index.md @@ -0,0 +1,5 @@ +--- +title: Bitcoin 2024 Nashville +--- + +{{< childpages >}} diff --git a/bitcoin-magazine/bitcoin-2024/the-state-of-bitcoin-core-development.md b/bitcoin-magazine/bitcoin-2024/the-state-of-bitcoin-core-development.md new file mode 100644 index 000000000..13d0a471b --- /dev/null +++ b/bitcoin-magazine/bitcoin-2024/the-state-of-bitcoin-core-development.md @@ -0,0 +1,8 @@ +--- +title: "The State of Bitcoin Core Development" +tags: ['bitcoin-core'] +media: https://www.youtube.com/watch?v=zOZRRyboaYo +speakers: ['Aaron van Wirdum', Ishaana Misra', 'Ava Chow', 'Mark Erhardt'] +summary: "Discover the latest developments in Bitcoin Core with our expert panel featuring key contributors to the project. This video delves into recent changes in security vulnerability disclosures, the challenges of funding open-source development, and the careful process of introducing new features to Bitcoin Core. Our panelists offer unique perspectives on the project's priorities and the distinction between Bitcoin Core and protocol development." +needs: transcript +--- From 7a666f8fe0fe24d465d7b7a37dbd3bbd9394bc2a Mon Sep 17 00:00:00 2001 From: kouloumos Date: Fri, 6 Sep 2024 13:05:22 +0300 Subject: [PATCH 4/5] curate(transcript): Making Bitcoin More Private with CISA (bitcoin-magazine/bitcoin-2024) --- .../bitcoin-2024/making-bitcoin-more-private-with-cisa.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md diff --git a/bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md b/bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md new file mode 100644 index 000000000..dee1f3bcb --- /dev/null +++ b/bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md @@ -0,0 +1,8 @@ +--- +title: "Making Bitcoin More Private with CISA" +tags: ['cisa'] +media: https://www.youtube.com/watch?v=HvI7NPI_Pk0 +speakers: ['Craig Raw', 'Fabian Jahr', 'Jameson Lopp'] +summary: "Delve into the world of Cross-Input Signature Aggregation (CISA) with our expert panel from Sparrow Wallet, Bitcoin Core, and Casa. This discussion illuminates how CISA could revolutionize Bitcoin transactions by enhancing privacy and reducing fees. Uncover the technical aspects of half and full signature aggregation and understand their potential impact on the Bitcoin network." +needs: transcript +--- From 48b2350f0ba7d30790d6cd084f0efd0f912745e9 Mon Sep 17 00:00:00 2001 From: "ai-transcriber[bot]" <182107790+ai-transcriber[bot]@users.noreply.github.com> Date: Thu, 19 Sep 2024 13:00:57 +0000 Subject: [PATCH 5/5] ai(transcript): Making Bitcoin More Private with CISA (bitcoin-magazine/bitcoin-2024) --- .../making-bitcoin-more-private-with-cisa.md | 478 +++++++++++++++++- 1 file changed, 475 insertions(+), 3 deletions(-) diff --git a/bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md b/bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md index dee1f3bcb..bd3c9a733 100644 --- a/bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md +++ b/bitcoin-magazine/bitcoin-2024/making-bitcoin-more-private-with-cisa.md @@ -1,8 +1,480 @@ --- title: "Making Bitcoin More Private with CISA" -tags: ['cisa'] +transcript_by: kouloumos via tstbtc v1.0.0 --needs-review media: https://www.youtube.com/watch?v=HvI7NPI_Pk0 -speakers: ['Craig Raw', 'Fabian Jahr', 'Jameson Lopp'] +tags: ['cisa'] +speakers: ['Fabian Jahr', 'Jameson Lopp', 'Craig Raw'] +date: 2024-08-29 summary: "Delve into the world of Cross-Input Signature Aggregation (CISA) with our expert panel from Sparrow Wallet, Bitcoin Core, and Casa. This discussion illuminates how CISA could revolutionize Bitcoin transactions by enhancing privacy and reducing fees. Uncover the technical aspects of half and full signature aggregation and understand their potential impact on the Bitcoin network." -needs: transcript --- +Speaker 0: 00:00:02 + +Good morning. +My name is Aron Favirim. +I work for Bitcoin Magazine and this is the panel on Bitcoin Core development. +I'll let the panelists introduce themselves. +Let's start here with Eva. + +Speaker 1: 00:00:16 + +Hi, I'm Eva. +I am one of the Bitcoin Core maintainers. + +Speaker 2: 00:00:20 + +Hi I'm Merch, I work at Chaincode Labs on Bitcoin projects. + +Speaker 3: 00:00:25 + +Hi I'm Ishana, I'm a Bitcoin Core dev and I'm currently interning at MIT's DCI. + +Speaker 0: 00:00:31 + +Alright so let's start off with a recent topic. +So there was recently, there's a new policy within Bitcoin Core, there were security disclosures, right, Eva? +What's the story here? +What has changed about Bitcoin Core development? + +Speaker 1: 00:00:45 + +Yeah, We've historically done a poor job of disclosing security vulnerabilities. +So recently, a couple of contributors have taken it upon themselves to rectify that. +So we've established a new disclosure policy where we're tracking bugs better, assigning them severities and now we're going to be disclosing things generally two weeks after the last vulnerable version becomes end of life. +In the lead up to deploying that, we've started disclosing a lot of historical bugs. +What is end-of-life? +Yeah. +In Bitcoin Core, we support three major versions. +So right now that's 27, 26, and 25. +So after the next major version comes out, then the oldest one becomes end of life. +So in a few months, we'll have 28, which means that 25 point whatever will become end of life and no longer supported. +And at that time, we would disclose any issues that were present in 25. + +Speaker 0: 00:01:58 + +OK, so this is a new thing. +Merge, why is this new? +Why wasn't this happening before? + +Speaker 2: 00:02:05 + +Before, probably most of the security closures just happened whenever the discoverer got around to writing up a blog post or whatever. +And so some things got disclosed, especially the bigger, for example the inflation bug a lot of people have heard about shortly, but now there was a backlog of some things that we knew about that hadn't been perhaps presented in any formal way yet. + +## Remembering the Past and Discovering Cisa + +Speaker 2: 00:02:34 + +So there's blog posts on BitcoinCore.org now that, well pretty short just disclosures on what vulnerabilities existed in older versions. +And I think one of the main things here is we're trying to tell, to make it clear that just because you hadn't heard about some vulnerabilities in Bitcoin Core before, it's not that it's bug-free software. +Stuff happens, it gets fixed, so we want to make a bigger, better job of, do a better job of disclosing and keeping track of that. +So everything up to 0.21 has been disclosed now. +I think end of this month, there will be some disclosures for 22. +So At the end of this month, +there will be some disclosures for 22? + +Speaker 1: 00:03:19 + +So this month, at the end of this month, we'll have a couple more disclosures for things that were in 22. +Next month, it'll be 23, month after 24, and then 25 should be around when we release the 28 release. +So we will now be in sync with the policy that we established. + +Speaker 0: 00:03:39 + +Maybe this is a stupid question, but real quick, what is the practical benefit of this? +Why do this at all? + +Speaker 2: 00:03:47 + +In a way, so one problem is if there's undisclosed security vulnerabilities that people are aware of, attackers might have an edge. +So it's preferable that everybody knows. +Another one is that by documenting what has happened and how it was fixed, we retain the knowledge, we also teach maybe related projects what they should be looking at. +There is a ton of forked coins from Bitcoin, some of which have not very active development and well, they might want to know about these issues and fix them. + +Speaker 0: 00:04:26 + +Ishana, you are a relatively new Bitcoin Core developer, right? +What's your experience starting out as a Bitcoin Core developer and what kind of advice would you have for other people who might be interested in doing that? + +Speaker 3: 00:04:39 + +Yeah, so I started Bitcoin Core development almost like a few years ago And I think that the main advice I'd have is, well of course you need a strong understanding of fundamentals. +And I think that Chaincode Labs has a really good Bitcoin protocol development seminar that gave me good fundamentals. +But I think that people should... + +Speaker 0: 00:05:01 + +Did you do that seminar? +Did you do that seminar? +Yeah. + +Speaker 3: 00:05:04 + +And so it's great to talk to people about these concepts, but also I wouldn't be too hesitant with trying to contribute. + +## Cross Input Signature Aggregation + +Speaker 3: 00:05:13 + +There's a ton of good first issues and small PRs that you can open. +And people are generally very helpful and will review and super supportive of new contributors. + +Speaker 0: 00:05:24 + +Right. +If you get started, so you would recommend this Chaincode course, But at that point, is that open for anyone or how do you even get in there? + +Speaker 3: 00:05:35 + +Yes, so the resources are on the website and anybody can use them. +And then they also do seminars, which are like where you read the resources and then you meet with people and discuss them. + +Speaker 2: 00:05:46 + +Right. +Yeah, so we have a course that you can do self-paced. +It's a bunch of resources. +It's a lot of talks and reading material and articles. +So if you want to go for it in your own pace, all of that is linked on learning.chaincode.com We did these Bitcoin developer seminars and lightning developer seminars that were five-week programs and we had earlier this year the big fast program with I think over 600 participants. + +Speaker 0: 00:06:20 + +Okay, this maybe ties in a little bit but like, well I want to ask kind of why would someone want to become a Bitcoin Core Developer? +That's a good question in itself. +And tying in, what's the status of funding Bitcoin Core Developers? +Because many Bitcoin Core Developers do get paid in some way or another, so what's the status of that? +Maybe, Do you want to start? + +Speaker 2: 00:06:46 + +I'll start quickly. +I was just thinking of that Shackleton ad, fearless men, there's danger of death and whatever. +And no, so it can be pretty rough. +Like there's been a bunch of legal harassment over the years. +Funding was uncertain at times. +Sometimes if you're working on stuff that's not super interesting to a lot of people, it can take a while to get review. +It is, I mean, inherently any group of at least two people has social dynamics. +So if you find a few people that you get along with and collaborate with them, you might have a great experience if you're working on something that only interests you or you don't find your folk, then it might be a little more isolated. +So a good thing is maybe to pick something that you're really excited about, that you have drive for, because if you scratch your own itch, you tend to not lose your motivation as easily, and if you're more excited about something you tend to infect others with that. + +## Various Approaches to Signature Aggregation + +Speaker 0: 00:07:50 + +And when it comes to funding specifically, who's funding Bitcoin Core Development and what's the status of that? +How do you get funded as a Bitcoin Core Developer? + +Speaker 1: 00:08:00 + +So mainly the funding situation right now is grants. +So there's nonprofits like Brink, OpenSats, and there are companies like Spiral, who provide grants to developers to continue to work on features and projects and open source stuff. +That's mainly how newer contributors get funding. +Sometimes, if you're really lucky, a company will hire you to continue working on open source. +So that's what I do at Blockstream. +But yeah, generally, the funding situation is a little difficult. +But the grants are the main way that people get money. + +Speaker 2: 00:08:47 + +There's also a little bit of an entry hurdle. +Because even if you're an established developer in other fields, if you're not known in the community, it can be difficult to get a grant immediately. +So often, people start out by working on stuff in their free time or by taking off a month and interning somewhere and working on a specific project to get a notch in their belt. +I think that's sort of what we tried to do with the FOSS program at Chaincode earlier this year was to create a space where people could focus on doing a bunch of different little Bitcoin things for a few months and we actually got a few full-time contributors out of that now, But yeah, you really have to sort of invest a little upfront before you become eligible for grants. + +Speaker 0: 00:09:41 + +Ishana, is this all your experience? +Do you have anything to add? + +Speaker 3: 00:09:45 + +Yeah, so I've not like received any grants yet, but what I think makes Bitcoin very unique is that in other places you can just get hired or get grants before you do this work, but sort of like what Mertj was saying, I think proof of work is a really big thing in Bitcoin and so you do need to show that you're capable of doing the work in advance. + +## Incentivizing Participation in Coin Joins + +Speaker 0: 00:10:07 + +Yeah, and Mert you briefly mentioned the legal issues there, specifically Greg Wright's lawsuits I guess. +In general how big of a, well that lawsuit is over fortunately, but in general how big of a problem is this for Bitcoin Core development? +Like, it must be at least some deterrence. +Do you think it has affected Bitcoin Core development? + +Speaker 2: 00:10:28 + +I think it had a huge chilling effect for a while. +I know that of some people that specifically stepped out of Bitcoin contributions due to this legal precedent or not precedent but like situation. +I think what really helped was that a few people stepped up and just started taking care of it. +Started donating a ton of money and their time and organizing the Bitcoin Defense Legal Fund. +But yeah, it's not necessarily for the faint of heart. + +Speaker 0: 00:11:12 + +Yeah, so what is, I mean, how do you move forward from here? +You mentioned rich people just sort of take care of it. +Is that the solution here, Eva? + +Speaker 1: 00:11:22 + +I mean like traditionally as much as we hate it is that... + +Speaker 0: 00:11:26 + +And by the way you were one of the people that was being sued, right? + +Speaker 1: 00:11:31 + +No, I was not. +Oh. I don't want to get into it. + +Speaker 0: 00:11:34 + +Okay, okay. + +Speaker 1: 00:11:36 + +But I know a bit more about the lawsuit. +But I mean, traditionally in Bitcoin, it is just the rich people are taking care of us. +You see how much money that Jack donates. +And I believe Jack was one of the main people who helped out in the defense fund. +So that is unfortunately how it is currently. +But ideally, people and companies that use Bitcoin, rely on Bitcoin, would contribute monetarily if not, like, I guess for legal stuff definitely contribute monetarily and helping us with lawyers. +It's just unfortunate that that's how it has to be or that's how it is. + +## Privacy Tools and Cost Savings in Bitcoin Transactions + +Speaker 0: 00:12:23 + +Okay, last question on the funding. +One of the concerns that some people have is that funding could also influence Bitcoin Core development. +For example, funding from ETFs could push Bitcoin Core developments in a certain direction. +Is this, in your view, a valid concern? +Shana, do you want to take it? + +Speaker 3: 00:12:43 + +Yeah, so I think that people are generally conscious of not having, like, not employing too many Bitcoin Core developers or one organization giving grants to too many developers or maintainers. +But the thing is that, like, if for example an ETF does fund one Bitcoin Core developer, that doesn't, like, that's, They can't convince them to directly impact anything very big protocol-wise, because then that developer would have to go convince other people as well. +So yeah, I think that it does make sense to be thinking about what could influence a developer. +I think that sometimes the concern is kind of blown up a bit. + +Speaker 2: 00:13:27 + +I would hope that if they make a contract like that, that they very clearly specify in the contract what sort of influence they intend to have on the developer's choice of work items. +Generally, I think if that situation is not very clear and people feel that the developer would be influenced heavily, they might have a harder stance convincing others that their ideas or projects are good or unbiased. +But for the most part, I would say that anyone in the ecosystem that has big impact, pushes around a lot of money, I would be happy if they have some sort of representation to take part in the conversation. +Because it's a two-way street. +If they have some developers that are involved in the development community, they'll learn about the developer concerns and it will flow back to the ETF or exchange or whatever as well. +And if the exchange or ETF has some concerns, those will be heard. +And right now, sometimes it feels that certain areas of the ecosystem are heavily dependent on how everything works, but sort of isolated from the communication. +So I'd actually be for it. + +Speaker 0: 00:14:48 + +Yvan, anything to add? + +## Pushback and Perceptions of Soft Forks + +Speaker 1: 00:14:49 + +Yeah, I think having a diversity in funding sources is actually really important. +As I mentioned earlier, a lot of funding was kind of coming from Jack in general. +So having more diverse funding so that if Jack gets bored or he gets hit by a bus or whatever, that we aren't suddenly all out of work or, I guess, out of money. +So I think it's fine that for ETFs, mining companies, exchanges, whatever, to have a couple Bitcoin Core developers on their payroll, As long as it's not one, and this applies also to the nonprofits, as long as it's not one organization that has everyone, I think that's fine. + +Speaker 0: 00:15:41 + +So this ties in a little bit. +How hard or easy is it to get new futures in Bitcoin Core currently? +Some people would argue the bar is too high, Bitcoin doesn't sort of progress, or Bitcoin Core doesn't really progress, it's too hard to get anything new in Bitcoin Core. +Shall we start? +Yeah, Ava, we'll start with you. + +Speaker 1: 00:16:03 + +AVA GILBERT-LUKASIAKOVSKYI Well, it depends on the feature, right? +Like, there are things that don't affect users, that don't affect the rest of the network. +Like, There's a bunch of major-ish back-end changes, for example, the Bitcoin Core Wallet that we've been making. +And these can have a lower and other less impactful changes. +Can still be very important, but have a lower threshold for review. +On the other hand, we have things like consensus. +Consensus changes have a very high threshold, And it's not just the developers who decide consensus changes. +It's the entire community. +And a big part about evaluating consensus changes is seeing whether everyone else in the community, whether there's consensus for it. +What's the name? + +Speaker 2: 00:17:01 + +I think that a lot of people in this context conflate Bitcoin Core development and protocol development. +I think they overlap heavily and traditionally a lot of the changes in protocol development have been proposed by people that were also Bitcoin Core contributors. + +## The Limited Potential of Signature Compression + +Speaker 2: 00:17:20 + +But even while there's big overlap, simply because some of the people that have been working on Bitcoin the longest are still contributing to Bitcoin Core, there are separate topics. +And one, like, concerns of what exactly should be in Bitcoin Core are much more driven by the individual contributors whereas of course protocol development is a community conversation. +I am very happy that the BIPS repository is moving a little faster again. +I think that is sort of one of these focal points where we can move stuff and exchange ideas in a comprehensive and comprehensible manner. +The mailing list is live. +Some people lost track of it when it moved. +The mailing list is getting more traffic again. +And so, like these traditional points where that conversation happened are alive and well and maybe should be considered again as points where people keep at least part of that conversation. +Obviously, everybody can talk wherever they want on Twitter, on meetups, at conferences, or whatever. +But please be sure to keep the bigger summaries and the write-ups in a place where we can find them again, where we can index them, where the community will notice that the conversation is happening. + +Speaker 0: 00:18:46 + +Real quick then, you say Bitcoin Core development and protocol development aren't exactly the same thing. +Do you think it's plausible at all that we could see a protocol upgrade happen outside of Bitcoin Core? + +Speaker 1: 00:19:00 + +So, + +Speaker 2: 00:19:05 + +I think it's not impossible. +The ecosystem has grown a ton since we've had a lot of protocol upgrades. +As I said originally, a lot of that overlapped even more because there was just no other game in town at all. +But now there is more different Bitcoin implementations. +There's people that have some concerns that are maybe not championed by Bitcoin Core contributors very well. +So if they were to, say, create an activation client, and it turns out that a huge amount of the community is excited about this and running it, then I don't see why it couldn't happen that someone else is the driver of it. + +## Signature Aggregation and Getting Involved + +Speaker 2: 00:19:48 + +I would still ask, though, that just so we actually can get a sense of whether there is rough consensus, people actually approach the whole community and some of the places that everybody tends to look at and see is like the mailing list and the BIPs repository. + +Speaker 1: 00:20:08 + +I also want to add like if something if there appears to be community consensus for something there's also a good chance that people who work on Bitcoin Core will also think it's a good idea and want to then implement it in Bitcoin Core. +They may not be the champions of it but that doesn't mean that Bitcoin Core won't have that feature in the future. + +Speaker 0: 00:20:31 + +Ishana, anything to add on getting futures into Bitcoin Core? + +Speaker 3: 00:20:36 + +Yeah, so, well, we just talked a bit about Bitcoin Protocol, but I think in terms of Bitcoin Core especially, it is important and sometimes like newer contributors have to learn to advocate for their own work, to get review. +And in terms of just like reviewing PRs, because that is how features get merged, it's important to be reviewing other people's PRs if you want people to review your own. + +Speaker 0: 00:20:58 + +So it's, yeah, it definitely, I think advocating for your own contributions So there are also people that say Bitcoin should actually ossify as soon as possible Bitcoin core development is maybe even sort of considered a risk in a sense Now this might be a bit of a biased panel in that regard, but I still want to hear your opinion. +So what are your thoughts on ossification? +Is that good, bad, possible, impossible? +Let's go the other way. +Do you want to take it first? +Yeah, Ishana, let's start with you this time. + +Speaker 3: 00:21:32 + +I think it definitely depends on the kind of ossification that you're talking about, because some people are talking about the Bitcoin protocol and some people are talking about Bitcoin Core, and I think that it's important to distinguish the two, because with the Bitcoin protocol, I think, you know, that could be possible. +I haven't looked into exactly what that would mean. +I think that there are unsolved problems, so we might not want to do that just yet. +In terms of Bitcoin Core, it's important to keep maintaining it and I don't know for sure if we'll ever be able to ossify it because we do have to keep making sure we're up to date with dependencies and fixing vulnerabilities and things like that. + +Speaker 1: 00:22:12 + +Ava, anything to add? +Again what Ashana said, with Bitcoin Core itself, it is impossible to not keep making changes to Bitcoin Core because people keep finding bugs. +People keep finding vulnerabilities. +Software, operating systems change, and that necessitates updating Bitcoin core so that it can even like compile and run in the first place. +In terms of protocol, yeah, that could ossify. +There are like time bombs in the protocol though. +Like there are there are things that will stop working in a couple hundred years and those will need to be changed if we want Bitcoin to still work. +So even then the protocol can't really ossify currently. + +Speaker 2: 00:23:01 + +Yeah I feel that often the cry for ossification is a little motivated by concerns about features people don't like or don't understand. +And I don't think that it really, usually it's not the most productive conversation. +I think that in general we are doing pretty well for, let me take that from a different angle. +If you look at how other internet applications have evolved over the last 20 years, we will find other ways in which we want to scale. +If we want to scale to have Bitcoin be usable by the entire population of the planet, we certainly have to make some amendments and changes. +I think we are reasonably conservative and that it is necessary for people to really convince the rest of the community that something is a good idea, but we definitely will need to make more improvements if we want this to actually fulfill the vision that there's digital cash for everyone on the planet. + +Speaker 0: 00:24:12 + +Okay, well this will be the last question. +What are the priorities of Bitcoin, or the priority, or how are these determined? +How does Bitcoin Core maybe differentiate itself from other implementations? +Like what is the focus and the priority of Bitcoin Core? +Let's, Shana, do you want to start? + +Speaker 3: 00:24:32 + +Yeah, so do you mean like of the developers or the project in general? + +Speaker 0: 00:24:36 + +What's the difference? + +Speaker 3: 00:24:39 + +Yeah, well, in terms of just developers, I think that because there's so many, and there's no sort of like, I mean, the whole point is that it's decentralized and anyone can contribute. +So I think that everybody has different priorities. +I think that a lot of people are just trying to, you know, improve things, fix bugs. +There are also people who just like show up to the repository and try to get their own stuff merged really quickly and then leave. +But yeah, I think that everybody has different priorities. +So it depends on what your interest is and what sort of changes you want to make. + +Speaker 2: 00:25:15 + +Marc? +Yeah, I think that Bitcoin Core really is different from many other projects in the regard that there is not a founder that has a lot of sway, or sure, there's some members that have been around for, or contributors that have been around for a very long time. +But for the most part, things just organically happen. +Someone has an interesting project, others are also excited about it. +There's maybe a working group, four or five people, and then things start moving. +So if there's important issues, that tends to motivate. +If there's cool new stuff that provides us benefits, that tends to motivate. +We recently introduced priority projects into the Bitcoin Core. +Actually, you should talk about that. + +Speaker 1: 00:26:05 + +Yeah, okay. +I do want to first start out with, it's important to remember that Bitcoin core is not a monolith. +The maintainers are not a monolith. +It's not like everyone thinks the same thing. +There are many differing opinions. +So the priorities are whatever the contributors, every individual contributor, like, wants to happen. +And then they can spend the time, spend time convincing other contributors that their priorities should also match because it's a good idea. +So that is, as Merch just mentioned, this priority project things. +But even then, it's not like things that the entire project prioritizes. +It's things that most people in the project think are good ideas and want to spend time focusing on. +And so this, for the past couple of months, that's been package relay, cluster mempool, and removing the legacy wallet. +But even then, even though these are priorities, not everyone is working on those. +People still do their own things. +They do whatever the hell they want. +And there's just maybe a little bit more focus on that from people, especially people when they find that they have downtime and don't know what else to look at next. + +Speaker 0: 00:27:23 + +Did you have a last word, Murch? + +Speaker 2: 00:27:26 + +I just wanted to clarify. +So the way the project comes up with priority projects is someone proposes that something should be a priority, and then there's a number of other people that are saying, I'll contribute review to that. +And that's why we talk about it in our weekly meeting. +It's not like we've voted and said, oh, we should work on this, or someone decided. +It's just enough people are working on it that it becomes a permanent item on our weekly meeting. + +Speaker 0: 00:27:55 + +Got it. +All right, that's our time. +So everyone, thanks for being here. +Give a hand to our panelists. +And enjoy the rest of the conference. +Thanks for having us. + +Speaker 2: 00:28:04 + +Thank you. + +Speaker 3: 00:28:30 + +You you