0:00 Let's continue the conversation. 0:03 Someone actually had requested. 0:05 I didn't notice. 0:07 To speak in the last one. 0:12 I think I can invite people. 0:14 I don't remember. 0:44 Yeah, we did go for a while. 1:00 It is too bad that it got interrupted, but we had gone for a while. 1:05 If anyone wants to say anything, then request to speak. 1:14 But it wouldn't be the worst thing in the world if we did end it. 1:25 Let's take a look. 1:27 Let's take a look. 1:57 What was the last thing we said? 2:09 I don't even know. 2:10 I was saying there's a risk. 2:12 There's always risk. 2:13 There's risk to inaction. 2:14 Let's see. 2:18 We had someone else who wants to speak. 2:19 Yes. 2:26 I'm just saying you can't get out of it by saying, wait, wait, wait. 2:30 We should be careful. 2:32 Because that is also risky. 2:36 That is not a real thought in my point of view. 2:42 Well, when you bring the time element in, it can be. 2:46 Because if we aren't facing that risk and urgency right now, and maybe it ramps up over time, then it can meet a point where then it makes sense to seriously look at drive-sharing. 3:02 I'm saying as a general principle, though. 3:04 I'm just saying because you can imagine a situation where you did face such a thing, such a situation where urgency wasn't. 3:15 Like if someone bursts into the room and says, oh, my gosh, this whole city is burning down. 3:19 We need to run for our lives. 3:22 Well, in that case, you're actually happy that the person is causing you to panic or whatever. 3:30 I'm saying as a matter of principle, it's not automatically the case. 3:34 The urgency has to co-vary with whether or not there actually is an actual imminent problem, which is very hard to know. 3:44 Anyway, Soshi and Joyer, we'll go back to Dune Moon, of course. 3:48 But Soshi and Joyer did raise his hand. 3:51 Hey, what's up, guys? 3:53 Thanks for bringing me up and thanks for continuing the space. 3:56 I just wanted to add to the conversation about immediate demand and aggregate demand and why potentially people might say there hasn't been demand for so many years. 4:06 Why now? 4:08 But from another point of view, I would say that there's actually a lot of demand because you can see that people that might have had demand for other type of protocols or other type of protocol design, they already go to other chains. 4:22 So you can see that just from this point of view, there's a lot of demand for an EVM style chain because they actually have a lot of users. 4:29 So you can actually say that in a way that's actually demand for a Drivechain that has EVM or a chain that has a bigger block size. 4:37 There's definitely demand for that, too. 4:39 So to say that over time there might be aggregate demand, you might also say that over time that demand is going to be very hard to upkeep because those people will leave and then their incentive to come back is really not that strong anymore. 4:51 So that point of view of why there's so many years is not demand. 4:55 You can say that that demand actually leaves and there's no reason for it to even want to look back anymore because you solved their use case in a different protocol. 5:03 So I just wanted to give that point of view. 5:05 Yeah, I completely agree. 5:07 I think it would have been better to do it, much better to do it back in 2015. 5:12 If someone has a thing, like almost all the altcoiners, there's many scammer altcoiners, but there are many that are pure of heart actually. 5:20 And Vitalik was co-founder of Bitcoin Magazine, the company that does the big Bitcoin events. 5:30 Vitalik was a co-founder. 5:33 And Roger was very sincere in caring about Bitcoin. 5:38 A lot of these people are very sincere. 5:39 They try to do their thing on Bitcoin and then they leave and they can't. 5:43 And so, oh, hello. 5:48 So, hello. 5:53 Ladies and gentlemen, Mr. Adam Back. 5:55 Hello, just sort of follow up. Keep going. 5:58 OK, I was saying that I was repeating something that I said to you in Amsterdam last year where I said these people bubble up and they want to do something in Bitcoin. 6:14 They want to do whatever their thing is, Namecoin or whatever, Ethereum type of a thing. 6:21 And then they can't and then they leave and they start their own coin. 6:26 And now kind of like they don't really want to come back because the last thing they want to do is after having been rejected by Bitcoin and then making it starting from scratch with their own altcoin and proving the use case out. 6:42 After they do that, then it's kind of an insult to go back to BTC as a sidechain and kind of lose what you worked hard to create with your own two hands in the altcoin world. 6:56 And so, yes, that was something Satoshi and Joyer was kind of touching on, because Dune Moon was saying that possibly there's not very much demand for this, the idea of sidechains. 7:11 No, just right now, timing, that it isn't necessarily the existential change that we need in this moment. 7:18 And we have it. We have the idea of it. It's been fleshed out very well so far. 7:23 And we think that it's so well covered and all the third order effects are considered. 7:29 OK, well, it can have its time. It just doesn't seem like the aggregate emergent horde is moving towards it. 7:36 And that might be kind of belying and underlying truth that there isn't the urgent demand for it right in this moment. 7:44 Well, I mean, I think there's other factors too, right? 7:49 Like, there's some features required for Bitcoin to enable it, right? 7:56 Like a soft fork. And so I think that's the first hurdle. 8:01 For end users, they get motivated to use something when it's available and integrated and there's hardware wallet support and there's exchange ports and all this kind of stuff, right? 8:13 Which is the first technology has to exist, I think, in the life form with a soft fork. 8:20 I think that's the first hurdle is to figure out what path is going to make them available in Bitcoin, whether that's finding a poor man's Drivechain kind of idea with using covenants or some other technology that comes for other purposes. 8:38 By the way, I was just reading about, what's it called? Something on Rootstock, I think it's called like PowPeg. 8:47 Kind of interesting. You know about this before? 8:52 Yeah, I think I know a little about it. 8:56 It's like half Drivechain, half federated, and then it automatically transforms from one into the other over time or something, I think. 9:05 Well, they had something where there was a sort of, I don't know what it was called. 9:13 It's like half Drivechain, half federated, and then it automatically transforms from one into the other over time or something, I think. 9:21 Well, they had something where there was a sort of policy that was a mixture, right? 9:29 Or processing blocks, but not the peg. 9:33 I think they have implemented something where part of the threshold is HSM signers, functionaries. 9:44 They call them functionaries, it's the same as Liquid does. 9:47 And part of it is merge mining with the idea. 9:51 I've heard that discussed before, but they actually went and implemented it. 9:55 It's kind of interesting because they sort of harden each other a bit. 10:00 If the miners go crazy, even 100% of miners can't do something because there are some functionaries. 10:05 And if the functionaries go crazy, they don't have quite enough signatures to take the coins. 10:12 It gets the peg management policy without some minor collusion or something, right? 10:19 But the power peg thing seems to be newer. 10:23 And that is basically two parts to it. 10:30 The first part is the merge. 10:33 There are the functionaries of HSM that are signing blocks in a threshold, right? 10:39 And also sort of co-signing peg outs, right? 10:48 And of course the functionary code looks at the unit stock sidechain. 10:56 But the power peg part is that they added that the merge miners are going to... 11:04 I think they might have actually deployed it. 11:06 So the merge miners look at the sidechain. 11:11 And then they instruct the HSMs whether to sign or not based on hash rate. 11:17 So they kind of artificially have the merge miners decide. 11:21 But the HSM functionary block signers are still double checking it, right? 11:32 So they won't peg out unless the miners tell them to, the merge miners. 11:39 But they'll also reject what the merge miners are saying if it's not a valid peg out. 11:44 Like they can't see any evidence that this peg out is proven on chain. 11:49 So it's kind of an interesting addition to the mechanism. 11:59 Yeah, they had this... I don't remember a lot of it. 12:02 But Sergio wrote this post about it's very, very difficult to steal from it. 12:10 But it's more likely to hang or become delayed, which is a good thing, I think. 12:18 Well, I mean, I haven't quite understood the last part of it. 12:22 But one thing that occurs to me, because some users were jumping in and explaining the advantages of it. 12:32 And they were saying that the miners would prevent a theft 12:43 if the functionaries went rogue and colluded amongst themselves 12:50 and tried to take the peg coins without there being any peg out on the rootstock sidechain. 12:59 And so they were saying, well, the merge miners would stop them. 13:04 I was like, well, wait a minute, how are the merge miners going to stop anything? 13:07 These guys are just signing a valid transaction, sending it to the mainchain, and it'll get mined. 13:12 Then I was like, wait a minute, is there some kind of miner-activated softwalk we don't know about 13:17 that they're actually rejecting invalid rootstock peg outs, 13:24 the proportion of miners which merge mine it, which I think has been quite high at times. 13:30 But maybe they're just, if they are a rootstock merge miner, 13:37 they've added to the transaction validity test a test of any multisig that is a rootstock peg out, 13:47 but it has to be a valid rootstock peg out according to the rootstock sidechain, 13:52 or they're going to not add it to the mempool, something like that I'm guessing. 13:56 But it does mean that if there's enough miners, just some miner who is not a rootstock miner 14:03 could process it anyway, right? 14:05 The only way the rootstock merge miners could stop it is if they colluded to orphan the blocks 14:12 of any miner that makes an invalid rootstock peg out transaction, 14:19 which then becomes a consensus rule and could cause a fork or something, right? 14:23 I'm curious how it actually works now. 14:27 We were talking about that earlier in the other space, about if miners secretly activate a softwalk rule, 14:34 and you don't even know that the rule exists, how do you know that that's not happening all the time? 14:40 And in fact, you may remember I asked Matt Corral that exact question at Scaling 3. 14:46 I said, what if there was a mandatory extension block that was 8 terabytes or something, 14:51 but it was activated six months ago? 14:53 Paul, we talked about this in Miami recently, I remember. 14:56 And you'd find out as soon as somebody tried to do something about it. 14:59 I mean, if you use Drivechains, for example, and you put some money into a Drivechain, 15:03 and you were secretly running this fork, I mean, unless literally 100% somehow knew about it, 15:08 but nobody else did, which is weird to think about, but okay, hypothetically. 15:13 But in reality, somebody that's not a part of that group is going to know about it, 15:16 and they're going to see the money there, and they're going to try to take it. 15:18 And the only way to stop them is going to be to reorg, and then it's going to be obvious. 15:23 Well, it's a hypothetical edge case to make a kind of philosophical point. 15:32 So it's saying, if 100% of the miners secretly had activated some kind of rule, 15:40 then really there would be no blocks. 15:42 There would really not be any blocks mined ever that broke the rule, 15:46 and so maybe you would see transaction censorship. 15:50 Well, and you'd see transactions that didn't make sense. 15:53 Individual users would wonder why there were a bunch of coins sitting around 15:57 without any normal signatures on them. 16:01 Yeah, or like if you use opnop9 or something, they would be like, what is that? 16:07 Well, I mean, you could do... 16:10 I mean, if it was a conspiracy, you could do... 16:16 You know, they could share a seed or a wallet. 16:22 And so, you know, they're actually anyone can spend, 16:25 but they just look like a signed transaction, right? 16:30 And then there's more coins. 16:33 Yeah, the one that I had, the magic... 16:37 The hidden terabyte extension block is like you only put the hash in opreturn, 16:43 but it's mandatory on layer one, 16:46 and it also has many other rules that are inside the extension block that are mandatory. 16:51 But no one knows about them. 16:53 And so then in that case, no one really can see that something has happened. 16:57 They just see an opreturn. 16:59 Yeah, and that case is different. 17:01 It's a secret extension block because you're not actually storing any Bitcoin anywhere. 17:06 Yes. 17:09 I mean, I think... 17:12 Well, some Twitter threads about that during the week, 17:15 but you could make a similar argument about other uses of Bitcoin finality, 17:23 like timestamping or something. 17:27 There's OpenTimestamps and FidelityWall, 17:31 and they put checksums into the main chain. 17:37 Now, of course, they don't try to reorganize the chain if they disagree about it. 17:43 But I think where it gets... 17:49 You know, if it's actually... 17:53 The part where it gets tricky is if this hidden... 17:58 If the miner actuated soft fork is creating forks, 18:03 like systematically orphaning certain things based on rules you don't know about, right? 18:09 So that's not good. 18:11 Let's say the rules have bugs in and they mess the network up somehow 18:16 and then cause it to stop progressing or to fork. 18:21 But we see this as the point, though, of the soft fork, 18:24 is that the old node should be indifferent to whether or not the rules... 18:29 It should be indifferent to the bug, in a way. 18:31 Well, no, but I'm just saying one of the reasons that... 18:36 I mean, the normal upgrade approach for a soft fork... 18:42 I mean, you know, the miner-activated soft fork is a kind of, you know, 18:48 Bitcoin SV kind of concept. 18:54 And where they're just saying, well, you know, 18:59 only the miners matter, only the miners run nodes, 19:02 trust what the miners say, right? 19:05 And so for a normal soft fork, 19:10 the miners are just sort of helping coordinate transition, 19:15 and you could almost as easily use a flag day, right? 19:19 And so the procedure normally would be, you know, 19:23 get consensus for the soft fork upgrade, 19:26 then hopefully lots of high-value nodes upgrade, 19:32 like exchange nodes, wallet nodes, and things like that. 19:35 And once there's human coordination that that's happened, 19:42 then the miner start the signaling type of activation 19:50 to arrive at a coordination point where the miners 19:53 will start enforcing that consensus rule. 19:57 But that means that already... 20:00 So then, so from that point of view, you know, 20:03 because the point is that the miners are not enforcing the rules, 20:07 the economic full nodes are, 20:09 and the miners are just there to order transactions. 20:11 And they could literally, you know, mine random numbers, 20:14 but just the hash rate would go down, 20:16 and if it was invalid, we rejected by the nodes, right? 20:19 So it's really the case that the miners are just there 20:21 to order transactions. 20:22 And if you have a miner-activated soft fork, 20:27 it's not that people don't know about it, 20:29 they're not checking it, right? 20:30 So they would not... 20:34 And I think I could get quite confused 20:36 if there's a fork or something going on. 20:41 Yeah. 20:43 Well, you know, actually, I mean, I don't really agree, per se, 20:48 because, I mean, I think that this is a modern view 20:51 of the soft fork that has emerged ever since SecWit blockade. 20:57 But I tried to research back into the first usage 21:02 of soft and hard fork, and I found it. 21:04 And it was Gavin Andrews in 2012. 21:07 And he said there are soft changes and hard changes. 21:13 And he said there are some changes 21:16 where we have to get everyone to upgrade. 21:19 But he said that is basically, in 2012, 21:21 he said that is basically impossible now. 21:24 Yeah. 21:25 And he said a soft change is one where 21:27 we only need a few people to change. 21:30 So intriguingly, this definition of the soft fork, 21:35 those soft and hard changes later became soft and hard fork 21:38 when it became like a network split 21:40 would be something we had to upgrade 21:42 like the 8 megabyte Bitcoin Cash hard fork. 21:45 Yeah. 21:46 You must upgrade the software to be on the 21:51 quote, right, unquote, side of the chain. 21:55 And then the soft fork is just one where, 21:57 as long as 50% or 51% of the miners enforce the fork, 22:04 everyone will be on the same side. 22:07 So it really had nothing to do with even, 22:09 it was like we can activate. 22:11 But you see that this whole thing is completely at odds 22:15 with the idea of everyone agreeing on the soft fork. 22:18 Explicitly, we'll never get everyone to agree. 22:21 And so it's intriguing. 22:24 But it shouldn't be surprising because remember 22:26 who started the contentious hard fork drama, right? 22:31 Like Gavin was kind of a hierarchical mindset, 22:35 benevolent dictator for life kind of attitudes 22:39 and centralized thinking, right? 22:42 So that, but I mean like procedurally, 22:45 in terms of the planning that went in, 22:47 when people were coordinating with node operators 22:50 and figuring out, you know, is there enough deployment 22:56 to encourage the miners to upgrade and start signaling? 23:00 That's literally how it works, right? 23:02 And for those reasons, because if the miners activate 23:06 and nobody else has, they can unactivate. 23:08 And then you've got like, you know, something weird 23:12 like a technical hard fork where not enough people 23:15 are paying attention to know this or something, 23:17 you know, something where the consensus rules 23:19 aren't enforced by nodes or something, right? 23:21 Which is like not providing the normal Bitcoin 23:25 security model anymore. 23:27 So that's the way it actually works, right? 23:31 But it is a curiosity that technically it's true 23:34 that if the miners, you know, if a cabal of miners 23:38 did a secret miner activated soft fork, 23:41 you wouldn't be able to detect it at all. 23:43 Like they could have secret keys shared between the cabal 23:46 so you literally can't even see, you know, 23:49 their checksums or their extended data 23:51 that they're sharing on the side or something, right? 23:56 Well, yes. 23:59 I mean, all I'm trying to point out is that the soft fork as was, it was framed back in that year, which I'm not saying that that should be whatever I, who cares about that, but I'm just saying that, isn't it interesting? I'm saying, isn't it interesting that it's actually sort of the opposite now? I'm just remarking on that. 24:19 It's like a historical thing where it was considered a problem in 2012 that not everyone would upgrade. In fact, he's saying, I take it for granted, there is no consensus on anything among the humans. So what we can do is we have to release a new version that's compatible. 24:43 And then if there's ever a block mind that the old version was totally miner centric. So it said, if we have a fork where someone breaks the rule and someone follows the rule, as long as we have, you know, one active chain, one longest chain tip is, you know, block 3000A and 3000B. 25:07 3000A follows the rule, 3000B breaks the rule. The logic was, as long as more miners have, are mining the enforce the rule one, that one will always win. 25:20 Since it will always have the longest chain and therefore the feature will be safe, despite the fact that many people will not be upgrading to enforce it. 25:28 So I agree with you in general, but I just think it's very curious the way the criterion has sort of flipped completely and become, you must get the human, the criteria is almost the hard fork criterion because what Gavin was saying back then, and I'm not saying whatever, whatever about Gavin, but I'm saying that he's saying we can't get consensus. 25:48 We can't get everyone to agree to upgrade to this. If we could, we would do the hard fork or whatever, because as you know, he was, he thought the cost of that was much lower than certainly I think the cost is insurmountable, but it's kind of the same problem of hard forking and getting everyone to agree on the soft fork are kind of very similar because they both require agreement. 26:08 Well, I mean, I think the problem with a hard fork, you know, even if there is like agreement to do a type of upgrade that's a hard fork, the problem is the coordination is really difficult because, you know, there's lots of nodes that people won't get around to upgrading. 26:26 If you do a soft fork, you know, they kind of work in a degraded SPV security model, but they don't get like forked off the network or lose money or get bamboozled, right? Whereas with a hard fork, it would be a mess, right? And, you know, what you're saying about Gavin, I think just nobody else agreed with Gavin. 26:48 That's why, you know, eventually the hard fork, you know, the big block drama became, you know, part of the public discussion and then led to this succession of failed contentious hard forks. And, you know, in particular, I recall with one of them, I'm not sure if it was Classic or one of the other ones, he was specifically arguing, it's a kind of, it's a minor centralization. 27:18 So he's saying that two megabyte hard fork is fine. And it's not really a hard fork to clients, because clients SPV, and they couldn't tell the block size, you know, because they was looking at the headers. And the validation that a SPV client would do, wouldn't be able to tell the block size was over a megabyte. 27:44 Because it doesn't download the block generally, it's just verifying some basic things, right. So he seemed to view that as a feature that, you know, miners could just change the rules. And as long as the SPV clients would be bamboozled, that was great from his point of view. 28:02 But everybody else was horrendous and was like, Oh, no, we need we need like, to find some fix so the SPV clients can check that they're on the right chain. But actually, I think what tends to happen in the end is that there are much fewer SPV clients, people using like different types of clients now, or clients with SPVs cross checking with another server and stuff like that. And Electrum protocol, all that stuff. 28:32 I didn't know that. That's an interesting idea that the it is kind of interesting in a way that that is a kind of advantage that the SPV people don't have to quote, kind of a weird situation, but that's a very SPV centric. 28:45 Yeah, yeah. Well, basically, that was his mindset. So you know, what you were saying, the rest of what you're saying about how he was describing the coordination is more of the same, right? It's not 28:59 lamenting the inability to get all the coordination. 29:04 Yeah, I mean, it's just saying like, well, you know, he's not worried about centralization at all. Never was, right? So if we could simplify the engineering talk by saying, well, the miners will decide, you guys can stay SPV. And the miners can just minor activate soft fork everything. You can upgrade if you want, but it doesn't matter. 29:28 It doesn't matter if you have consensus or not, we'll do it. These are all things that like fed into hard fork drama, I'd say. But I don't, you know, any of the other frequent contributors would have agreed with any of that when he said it. 29:43 So I'm wondering if this is a proper way to look at it, if the miners can be thought of as like paid security guards by the economic full nodes. So if that's like a good way to look at it, that miners are really just like paid security guards to enforce certain rules by the economic full nodes, then if the if the miners added on added on their own secret rules, that the economic full nodes aren't really endorsing. 30:12 Then they can add those, they can remove those, but they're not really being enforced by economic full nodes. So they're kind of like irrelevant. And if they added some kind of rules that, for example, were against the economic full nodes, and then that chain became the longest weighted chain, I don't think that would really matter either. 30:32 Because in the end, miners would eventually capitulate to whatever the economic full nodes, their rules of consensus do, because miners will like they might mine a longer chain that's heavier. But if those Bitcoin are worthless to, you know, to the full to the economic full nodes, then eventually they would have to capitulate anyways. So from that point of view, it's the miners really don't have the power, it's the economic full nodes that have the power. And the miners are just enforcing what the economic full nodes say. 31:01 So then if you have some kind of, you know, minor activated soft fork of Drivechain, if the economic full nodes are not enforcing it, then it's kind of useless. Is that a proper way to look at it? 31:13 Well, I think it's pretty close. But I think you say, how do we know what it is that the economic nodes say? Weirdly, the miners are kind of a part of like a weird media format where we learn what that was in some extent. But I think the security guard analogy, I use that one all the time. I think that's very good. I think like, they are the security guards. 31:37 The secret eight terabyte extension block is like if the security guards may have machine guns and stuff, if they go off in their own little closet, and they have like a poker game, and it's its own rule, then yeah, probably it's pretty secure over there. A lot of other people don't know about it. So they're not harmed by it. They don't. So I think it's a pretty good analogy overall. 31:59 I do think BIP300 in particular is a very weird thing to have activate only by miners, because the whole point of BIP300 is to constrain the miners, and to make it easier for the miners and regular users to trust each other. So it doesn't work as well if the miners are the only ones. That analogy is sometimes used like a dog holding its own leash. It's like, well, I don't know what the point of that is. 32:27 But it's also the case that we were bringing it up for an important philosophical reason, which is this idea that if you don't upgrade to be enforcing the latest soft fork, then you are, quote, degraded, unquote, degraded to SPV. 32:47 Yeah, I think that's generically the case. 32:51 But the thing about that is, how do you know that you, like, are you degraded that way now, like from some other protocol, of which BIP300 version 25 is only the SPV version of something else? How do you actually know whether or not you've been degraded? And if you can't know, then is that real? Is that actually something? 33:17 I think the reason, you know, sometimes miners use, like, hacked up variants of Bitcoin Core or with things bolted onto it, because they are, you know, trying to optimize something or shortcut something or adding some weird feature for, like, I don't know, paid site injection of transactions and stuff. 33:41 There's a standard way to do that. But, you know, for whatever reason, they modify it. And, like, they're typically not, like, experienced Bitcoin developers, right? So occasionally stuff is, like, blown up because there's some unreviewed code that's dodgy and conflicts with each other or something. 34:00 And so, like, there's a Bit 66 hard fork, which was miners doing kind of dodgy stuff, shortcut verification and things. But I think, like, one of the things I would worry about, and there was discussion about this, because it's not quite clear what Rootstock has been doing at different times, and there's merge mining going on, right? 34:22 Whether there's actually any kind of not very talked about, I mean, not like a secret cabal, but just nobody really knows about it, if there is anything like that going on. 34:33 So one of the main things I would worry about with that is kind of similar to the extension block idea, which is that that's kind of an extension block that we don't know about. And the main risk that people don't like about extension blocks is, well, whatever code is running in this extension block could have accidental fork risk, you know? 34:52 Like, Bitcoin has had issues in the past where, you know, nodes on 32-bit machines could interpret certain transactions as valid, where 64-bit machines would consider them invalid. And then, boom, you know, you can construct a magic transaction and split the network in two, right? 35:11 And then, you know, you can construct a magic transaction and split the network in two, right? And then, boom, you know, you can construct a magic transaction and split the network in two, right? 35:36 So the question is, if somebody's, you know, put together a bunch of hidden extension block code, you're maybe more worried about them, like, forking the chain, right? And creating a problem than them doing something hidden, because you can't really tell if they're doing something hidden anyway. You just don't want to screw things up. So that's why you want to know, like, what people are doing, have a look at it, and, you know, have people review it first or something. 36:07 Well, I mean, so, but in that case, isn't there, there's a bunch of software that's running that does not know anything about the extension block. 36:17 Yeah. 36:18 And so, the new protocol would fork, and the old nodes would be indifferent to which fork, so they would just follow the heaviest rule. And it would be no different than, it would be reorg, of course, reorg is itself bad, but it wouldn't really split, right? 36:38 I mean, I suppose it's possible that it could like, and with stuff like appear to stop from the main chain's perspective, or, you know, keep bouncing backwards and forwards reorganizing itself, or I don't know, like, that's kind of weird, right? 37:01 Like, there are blocks in existence on two sides of the fork based on some rule that you don't know about, or it's gone haywire. 37:14 Well, from that point of view, would you just see whichever chain, I mean, because you don't know about any other rules that accept the rules you know about. So according to the rules you know, you would just see whichever chain is the heaviest, even if you see there's like, you know, potentially two chains going off. Like, you would just, whatever one is the heaviest, that would be your valid one, right? 37:32 Right, but let's say these are, you know, approximately equal hash rate, and they're both growing longer, but, you know, the fork point is quite deep, then, you know, that could have, you could have sort of, I don't know, you'd be switching backwards and forwards from these chains, like, all the time or something. 37:57 Just because the hash rate is split, not because it has anything to do with why it's split in the first place. 38:03 Right. But I mean, normally, 38:07 It just so happens it is. 38:08 I mean, what would that look like? A really long... 38:13 There'd be like one really juicy, there'd be one really juicy transaction fee, and there are two people who try to grab it, and then it would be split on who grabbed it. 38:24 Yeah, but maybe one pulling ahead and then the other pulling ahead and still fighting over the same fork. I mean, normally, the chain resolves because miners give up when they see the longer chain, right? 38:35 But here, they're, like, persistently trying to go after the same thing again and again, right? So they'll pull ahead. 38:42 They just assume that the other person is totally invalid. 38:45 Yeah, I mean, because that's what they're doing, because they've got some defect in their consensus logic and their hidden extension block, but for the rest of us, it would look odd, right? 38:57 Because you're like, well, why don't they stop? Like, that's clearly a longer chain. It's as if they can't see each other's blocks or something, right? 39:03 And they just keep mining these two parallel chains, and you keep flicking back and forth between them. 39:09 Depends on who's currently winning, right? 39:12 Well, I think that case, though, still is like they have an incentive to… 39:18 Like, you see what I mean? It's a lot like the July 2015 thing, where one of them is going to lose a ton of money because of the 100 block maturity rule or whatever. 39:27 So some people are losing a lot of money. 39:32 And yeah, I guess it's kind of intriguing. That is a case where the miners would prefer, if they're on the losing side, they would actually prefer that more nodes be like, I don't know, pulling the poor girl. 39:47 I guess miners know that they're messed up, though, right? Because they would just be like that 32 versus 64 bit previous bug, but things like that are… 40:03 It's quite fragile. It's quite easy to make by accident if you do anything of any complexity. 40:09 And there's very little… There's not enough independent review on it. Somebody just hacks a bunch of stuff up and does this, then I think something like that is more plausible to happen. 40:23 You just get two different chains, and the nodes each are rejecting and ignoring the other block because back at the fork point, there's a 32 versus 64 bit bug or something like that, right? 40:39 Well, of course. I mean the miners never wanted to be in this scenario, we could guess. And in July, the 2015 thing, they also didn't really know, right? Like they didn't know that they had… 40:53 Well, I mean they kind of triggered it because they were spied mining actually, right? So somebody spied mined on something invalid, and they just kept going. 41:02 I guess in that case, though, the miners thought that they… That was an interesting case because the miners put themselves on their own invalid network that only contained them, and everyone running a full node was not on it. 41:14 Right. 41:16 Including some people who… All the people who had it actually updated were not on that because they knew it was… The fork point was invalid. 41:28 Right. 41:30 And so the difference in this case would be the old nodes would be indifferent. I think what would happen would be, since it would never be an exact tie, the old nodes, if you were on the slight minority, you would notice that you would be getting… 41:52 At a certain point, you would ask… You would peer with the other full nodes. The other full nodes would say the longest chain is some completely different chain. And then I think the nodes would throw alerts and stuff like orphans and things. 42:06 Yeah, I think there were a few alert messages. 42:10 So they would get the alerts at least pretty soon. 42:13 Yeah. 42:14 Because at some point, all the miners on the minority chain, they'd peer with someone, and they would say, you're not on the longest chain at all. What are you guys crazy? 42:23 And then, you know, actually what would happen would be they would… Wouldn't they request? Their mining node on the minority chain would request, and they would think that the fork point block was invalid, and then they would ban each… Everyone would ban each other. Right? 42:38 Yeah, maybe. 42:40 Would they not? I think they… 42:42 Oh, they… 42:43 If the miner… 42:44 If people said you invalid blocks too much, you'd ban them, yeah. But then you'd actually get an even more split network. 42:50 Yeah, it would be very split in that case. And they would say… Because they would say… Let's say you have like a split into like the top row and the bottom row, based on something in an extension block. 43:01 You're in the bottom row, and it's only 48%. You know, it's not… The hash rate is there or something. 43:08 What would happen would be they'd peer with someone, and this person would say, oh no, you have a longer chain. They'd give that miner the top row. They'd check the very next block in the top row. It would break the extension block rules. 43:26 So then it would be this peer passed me an invalid block. It would depend on if they custom coded it to deal with this scenario or not, because then it would just be immediate, like 24-hour ban, I think. If someone says they have a thing and they pass an invalid block. 43:40 So then they would… The minority chain, I think, would get itself banned off the entire network immediately. And then, I don't know if that counts as a problem fixing itself. 43:53 That's the network of hidden extension block nodes, right? The general Bitcoin network thinks they're all valid but might disagree about the height of them with this. 44:07 Well, I don't think so. Well, maybe. Because what I'm saying… In my hypothetical example… 44:11 They wouldn't drop the block as invalid though because they don't know about the defective extension block issue, right? 44:19 Right. But what I'm suggesting is there's a mandatory 8TB extension block in every block. And so that has some kind of hash or something. That's some kind of hash code. 44:31 And so that is what they hand over. They say, here's this block. Unwittingly, they have no idea that they're going to hand over the hash code. The miners will then look for the extension, the mandatory extension block. 44:44 But they either won't find it or it will be invalid. And then they want to have some kind of custom way of getting this extension block amongst themselves. 44:53 Yeah. 44:54 So they would do that. They would check the extension block and then it would be invalid. And then they would say, this block is invalid. 45:02 Well, half of them… 45:03 Right? And then they would ban everyone. 45:05 I mean, half of them would… I mean, if it was in two halves, then those halves extension block miners would block each other on two halves of the network, right? Something like that. 45:20 I think they would. 45:21 Yes. But then they will know, right? They'll be like… 45:26 I mean, that's the normal behavior, right? So then they might just see the hash rate drop a bit. 45:36 Yeah. It would not be a good thing, though. 45:40 No. 45:41 But for average users, they would just still continue with the longest chain. And then the only people really getting hurt is the miners that forked off with less of a hash rate, right? 45:54 Those are the ones that would really get hurt. Because if you're broadcasting a transaction, it would eventually reach both miners. And it would eventually reach the miners that do have more hash rate. So your transaction would get included anyways. 46:08 Well, you'd have to hope desperately that it wasn't the case that someone tried to double spend during this time. Which you would hope that they would not. 46:18 Yeah. 46:19 If that were the case, then yes. But otherwise, they would be unaffected, which would be very funny. The only people who would be affected would be the 100 block maturity. 46:28 I mean, there would be some confusing artifact that you'd be able to see manually, right? Which is, there would be somebody progressing another fork over there, even though there's clearly a more work chain that they're not converging, right? 46:46 It's kind of like there's a network split, you know? Like they're selectively not seeing the blocks, but they're seeing the transactions or something. 47:01 Well, yeah, this is my other thought experiment, other than the mandatory 8 terabyte extension block is also, what if occasionally the miners enter an irrational psychological state, and they feel compelled to do a 10 block reorg? And this is just something that happens. It's like, you know, when the crescent moon happens or something, they must do it. 47:25 And that is also kind of saying we have all been degraded to SPV of a kind of mystical, unknowable full node. This is my pushing back slightly against this whole degraded SPV thing is like, is that it's kind of like I agree with it. I agree with the details of it. 47:47 But I think like, every what I'm saying is every protocol is SPV of some other protocol that we may not know. So every protocol at all, but you can label them all like Bitcoin Core 25, Bitcoin Core 22. All of them are SPV of something and full of themselves. 48:08 But they're in fact, they're SPV of an infinite number of variations, multiple variations of the protocol, right? So there's actually we're always in SPV mode of an infinite number of things. 48:18 But I mean, if those things are not getting any hash rate, then it's not really right. Because then they're hypothetical things. 48:25 But that sends my question about mandatory minor extension block or mandatory minor psychological desire to reorg. 48:35 Yeah. 48:37 Then this is putting the miners back in the driver's seat of the soft fork. 48:44 I don't think the mystical once in a year mandatory 10 block reorg works because it could go against the incentives of the miners. Because like, what purpose, what like economic gain do they have from doing that? 48:59 I think he's just saying they. 49:02 They're irrational. They're crazy and they don't mind losing money, but if you if you want to say that the miners act irrationally, wouldn't you say then like Bitcoin would be broken in general then? 49:10 Well, I don't agree that I'm just trying to take an edge case so that we can you know what I mean? Like when physicists say, well, what if it was a black hole that was spinning at rotating at the speed of light? Like what would happen? You know, I'm just trying to sketch out the edges so that if we sketch out the edges of the black hole, it's going to rotate at the speed of light. 49:28 So that if we sketch out the edges, then we should have like the interior, a decent glimpse of the interior. So this is what people are saying, which is that you must get consensus among everyone in the world to enforce your soft fork. 49:43 And then the miners upgrade to be compatible with that. And if you don't do that, then it is it is harming the full nodes. But I'm saying, if you if you can't really know that you've been harmed, then is that a real sentence? You know, is it a real harm? Because you don't know. 50:02 If they don't know they've been harmed, then they haven't been harmed. It's irrelevant. But you also don't get anything. It's also irrelevant for you. Because it's like, if you try to enforce anything meaningful, that's the only time it matters. 50:20 I mean, an example of an example of a kind of harm is, you know, miners started doing spy mining. I mean, people know what that is, like, to speed up the transition between when a new block arrives to save the time of having to actually verify it before they build on top of it. They were just 50:44 But do you think that's bad? I actually think that's a good thing. I think that's like an invention. 50:48 Well, I mean, it's not great, because they're not verifying blocks, right? 50:54 Remember, the full node, each of our full node is supposed to validate the block. And also they have they have an incentive to get it. Like they're, what they're doing is they have a, it's like they've invented a kind of thing that's like a speed boost or something where it, it instantly validates a block, but it has some failure rate, or something. It's like some special chip. 51:16 Yeah, I think it's just like their business decision. It's a business decision of theirs. And if they want, they take it or they don't. 51:24 But I mean, I'm just saying, it did have a cost though, because like, the BIP66 fork was pretty dangerous. 51:31 But that, what happened with the BIP66 fork was everyone who was running their own full node was completely unaffected. I guess if you ran an old node, ironically, you may have been reorg'd. It depends. 51:46 I mean, people could have lost money. If those miners had done that on purpose, they could have profited from it. I mean, they did it by accident. 51:54 Someone did a double spend. I remember on Reddit, someone said they did a double spend as a demonstration and then gave the money to whoever. 52:00 So someone could lose, right? 52:03 But that's from a reorg. And actually, I think that is covered by the whole fact that the miners who mined the longer chain and then had to go back, the longer invalid chain under BIP66, those miners lost all the money that they would have. That was just a clear mistake on their part. 52:24 So I kind of think it's still covered because the miners were not – this is actually, I think, a kind of a deeper part of what I'm saying, which is that – I think we're both saying in a way, which is the miners are trying to solve – the miners are trying to cost minimize. 52:43 They don't want the stale blocks. They don't want orphan blocks. So they want the block to propagate as quickly as possible. They don't want to wait. They want to move on to the next block. 52:54 So the spy mine is a very good way of describing it because they're saying – they have switched over, and I'm going to switch also. 53:03 But I think the lesson learned from the BIP66 is actually that spy mining is really good, but it has this – but make sure you have the full node validate the block. So it's like you switch over immediately, but have someone somewhere validate the block in the next 15, 16 seconds, and then go back and kill the block if it's invalid. 53:26 So I really see that as a victory of the nodes over the miners yet again. 53:30 Well, I mean, I think they fixed their code afterwards because it cost them money, and they could see it was bad, right? 53:39 But that's exactly the whole point is that it cost them money. Spy mining was saving them money, earning them money, but it had this – Satoshi and Joy said it's a business decision. It's a cost-benefit analysis. 53:51 And now they said this works really well. What can we do to minimize this cost of spy mining? And I think that they did do that. 53:59 Well, I think what they do is they do the spy mining, they mine an empty block, and then they validate the block in the meantime. If it turns out it wasn't valid, they change. 54:13 They start working against themselves or try to orphan their own block if they found one, and they start mining transaction fees. They switch to a new block that they construct from their pool. 54:30 Right. So actually that's why I say it's just that they're climbing the ladder of mining invention, just making mining work better, I think, every time. 54:39 Yeah. And I still think that mining a block without verifying it is… 54:46 Yes, but actually think about that though. You're really now – you're going ironically back into the SV philosophy because you're saying everyone will be trusting the miners. 54:58 No, I think what I'm saying is… 55:00 If no one trusts the miners, then the miners can mine whatever weird, invalid stuff they want. 55:04 But people – I mean, I guess the people that it hurts are the SPV users, actually. The full nodes are probably not going to be affected, right? 55:17 And it's probably going to be infrequent because there has to be a transition or something going on for it to blow up, but it's still – I mean, some people – it's an empty block as well, right? 55:30 I think it has to be basically, or they run the risk of having a conflict with a transaction that's in there that they don't know about. 55:37 Well, if you go full tilt spy mode where you just take the exact get block template from – you pass it through completely, then I would think that's the cleverest way to spy mine. 55:49 Because you say, I connect – I'm a pool. I'm whoever I am. I'm whatever. I'm whatever I am. I'm brains or something. I'm a pool. 55:58 And I mostly – I have my own node, but I also connect to the boundary. I connect to AntPool, and if AntPool switches over, they switch over from one block to something else, and they have the – whatever it is. 56:15 I can get the HashMerkle root or something. Then I just – I try to copy their get block template, and I just try to swap out the coinbase destination. 56:26 That would be the coolest thing to do, is copy the whole thing. I don't know if that's possible. But you know what I mean? Because you're thinking, AntPool knows what the first block was, so they know what to do in the next block, so I'll just copy them. 56:40 And then 15 or 16 seconds later, we're going to have the real thing. 56:43 I think they maybe don't give you enough API to swap it. I mean, I presume start on v2 does, because it's trying to help you choose your own block, but I think they just give you a hash or something. Like, here, mine this. 56:59 And therefore, you don't know enough to change the address, probably. You do need to know the Merkle path in order to modify. 57:10 So I guess you must get the Merkle path. They probably give the whole thing, but I don't actually know. 57:19 I think there was this idea. I gave it a name. I called it hipster mining, where instead of mining the empty block, the new block has come in. Instead of mining the empty block, what you do is, if the mempool is a certain depth, you go like eight megabytes deep, and you pull the lowest fees that you think it's very, very unlikely that any of these were in. 57:45 Yeah, I thought about that. 57:46 Very, very likely that any of these were in. 57:48 And also, sometimes the miners have transaction accelerators. It's not a guarantee, but there may be situations where they could have transactions that they're fairly sure were not broadcast or something. 58:04 I think they would have a better success rate just mining empty, because if you're going to end up finding a block of a transaction that was already included by mistake, it's just not worth it. 58:18 It depends. 58:19 So it depends on the fees versus the block subsidy, right? If the fees are really worth it, then you might, but if the block subsidy is way more, then you should mine. 58:26 You know what you could mine? Those stupid inscription things, right? Because those were done by- 58:37 Identified by one hand. 58:39 Yeah, but they were done by a miner agreement, right? So the miners were just charging them, because it wasn't a standard transaction rate. 58:49 If you have your own private transactions that wouldn't propagate through the network, then you could just add those at any time. 58:56 Yeah, but I'm saying those bigger scripters that built the whole block, they would like that anyway, because the miner itself was generating the transaction and asking the user to prepay the fees, like as a private agreement, right? 59:12 So there's no transaction replay risk. 59:20 Unless that user gave it to different mining pools, but they probably wouldn't. 59:25 But I'm saying that the miner itself, I think, might create a transaction. They just give them a JERF and a JPEG or whatever. 59:36 Usually I think they give them the raw transaction. 59:39 Then they could mess with them, possibly, yeah. 59:44 Plus, don't they have to flag exactly which Satoshi is the ordinal or whatever? 59:50 That's all done on the ordindexer side. So it's just a raw transaction that's given to them, from what I understand. 59:58 Yeah. 1:00:00 Yeah, but so it's like this idea of being reduced to SPV because you don't know about, you aren't enforcing the latest rule. I still philosophically, I do not wholeheartedly accept this. 1:00:21 Well, I mean, you could say if you accept the mainline view that economic full nodes are what defines consensus, and then if you are a soft fork or more behind that, then you are SPV to the global Bitcoin consensus rate. 1:00:44 And the miners are having to follow, generate blocks that are compatible with that, or they don't get paid. 1:00:53 Well, I'm not sure I buy all those completely because, I mean, think about it like this. 1:00:58 Earlier you were talking about how SPV, they wouldn't even know what the block size was. So that's like an extreme, that's like what I think of as SPV. 1:01:05 Yeah, I just mean like degraded. 1:01:08 But of course, we all know that like, if you would not be like, you know, you switch from Bitcoin core version 30 to 31, it's not like the block size will have changed and you'll still be, those old nodes will still know the block size, they'll still know about whatever, the CDSA signatures and all the things will be checked except for the one new thing. 1:01:32 I think the reason I would say you're SPV is because, you know, pick a soft fork like Schnorr signatures or, you know, one of the other things, but like, you know, to a node before the upgrade, it looks like an optro effectively, right? 1:01:59 And so if you are accepting things that you think are optro as valid, then the miners could collude and like make you believe you've got a ton of money in invalid blocks and other people would just like calmly ignore them, right? 1:02:16 So yeah, it is going to require burning hash rate to catch out some people, but it's plausible too, right? You know, you could have an exchange that accepts one confirmation. It doesn't upgrade their stuff very well. Some exchanges are not very good at upgrading. 1:02:31 And you could, you know, run enough hash rate to do it and then they would accept a phantom deposit which you convert to something else and take out. I mean SPV in that sense, right? And I think all SPVs are the same in the sense that, you know, it doesn't matter what it is, they would all be exploitable because you're going to accept something that was previously always true, right? 1:03:01 So you would accept something as true that is not according to the economic majority, right? 1:03:11 Well, yes. It's funny because normally the victim would be the person whose money is being taken, but that's not what you're saying in this case. It's the person who… 1:03:21 Steve, you know what I mean? Like you would take it out of… 1:03:52 And they say, oh great, you know, you've got one confirmation, now you can trade. You can trade it and take it out, right? And so I think that would absolutely work, yeah. 1:04:04 The interesting thing about that is that though it does require the miners to then re-org, like basically similar to a re-org. 1:04:13 Well, I mean that transaction, that whole block would be invalid to the rest of the network. So you'd be intentionally making an invalid block to target for a large fake transfer some people who didn't upgrade where you can convert them to money. 1:04:29 But what I'm saying is all this does is it prevents miners from needing to take the step of having a bunch of money to double spend. That's actually the only marginal value of the attack to the miners I think. 1:04:43 I may be mistaken though because I think I've never thought of this possibility before. But I think if the miners have a thousand BTC, they can deposit it at the exchange that uses one confirmation and then just re-org it out by just mining more blocks elsewhere, right? 1:05:00 Well, I mean I think the thing is you could, it's kind of like the Finney attack, right? Which is that you could rent 1% of hash rate until you get lucky and you get your invalid block that uses a bogus opt-true to move a bunch of money you have or don't have. 1:05:22 And that you don't have and do a fake deposit. But if you've got a re-org, now you've got to be really sure that you're going to overtake the network. You need to control comfortably more than 50% of the network, right? So it's a higher risk, more expensive thing. And you've got to have the money, right? 1:05:45 Well, I mean I guess. I'm saying something like the miners want to defraud this exchange that – I'm saying how much of the attack hinges on the fact that the exchange is a one confirmation exchange because the exchange is getting this money in. 1:06:03 And it's clearly – they have some kind of cost benefit in mind when they say, well, we only require one confirmation even though it's a big receipt. 1:06:17 So I'm saying a parallel world where there is no soft fork confusion because that's what we're talking about. It's like this soft fork degradation effect. 1:06:27 In a parallel world, they could just have the hundred. Instead of having 1,000 coins that are locked behind like an op-nop seven that no one knows about, they are 1,000 coins that actually the miners themselves have the key. 1:06:43 It's like pay to pubkey hash and they actually have the signature for. 1:06:47 So in that scenario, it's very, very similar. They spend 1,000. They find a block. Everyone else in the world sees this block as valid, but they go back and they rewrite it and they orphan the block. 1:07:03 And it's a reorg attack in that case. What I'm saying is you can translate this attack into a reorg attack, and the only difference is that the miners did not need to already have the 1,000 coins in their possession when they began the attack. 1:07:23 I think a reorg attack requires more hash rate though, right? 1:07:27 Okay, so you're saying you have only 1% of the hash rate. Yeah, I think maybe that could be the case. 1:07:40 I think you need to distinguish here rational actors of miners or irrational. Because once you start introducing that miners will act irrationally, then I think that consensus of Bitcoin or rules of Bitcoin kind of break. 1:07:56 But if you're going to say that all miners will act rationally, then you have to provide economic game theory for them to actually do this. Because you can say that them doing this will hurt the price of Bitcoin, hurt the price of their ASIC, so it's not a rational move for them to do. 1:08:09 Not to nip it too badly, but if miners start acting irrationally, I mean, miners are just service workers for the users who end up buying the coin they value, so users are going to pay for the coins that follow the rules that they want. 1:08:21 And if you're a miner mining some other client rules, then you're not getting paid by those people. 1:08:27 Well, this scenario is all following the rules of all nodes anyways, really, right? 1:08:33 I mean, I guess it's, I mean, it's sort of making invalid blocks so the other nodes don't care, they ignore it, right, in order to catch out and upgrade. 1:08:48 It's kind of like a free eclipse attack on the exchange because the exchange will process this block and then it will just immediately get blown off the network. 1:08:59 But I'm still trying to figure out to what extent does it actually benefit from the fact that you… 1:09:05 I mean, it's a lot cheaper, right, because the natural, I mean, everybody, no other miners will build on it, so it's like a pretty much throwaway invalid block. 1:09:16 And you could create one just by renting enough hash rate and waiting, you know, like 1% per day should do it. 1:09:23 And that is probably going to be cheaper and easier to achieve because you can rent hash rate, no problem, right? 1:09:33 But if you actually wanted to have very high assurance of being able to orphan a deposit, then you've got to muster like 50% of the hash rate, right? 1:09:45 But I guess you can construct other variants. 1:09:47 It's kind of silly anyway though because if you think about it… 1:09:52 Well, sorry. 1:09:54 I was going to say you can probably repair it, your version, to be effective, which is you deposit, you try to orphan, if you fail you withdraw again, right? 1:10:14 If you succeed, you withdraw. 1:10:18 And, you know, so you sort of, you don't lose because you just, you know, if you fail to do your reorg, you just withdraw the coin again. 1:10:35 No, I mean, of course it's going to, failing to do the reorg is going to cost you because you're running hash rate. 1:10:41 So you might have to, you know, do 1% of the hash rate for a day until you manage to do one reorg, right? 1:10:49 I think you need a lot of hash rate in every case because even in the case where you, from the point of view of the exchange's old node, you, it will see one block paying it. 1:11:04 But if you are not on the longest chain, that, I mean, what I'm trying to say is the old exchange node, it's open-minded to the new nodes that actually enforce the rule. 1:11:16 Oh, yeah. 1:11:18 It won't believe it for very long, right? 1:11:21 Right. 1:11:22 Yeah. 1:11:23 So actually you do need a, you need like 51% hash rate in a way or something. 1:11:27 Or you need an exchange that accepts one confirmation, which is why I used that example, right? 1:11:32 Yeah, which is why they don't really do that. 1:11:34 I mean some accept not very much because it's sort of competitive. 1:11:39 I can do three, I think. 1:11:41 But three is pretty different than one. 1:11:43 Yeah. 1:11:45 I think they probably cut it. Well, it's like it's the same thing as anything else. 1:11:50 Well, I mean, you can, I mean the exchange is just an example of how somebody could create mischief and still with it, right? 1:11:58 You know, there are scammers that would probably figure out a way to do something with it by persuading somebody, you know, to do something irreversible based on one confirmation, right? 1:12:10 But that's what I'm trying to say is, is it actually just a reorg attack? 1:12:17 Like if it's, does it just hinge on the confirmation logic? 1:12:21 You see what I mean? 1:12:23 I think it's the same, yeah. 1:12:25 I think it's the same basically as any reorg, even without like older nodes. 1:12:29 Yeah, I think the logic goes the same over there. 1:12:31 Because if I could just pin it all on the reorg thing, then I'm back in business with saying that there is no degradation because this is just like a fictional degradation that is unknowable. 1:12:43 Kind of. 1:12:45 Sort of what I'm thinking about. 1:12:47 See, because it's kind of like saying we will pay them, but then the old node, it's because the old node is indifferent that the old node will accept the longest chain that has a different conflicting history for that op true. 1:13:06 So that is exactly why it actually goes back to the Gavin Andreessen era definition where they are indifferent and then they will be following the miners. 1:13:18 So it is SPV in that sense, but it's the idea of if the miners are, this is because the whole, the question kind of is going in a couple of different circles and doubling back on itself. 1:13:30 Because the soft fork is saying you're indifferent between two rule sets. 1:13:36 But you're never indifferent on whether or not you follow the longest chain. 1:13:41 So it's kind of by definition, the soft fork is saying whichever majority hash rate pick is the longest chain. 1:13:52 And that is why I find it so curious that this definition is flipped around and has become something else. 1:13:59 Not that I'm, I don't complain about that. I actually think, I think it's fine for definitions to change or whatever. 1:14:05 I'm not trying to say the old definition can stand, but I am arguing that the old definition was a Gavin fork of people's views that everybody else immediately rejected. 1:14:19 Well, I think Gavin had a lot of views that people rejected. I agree with that. But I think this was the old understanding that you couldn't get everyone to upgrade. And so what you would do is you would release a new version where people were indifferent between following the rules or not. 1:14:41 And then it's exactly because of that fact that whichever chain the miners were on was the chain that everyone was on. And if the miners then upgraded, then the whole network upgraded. And that was, and I think that wasn't just Gavin, I think, but I don't know. 1:14:59 I'm not sure because I wasn't paying attention at the time. I wasn't using Bitcoin or reading IFC and stuff when some of these really old soft forks were done. 1:15:14 But you'd want to ask some of the developers that were active, like Luke Dasher or Greg Maxwell and people like that, how did that upgrade happen in practice? 1:15:30 Because the concept that they would try to talk to people running economic nodes and make sure they upgraded before they would ask miners to upgrade and then figure out an activation schedule, that was around since at least 2013 because I've heard people talking about it. 1:15:52 But it probably was around a few years before as well, right? And you're only talking about that kind of timeframe. When Gavin was talking about this, it was probably what, 2012 or something? 1:16:07 Yes. This idea of the soft and hard chain was 2012. And then it was October, I think, 2012 and someone made a big glossary. And because I was just researching the history of this idea. 1:16:20 But it's true that you're right that the soft fork miners were not seen necessarily as causing the soft fork to happen per se, so much as it was saying, this is the date at which we now know that enough other people have deported. 1:16:44 And it was kind of something like, when is the soft fork activated? Okay, when 95%, BIP-9 or whatever. And there were like in 2013, Gavin YOLO'd one or two of those. I think was it Pagescript Hash was just YOLO'd on a day or something? And that's why that's the one that is half broken or something. One of them has the extra… 1:17:10 That was a lesson in how not to reach technical consensus, that whole saga. 1:17:17 So rushed. And then we were stuck with that for a very long time. We sort of still are, because who uses Pagescript Hash? Maybe some people do, I'm sure people do, but I don't. I use the regular Cray multi-sync. So I don't know who's using… I'm still on the old… I'm still on the Gavin, the YOLO'd Gavin. 1:17:38 So which was the first soft fork Google searches jammed up with stupid contentious forks? 1:17:45 Oh, another table one. BitMEX Research has a table that is… I don't think I fully agree, but it's very good. Find the BitMEX Research. 1:17:52 But I'm not looking for network split type forks. I mean like soft fork upgrades. 1:17:58 The first planned soft fork was the block-hiding coinbase, I think. 1:18:04 Oh no, that's pretty late, I think. The search engine itself did a few, and in particular, my belief is that changing the longest chain to the heaviest chain is theoretically a hard fork, and it's also… the unknown is also theoretically a hard fork. 1:18:22 That is a hard fork. 1:18:24 We'll not follow that thing. 1:18:27 And then when would it have become problematic for the first time? I don't know, but definitely block… maybe it is block-hiding. I don't think so. I thought that was a different… 1:18:40 I'm not the one. BitMEX has a thing for the hard fork, though. 1:18:44 There's a cool table, and there was, I think, no duplicate transactions? When was that? I don't know, but I don't really remember. This is going to be funny, though. 1:18:53 Everyone will look it up on BitMEX and then laugh at us if we try that. 1:18:59 Yeah, I have the article already. I'll try to read it now. 1:19:04 Maybe I'll try to find something on BitMEX research. History of soft forks or something. 1:19:10 Well, Satoshi disabled the upper variant. 1:19:13 Oh yeah, that's it. 1:19:15 That will be a soft fork. 1:19:17 That is a hilarious mistake, right? It's like op fork the network. Oops. 1:19:24 If you just use it, you spontaneously fork the network. 1:19:28 It is a strange… it's a very strange one because it seems to imply that Satoshi wanted… Satoshi seems to have… I think he made a mistake. 1:19:44 But that part of it, I think he's thinking, oh, I can make it so that different versions will… it's kind of like a sidechaining kind of weird idea where we can have multiple interoperable versions somehow or something. 1:19:59 I think he didn't really quite think it through because it's like… 1:20:02 I mean, you're sure he wasn't just thinking, oh, let's make the version available on the stack in case someone wants to write a program using it. 1:20:09 Yeah, I guess that's probably what he thought. 1:20:11 That's probably what he thought. 1:20:13 He probably thought, well… I mean, he was really right, though, because he made all this stuff available and then he soft forked it all out. 1:20:19 He deleted it all, so he was right to do it. 1:20:22 And the one thing he missed, he didn't put the op nops. 1:20:25 He didn't actually… so it's kind of funny. 1:20:27 He had to put the op nops later. 1:20:29 Kind of an interesting… definitely an interesting… definitely a brilliant guy. 1:20:35 But yeah, that's kind of a funny… 1:20:38 Well, then there was that horrible bug with like op equal or something. 1:20:44 I don't know about that one. 1:20:45 Op return, maybe? 1:20:47 Op return called you to spend any… 1:20:49 Yeah, you could spend anyone else's coin. 1:20:51 No, that didn't work. 1:20:54 Yeah, that is the… if I read the table correctly, that was the first soft fork to disable the op return. 1:21:03 And what did op return do, like to just take any coin, basically? 1:21:09 It would just exit the script, as far as I understand. 1:21:13 It immediately… 1:21:15 Yeah, and if there's anything on the stack, it's true. 1:21:19 So that is… I'm not actually certain, but I think it's the modern usage of op return as something that you never… I think it's like accidental. 1:21:33 But then you reuse the code for something else, like embedding data, right? 1:21:38 But the original purpose was to just exit the script. 1:21:42 So if you just push a 1 to the stack and just exit immediately, then you could spend any output. 1:21:49 But the new purpose is embedding data, I suppose. 1:21:54 Yeah. 1:21:55 Bitmex research says that there was… it counted as soft fork when they disabled the 14 other… they disabled OP_CAT and disabled other things. 1:22:11 The sigops limit from 2010, they say that's a soft fork. 1:22:22 And the 1 megabyte block size limit, of course. 1:22:25 July 19th, 2010. 1:22:28 Okay. 1:22:30 But these aren't real soft forks. These aren't really anything. 1:22:33 Okay, this is… I'm so… you know, I was going to guess this, but I didn't guess it. Instead, I looked it up, and I wish that I had. 1:22:40 But the first soft fork that seems to be real is disabling any transaction having the same TXID, with the two exceptions. 1:22:50 That one is like in 2012. But it's not really an upgrade, but it's like a… it's a real thing. 1:22:57 Oh, and this one, pay to script hash is April 2012. And this is the… was it the YOLO? This is the YOLO'd one. 1:23:07 But it's 55% hash threshold. 1:23:11 Which… 1:23:13 Yeah, exactly. There's no threshold for that one. I think it also had some chain splits, if I'm not mistaken. 1:23:19 You are right. March 2013, it is BIP34, require the coinbase to include the block height. That is the first one to use the 95%, which I thought was… I think of as a normal soft fork. 1:23:32 Yeah. 1:23:34 Which no one else does now, but that's fine. 1:23:38 Well, I mean, some of the other ones, did they not have miner signaling, I'm guessing? 1:23:44 They did not… well, pay to script hash had 55% miner signaling, but there was something very funny happened where they kept moving the date because not enough miners had upgraded. So, it was a little… it was very ad hoc. 1:23:59 It was very ad hoc. 1:24:03 But then this 95% thing was supposed to be used by BIP66 and other things when… checkLockTimeVerify, relativeLockTimeCheckSequenceVerify. 1:24:16 So, I guess, despite the hidden extension block for experiment, it's going to be bad not to do things that way. You know, it's just like an experiment to explore the possibility and the security implications and stuff like that. 1:24:46 And maybe to use the argument, like, if you can't tell, then philosophically, should anybody care if disclosed things are done that way or something? 1:24:59 But presumably, the mainline way to do it is to, you know, either find consensus for the Drivechain codes to enable Drivechains and other things like it, 1:25:19 or to figure out a way to implement a Drivechain variant using an existing or new opcodes that are added for other purposes, like covenants, we were saying, might be able to do it, right? 1:25:35 Well, yes. I mean, I also said this at Scionic 3 when we were in that group. I was like, well, theoretically, if the software were released, then there would be no way of stopping miners from doing either a Drivechain or an extension block. 1:25:55 And so I was like, mulling that over also, like, what does that mean exactly? 1:26:04 Well, wasn't, I mean, BIP 148 and all that stuff, wasn't that related to this kind of concept? 1:26:18 Like, a user-activated soft fork was actually a sort of veto of a minor unilateral action, right? Do this or else you'll fork yourself off the network when you do that thing, kind of thing, right? Because it was public, and people didn't agree with it. 1:26:39 Yeah, I agree that, well, in that case, the miners, I think the miners kind of knew that they weren't doing the right thing, actually. I wonder if you agree with that or not. But I think that they kind of knew that they didn't really feel that SegWit was bad for Bitcoin, right? 1:26:55 They were just holding it hostage to try and get this other thing that someone told them they should want, that they believed. That's my interpretation. You know what I mean? It wasn't like they were thinking, if we put SegWit, then how interesting would it have been if instead they had said something like, SegWit is a block size increase from one to four megabytes, and we don't want to do that or something. 1:27:20 Yeah. 1:27:51 Yeah, for some reason. I mean, I don't think originally they cared either way. They just wanted Bitcoin developers to figure something out. But for some reason, it became fixated on, you know, it had to be a hard fork. Like, they would have taken a two megabyte hard fork or a two megabyte soft fork if they really wanted a hard fork, for no logical reason, right? 1:28:19 I don't know why. I've tried to figure that out. I think it's utterly perplexing, and I have tried very hard to figure out why that is. I think you and I have talked about it too before, which is that maybe it had something to do with what you just said about Gavin was saying. 1:28:34 Maybe the way BitPay or someone, one of these people has set up, is like their software would work. But that doesn't really make any sense, right? Because surely they just run the Bitcoin node, and then they have RPC access to it. So I don't know. I find that perplexing. I find it very strange. But I've been trying to figure that out too. 1:28:53 Why did they care so much about it being a hard fork? And especially why did miners care about it being a hard fork, where their power is reduced like minus 99.9%? Like, as I was just explaining, with the soft fork, they have an enormous ability to actually affect or disrupt the thing. With the hard fork, it doesn't make sense to me personally. I don't know why. I've tried to figure it out for a long time. 1:29:23 I find it one of the greatest mysteries in all of Bitcoin. Why did they do that? 1:29:53 Let's pivot Bitcoin into a bit more centralized sort of micropayments kind of system. And it was easier for them because they didn't have to like upgrade software. And you can see afterwards, like the people, companies that upgraded to SegWit, and even, you know, the people that wanted the big blocks were the last to use them via SegWit, to put it that way, right? 1:30:23 Well, I find it, as I mentioned a couple times, I find it absolutely fascinating that in December 2015, at Scaling 2, the miners seemed clearly not to care at all one bit. Anyone can go and watch the miner stage or whatever from Scaling 2, and the miners clearly have, first of all, no idea what any of the issues are or what they're talking about, but they're very innocent in a way. 1:30:47 And they also are very annoyed that no one is telling them what to do. Someone literally says at some point, can someone just tell us what to do? Someone literally says that like exact sentence. And so that is a very peculiar thing. I've wondered about that a lot. 1:31:02 And I actually, I think the only explanation is that the people pushing for a hard fork didn't really know the difference between, they didn't know all the differences between this hard and soft fork, because I think if they had a more fully informed choice, they would have gone with the soft fork extension block or whatever that JJ was doing from Perth, right? That was like their one shot KO of just instantly winning the block size block, which they never took. 1:31:29 Baffling. A baffling decision. 1:31:32 Right. One of the things that sort of rapidly changed their minds about the desirability of a hard fork, not long after that, was Ethereum actually had one. The DAO rollback. And they thought that was really scary and didn't want to see that happen in Bitcoin. 1:31:56 Yeah, that was minus 60% of the Ethereum price in like a single day or something funny like that. And then the thing they remember, Emman Goodsire had that way of sort of fixing it with a soft fork, but that also broke. So they were going to drain the attacker's money, but then that also led to a fork. And they had a fun 30 days of just kind of chaotic nonsense. 1:32:19 Yeah, that was fun. Slocket. 1:32:22 Oh man, Slocket. 1:32:24 Slocket. 1:32:26 This is the Ethereum bike lock. Just babbling in so many ways. 1:32:35 Yeah, that was fun. That was a fun month or whatever that was. That was really weird. And I think that was the Ethereum peak in terms of like ETH BTC ratio or something. Something like that. I don't know. No one told me that. I remember though, the peak was a while ago. 1:32:56 I think the peak might have happened like a few months after that. But like close to it. 1:33:01 Oh, they got over? They got over the Slocket? The Dow? 1:33:06 Yeah, because after that was like when the bull market started to come around and the whole ICO started to come around. And I think that's when the peak happened. 1:33:14 You know, actually, I think even though I just laughed at that, I'm now going to tell a very unscientific just so story and pretend like I like what I'm thinking at the narrative that I could throw out there is that because one thing I've always believed is that the reason why it was Ethereum and not some of these other like member bit shares and remember whatever NXT or something. 1:33:38 So like why Ethereum? Ethereum kind of distinguished itself as being different from Bitcoin in many ways. So it's kind of like a product differentiation thing where people are trying to figure out what is the different thing. 1:33:52 And so you could argue that by doing the Dow hard fork, they set themselves apart. And they said, we are willing to be more centralized, more move fast, break things, they kind of drew the polarity, the polarization of the BTC versus ETH. 1:34:12 And thus they captured what you might call the, they captured the stage for like the single opposition party, like the leader of the opposition to Bitcoin. 1:34:25 I mean, I don't know. I don't think so. I think them just being different enough, like from bit shares and things like that, just like totally different protocol had the EVM expressibility like that was enough of a moving and then like the ICO boom, like in 2017, 2016. And I think that that was enough for like whatever user demand for it. 1:34:48 I don't think like the DAO actually had like a positive effect for users. 1:34:56 Anyway, throw that theory out there. Or whatever. But it is interesting the way Ethereum has done many things, the exact opposite of the way Bitcoin has done them. And I don't know, does that add up to being the number two coin or I don't know. 1:35:13 I think they just spent more on marketing than anyone else at the time. 1:35:22 I remember Dash had a whole marketing budget in there, like it was like in their blockchain. Like 15% of the block reward goes to marketing. And that came out and I was like, that's the dumbest thing I've ever heard in my entire life. And then it completely started to work because they were sponsoring all that stuff and you'd see them everywhere and all these people were talking about them. 1:35:41 I agree with Adam, the marketing that Ethereum took with like the Ethereum conferences and like onboarding a bunch of developers. That was probably the main thing. Yeah, I kind of agree with Adam, the marketing. And I think maybe if you want to say Dash had marketing too, it just wasn't good. 1:35:56 Yeah, it wasn't developer focused, I guess. 1:35:59 Anyway, so could you implement… I was finding the conversation on Twitter interesting earlier in the week about the limits of language expressibility. 1:36:23 Because I think people have taken the idea that you could or should reject specific opcodes if certain things were possible to implement with them. 1:36:36 And I just thought, you know, it's like designing a CPU for the, you know, you can implement Pac-Man button or chess or something. Imagine like trying to think like that at the opcode level. 1:36:47 It's, you know, any programming beyond a certain level of expressibility is going to become equivalent and able to, you know, just implement things in a different way. So I think that's not a good way to think about things. 1:37:07 Well, I think there is a theoretically possible way that I did, in fact, present about in 2016, which is that since the way Drivechain works is it's like the miners are like, the sidechains have like these, they're like these big categories, and it's like human managed. 1:37:27 You could have something where it's general purpose at the lowest level, which of course the BIP300 sidechain is like, just like any Turing complete. Like, you know what I mean? Like, it's like you just any piece of software. 1:37:42 So it has infinite expressibility. But actually, because the drop out of the sidechains is done by miners, the miners might only add them by category, like they'd say you have to have a privacy sidechain, or you have to have a assets sidechain. 1:38:04 And then it might come back in and it might be even be the case. But if there's general purpose sidechain, like an east sidechain, they might one day pull the plug on that and say, because it's too general, and it allows things that are bad, you have to undo the generality and you only have to make a, you have to make an NFT sidechain. 1:38:25 And so that's just a theoretical possibility that I, I don't know how practical that really is, because, but you could, the miners could, if there's something, if there's a problematic behavior, then actually the, you could pull the plug on it at the sidechain level. 1:38:45 And then the sidechains themselves would, they would know that they would only actually be added by miners, they would only be not killed if they were not general purpose. So it's kind of weird, you have a general purpose ingredients, which is just like whatever the software could theoretically do. 1:39:05 But then if the result is bad, like you're held accountable to the results, you say you must do. 1:39:09 Well, I think, I hope people would be more like permissionless innovation mindset for, for a side 1:39:17 chain. But I mean, the original context they were thinking about expressibility limits is like, you 1:39:24 know, in the Covenant, recursive versus not. And, you know, some people have given fairly convincing 1:39:30 arguments that it doesn't make that much difference to safety, because you can have really deep, 1:39:35 pre-committed, non-recursive Covenants. But, you know, then they are thinking, well, if they, if 1:39:46 they don't like sidechains, and you tell them that, you know, a Covenant could make us, could be 1:39:51 used to implement a sidechain either, then like, well, maybe we don't want Covenants either. 1:39:55 Really dislike them. I mean, don't you think sometimes these are just people on the mailing 1:40:00 list or on or on Twitter, who they just really want to say an impressive thing, and whether or not 1:40:08 it's good for Bitcoin, it's secondary to their cause? 1:40:12 No, I mean, it was the recursive Covenant thing. I thought this is a very impressive point. But then 1:40:17 I was like, you investigated more than I did. And I was like, well, I mean, I'm not saying 1:40:22 this is a very impressive point. But then I was like, you investigated more. And you're like, 1:40:25 wait a minute. Yeah, it only seems impressive. It's not really impressive. Actually, it's just, 1:40:30 I mean, I think it's like the concept of, you know, what opcodes, 1:40:39 like volunteer developers on Bitcoin are gonna typically be, you know, self motivated to 1:40:47 work on, you know, test, code, etc. are things that somebody has a use case for, you know, so 1:40:57 like lightning, doing what it does, and requiring originally was it CLTV, or like one of the time 1:41:08 based things as an opcode, rather than as a height flag was, like motivation enough for people to 1:41:18 want to do that, right. And so, but this conversation is almost the opposite, right, 1:41:23 that there was something that didn't want it. So then they were thinking about, like, 1:41:29 not wanting something else, or, you know, trying to restrict covenants, so that they 1:41:37 do the applications they do. I mean, it's not really about what it can do, but what it can't 1:41:42 do, right? So we don't like this thing. So we'll try to figure out when to do covenants that makes 1:41:46 it impossible to do that. But I was trying to explain to them that, you know, people have found 1:41:51 this out before in other languages, that the limits of computability are really counterintuitive, 1:41:57 and people will think that it's not possible to do that. And for some reason, for years and years, 1:42:03 and then somebody will show, you know, they'll tell somebody else, and they're like, oh, yeah, 1:42:07 you could do it. And, you know, they had a key insight, and they make a working example, and it 1:42:12 flips everybody's view. It's like, well, you can do it. It's a trick to it, right? So, you know, 1:42:17 can Bitcoin do covenants today? It turns out not quite, but really close, right? If OP_CAT hadn't 1:42:24 been disabled very early on, maybe it would have had covenants. There's several 1:42:31 approaches that almost but not quite work, and maybe it's even possible, like with some, 1:42:36 you know, really creative abuse of like signatures and different things, right? So 1:42:42 I think it's just not a good approach to worry about, and just try to make, you know, 1:42:50 useful opcodes that work well with other opcodes, and composably, and, you know, 1:42:57 can enable a range of things when combined with other opcodes, whatever you write. 1:43:10 Does anyone else want to say anything? A lot of people asked to speak, and I 1:43:17 added a bunch of people. 1:43:21 Yeah, I could. You know, thanks for adding us. I mean, this is related a little bit to 1:43:26 the Drivechain conversation, but more about, I guess, some ethos of the cypherpunks, and, 1:43:30 you know, Adam, just everything being so badass on a mission standpoint. I was curious about 1:43:35 what you guys thought about how we can get more people running nodes effectively and being active 1:43:39 participants in the network. I mean, I think that there's this interesting, you know, movement of 1:43:45 people that want to have a bigger voice, want to be a part of it, and, you know, there's some 1:43:50 different ways people kind of get in the door through, if it is, you know, on the payment side 1:43:54 of things, financially, that's all wonderful. You know, yeah, inscriptions, good and bad, I mean, 1:43:59 have brought people in through kind of creation of art or inscribing different things, like we 1:44:05 even made like a manifesto and whatnot, but I was just curious to get your guys' perspective on that, 1:44:09 like, and what kind of, I don't know, how Drivechains can also help, you know, more effectively 1:44:15 bring a different group of people into running nodes and just actually being contributors in 1:44:20 that way. I mean, historically, what helped was, I think, Lightning, the way it was implemented 1:44:28 and then to be online, and how it became quite popular to run Lightning, a node related to 1:44:34 running a Lightning instance. And I also think the UASF and contentious fork caused people to, 1:44:42 you know, more people to realize that running a full node was a defensive measure, you know, 1:44:49 not your keys, not your coins, but also not your full node, maybe not on the right network. 1:44:56 So I don't know, like, in terms of encouraging people to run nodes, I think the other thing 1:45:01 that's helped is there are multiple companies making dedicated nodes that are easier to 1:45:09 set up and maintain, you know, not everybody's, like, a Linux system administrator capability, 1:45:15 right? Yeah, totally. Like, for me personally, I have a, you know, a Mac and being able to have an 1:45:21 SSD just made it a lot easier. And I guess the incentive to do it, too, has been fascinating 1:45:27 to see, like, I guess, you know, art really speaks to people. So people having the chance, 1:45:32 I guess, kind of like you were saying, Paul, like, the marketing side, it's been really fascinating, 1:45:36 kind of cool to see that, like, right or wrong, like, the ordinal side of things has been like 1:45:41 a marketing kind of for a different population of people on the Bitcoin side who want to experiment 1:45:46 with art and do other things and are now, yeah, even learning about doing stuff like running nodes 1:45:52 and learning how to be badass cypherpunks. So I think it's just really interesting and pretty cool 1:45:57 to see. Yeah, I have some ideas. So, yeah, it's true that every Lightning node must be, 1:46:04 must have access to a full node. And the same way, actually, every Drivechain, 1:46:09 sidechain must need to have access to a full node as well. So that's kind of direct. But in general, 1:46:18 the block size limit is key because it keeps running a node cheap. So you have to keep 1:46:23 focusing on it cheap because a thousand new blocks come in every week. 1:46:28 And so even if at the one megabyte level, that's one gigabyte. And now we're at whatever we are, 1:46:33 you know, who knows exactly what it is, but 2.5 gigabytes per week. So it piles up and 1:46:40 it has to fight against the increasing internet speeds and things. I have some other thoughts, 1:46:49 which are that, I mean, one thing we talked about in the other chat is this coin news 1:46:54 idea, which is neither, it's not a soft fork or a hard fork or anything. It's just cosmetic 1:47:00 in the node. I mean, I think the node should do some things for people. So the node, 1:47:06 it tells you whether or not you're on the right Bitcoin network, but the node should also, 1:47:10 like the node should have a block explorer. So like we have this in DriveNet. If you download 1:47:15 it, we actually have in the, in the full node, it has a block explorer and it has like hash 1:47:21 calculator. It has stuff that like lets you figure out whether or not your wallet is working. 1:47:29 It has the bit 39 wordless stuff. So it has, it has tools in there that I think that I use 1:47:36 personally. So if I use them, then maybe someone else will find them useful. Maybe not. I don't 1:47:41 know. So I think that we should, the node should have a bunch of stuff that people use. And I also 1:47:49 think that the node could be possibly, I'm open-minded to a radical re-envisioning of the 1:47:55 node. I'm sure everyone's going to panic and say that this is me attacking Bitcoin yet again, 1:48:00 but I think you could like download one piece of software that's very small. 1:48:06 That's not a full node, but it's something. And then that thing could like 1:48:13 upgrade to an SPV node and then upgrade to a full node, 1:48:18 like upgrade to a highly pruned full node. And so what I'm getting at is if you, if you go to 1:48:22 people on day one and you say you need to download 600 gigabytes, they'll be like, 1:48:29 okay, thanks. Nice to meet you or whatever. And they'll just be like, whatever. 1:48:32 But we want to ramp up the commitment. You know what I mean? There's a lot of people who run 1:48:36 nothing. They run no node at all, zero. So we want to see if we can get them in for like, 1:48:42 can we get them in for like 50 megabytes? And then can we get them in for this? And then we'll, 1:48:46 you know what I mean? Like we can give them a tiny piece of software that does 1:48:50 some cool stuff for them that they actually like, and then we can maybe, you know, ramp it up. 1:48:58 And I think that's the best chance that we are going to get at actually getting these people to, 1:49:03 I'm kind of surprised that so many people do run full nodes at all, given the severe ramp up. So 1:49:10 I'm thinking like, all these people with zero nodes, how do we get them to something? 1:49:15 Other people don't necessarily like this approach though, because they say 1:49:19 that this will stop people from ever becoming a full node. But I say a lot of people will never, 1:49:23 will never become a full node if you ask them this way. So it's hard to say who's right about that. 1:49:31 Yeah. I think so much of it goes back to incentive, you know, it's like, what is it? 1:49:35 And for me, and I think like running a node, like there's a big identity component too. You know, 1:49:39 we've seen this, we're trying to like earnestly create, you know, a little community that, you 1:49:44 know, cares about the Cypherpunk values. And it's been very cool for people, like it means something 1:49:49 to them to run a node, you know, to like be an active participant. And I think I'm down if you 1:49:54 want to like experiment a little bit with, you know, I think another campaign I'd talk to some 1:50:00 of the folks with the SF Bitcoin dev, you know, meetup was we were looking at doing like a 1:50:04 lightning kind of campaign. We kind of got a number of people running nodes, but like we were 1:50:09 thinking about lightning, but if you want to experiment, I think that could be super cool. 1:50:13 Like we need to have a way to mix these kinds of things together. And I think, you know, 1:50:18 we need to have a way to mix these communities. Like we're all here to improve and advance Bitcoin 1:50:22 however we can. So there was blockchain.info before they spent billions of dollars on 1:50:30 blockchain.com or whatever, but blockchain.com used to be called blockchain.info. And there used to be 1:50:36 someone cool there. I don't know who they were. If you know who they were, contact me, but they 1:50:42 had this thing where I'm sure that some people remember it, like you could go there and like the 1:50:50 most recent transactions would like scroll by in a kind of like little fireplace thing. 1:50:56 And it would like just, and it would pop up and you would see, oh, here's a transaction. 1:51:01 And I think it had like vaguely like the location or something. It had like the amount, the TXID. 1:51:06 And it was like, here's one from Atlanta, Georgia. Here's one from whatever, something like that. 1:51:12 And it was just really cool to see, honestly. So I also put that in the DriveNet, 1:51:16 our software node also does that, where if people broadcast transactions, they just 1:51:22 kind of show up. You can see them in like a little box. It's kind of like the troll box or something. 1:51:26 You could see them show up and it shows you how much money the transaction's for and TXID and 1:51:33 when it was. And so you kind of see, you feel kind of connected to the community that way, which is, 1:51:37 of course, exactly literally what the full node does. But it's also kind of cool to have something 1:51:42 to look at. And it was kind of cool to look at it first, because you would think of back in those 1:51:47 days, Bitcoin was very small. So you were like, is this project going to, does anyone like this 1:51:54 project? Is this a scam? Am I being scammed by Bitcoin? And so you could see it and you'd be like, 1:51:59 oh yeah, these other transactions are here. It was kind of a neat little thing. So I don't know. 1:52:05 I like that. Where is that? Where can I see that? 1:52:08 Well, if you download our software, you can sort of see it. Although our software defaults to 1:52:13 reg test mode for easier testing. So nothing will really be seen there. I think hopefully, 1:52:18 I'm not sure if you can try to find on Google, like an old blockchain.info, 1:52:23 like front page or someone screenshot of it, because it was pretty neat. And I liked it. 1:52:30 And then they found at some point they got rid of it, which is, I think a huge mistake. 1:52:34 Yeah, I remember. 1:52:37 Yeah, I was wondering where that went. I like blockchain.info. I miss that. 1:52:42 Sounds interesting. Adam, are there any like pieces of art or anything else in like the 1:52:47 cypherpunks movement that's kind of caught your eye that you think would be cool to highlight? 1:52:52 Well, something I was talking about earlier on is the, like the hash of a block. I mean, 1:53:04 this is backup, right? So there was this project, you know, people are always comparing fingerprints 1:53:11 or hashes of like public keys to make sure that they're sending a transaction to the right place, 1:53:17 to make sure that they're sending a transaction to the right place, or that they're looking at 1:53:21 the right person's PGP signature and stuff like that. And this guy called Raph Levine 1:53:26 on the cypherpunks list had the idea to make them more visually easy to compare. 1:53:33 Now, of course, you know, so he had this algorithm for converting 1:53:39 a hash output into an image. And, you know, of course, it's difficult because you want to make 1:53:48 sure that you can't create hash collisions. And that's the case for hash functions. But when it 1:53:54 goes through a transformation to an image, you need to make sure that it's not like easy in terms 1:54:02 of work to find another hash that looks almost the same, even though it's quite different, right? 1:54:08 So that is the kind of the new trick is you need to think of, you know, some kind of visual 1:54:13 algorithm to transform it into like, you know, a certain resolution snowflake like pattern, 1:54:19 you know, if you look at a snowflake under a microscope, they're all like, different, 1:54:23 interesting, symmetrical, crystalline patterns. So, yeah, so thinking about that, and you could 1:54:30 use one of those visualizers on the Bitcoin blocks, because, you know, there's a huge amount of 1:54:38 work that goes into making a Bitcoin block. So it's a thing of kind of mathematical and 1:54:44 thermodynamic beauty, but you can't see it, right? It's a conceptual thing. But if you had these 1:54:51 snowflake transforms, you could actually look at them and they're unique and expensive to make. 1:54:57 We have to find some way to sort of preserve that information, right? So the uniqueness of a block 1:55:02 hash, and visually, how many leading zeros it had, all in a way that makes the images also 1:55:11 very hard to make, you know, to collide to make them look almost the same, right? 1:55:17 That's super cool. I wonder if we could integrate that somehow. I hope you don't mind, 1:55:20 I'm just going to pin this thing. We just made this, you know, we took the manifesto and basically 1:55:25 made the color change with block height, you know, the font of the color. I wonder if we could, 1:55:32 like if a next step could be, I'm sorry, I'm not, my training is actually as a physician, 1:55:37 and I kind of love blockchain Bitcoin since like 2015, and just kind of gradually leveling up my 1:55:43 technical ability. So I'm not following all of it on the tech side. But conceptually, 1:55:47 I love the idea of kind of maybe the next iteration of a manifesto or something 1:55:53 could incorporate this snowflake somehow. I don't know if we could take the hash of block, 1:55:58 maybe Elock could link it together somehow by trying to, I don't know, Adam, if that makes any 1:56:05 sense. I mean, there are services, presumably they're still around, where you can pay a miner 1:56:12 to include a message in the extra non-space. So like a kind of useless part of the block 1:56:22 that takes space anyway. And so it's kind of like a bit of permanent graffiti in the 1:56:31 small part of the block to do with mining, the counter when you do the mining. But those are 1:56:38 kind of cool. It's not like inscription, so it's not like a GIF or something, but there's a 1:56:46 chunk of bytes in there, which is where the miners iterate and keep changing it as they're mining. 1:56:53 You know, each attempt to mine will use a different one, right? So it doesn't really 1:56:58 cost anything in terms of efficiency or space or block size to put a small message in there. 1:57:05 And so there were services that let you do that. Yeah, I see. So I was reading about your 1:57:10 HashCast stamps. Did anyone ever make a visual representation of those hashes? 1:57:17 No. I mean, some people tried to collect them. They'd throw quite a bit of compute power at 1:57:28 them, like multiple machines and graphics card, you know, GPU implementations. And 1:57:35 I think it was even people doing that while you could Bitcoin mine. Like, 1:57:39 they would have mined quite a lot of Bitcoin instead of that stamp. But anyway, 1:57:43 I put them on a web page because I thought they were kind of interesting artifacts. 1:57:50 But there were people doing that in parallel with the time when Bitcoin mining was happening. 1:57:56 Curious. 1:58:03 Well, very cool. Thanks for the chance to just talk and better understand this. And I've been 1:58:09 trying to learn more about drivechains. And Paul, I'll follow up with you as well, 1:58:12 just about seeing what we might be able to do with our community. But appreciate the 1:58:17 opportunity to learn. Yeah, I better clock off. Getting late in Europe. But you guys can keep 1:58:23 going. 1:58:32 So for the Drivechain, would that like take activation, like softworks from like node 1:58:37 runners that are Drivechain, like running the Drivechain nodes, I guess? 1:58:43 Well, BIP300 activates on L1. And that's the only thing that's on L1. 1:58:52 So the sidechain is its own thing. And it has a, well, that's not quite true. Maybe I didn't 1:58:59 explain it. What were you, what do you actually want to ask about? 1:59:02 Well, like we were talking about, like, the difference between like miners and node runners. 1:59:08 Miners and node runners. So like, would you need to like softwork into the 1:59:14 Drivechain? Or could you just run that on everyone else's nodes? Like, 1:59:19 would they know the difference between like a Drivechain transaction or what have you? 1:59:25 Well, I still don't really know what you are trying to ask about. Do you mean that, 1:59:33 like, Drivechain itself is BIP300, and it has yet to activate. And then individual sidechains 1:59:43 also activate on L1. But the sidechains themselves don't live there. They're like lightning nodes. 1:59:51 And so that's like, you know, LND versus C-lightning or something. 1:59:57 So I guess my question is, do you need like a change to 2:00:00 nodes to be able to support the sidechain? 2:00:04 Like, oh, well, yeah, like, ideally, everyone, ideally, the BIP300 idea will get merged into 2:00:14 like the next version of Bitcoin, which is supposed to be version 26. 2:00:20 And then, and then everyone would upgrade to that. And that would include activation parameters 2:00:27 for BIP300. And it's not that everyone has to upgrade to that. But, you know, 2:00:31 this is the ideal situation. So I suppose it, but I'm not sure to what extent it actually requires 2:00:40 most other people to upgrade. I think it's ambiguous. But yeah, the more people who could, 2:00:47 ambiguous. But yeah, the more people who could, 2:00:53 it helps the idea if people are supportive of it. So if people, I guess, tweet about it, 2:01:01 we have a page where we have people on Twitter. We have, it's good if you combat the FUD. 2:01:09 And so if people say things, then you can either 2:01:16 educate people or send them to this space where we, we let anyone come up. 2:01:24 Even the haters. So, so yeah, we do that. So, 2:01:31 so we, so I don't, you know, I think, but in general, the idea is we don't want, 2:01:40 with BIP300, we don't want to like force people to do something they don't want to do. Instead, 2:01:46 we want to just try to educate people and get them excited about what this is. 2:01:55 It is, we just spent a bunch of time talking about whether or not a soft fork is actually 2:01:59 a mandatory or optional change. I kind of still think it's an optional change to some extent, 2:02:06 but we just spent two different spaces talking about that. And many other people have 2:02:12 completely different opinions about that than Adam Bakkenai and Luke Dashjr.'s many opinions. 2:02:19 But yeah, in a sense that there are many new versions, new version of Bitcoin Core 2:02:24 that comes out every once in a while. So, 2:02:31 the ideal thing would be to, for me to open this pull request to the next version of Bitcoin Core 2:02:39 and then have it be, you know, the next version of Bitcoin Core. And then, you know, 2:02:46 to the next version of Bitcoin Core and then have it be merged. But I think there's a bit of a 2:02:51 chicken and egg problem where people will probably, they would hesitate to merge anything 2:02:58 unless they think there is a reason, unless there are people who want it. 2:03:03 Because just in the name of keeping the code as easy to manage as possible, 2:03:09 they will not want to merge anything. Excuse me, they will not want to merge anything 2:03:15 unless there is demand for it. Of course, there cannot literally be any demand for it until after 2:03:21 it activates, but you know what I mean. Like, they want to get an idea that they're actually 2:03:25 doing something that people like. So, I don't know, maybe that answers your question. 2:03:31 What about, like, running that, having people, like, experiment with running 2:03:35 the software before it's, like, merged to Core? Yeah, we have that. That's what I call a drive 2:03:40 NAT. You go to drivechain.info slash releases, or I think LayerTwoLabs.com has, I don't know if it has 2:03:49 the latest version, but I will make sure that it does. But, yeah, that's what I call a drive NAT. 2:04:01 I update it at drivechain.info slash releases. And, yeah, and we will try to make the version 2:04:10 better all the time. So, you can run that, and that's just with Play money. 2:04:15 And it will, it'll, that's like a version of Bitcoin Core that has BIP300 in it. 2:04:20 And you can click on all the buttons and see for yourself, and you can mine blocks 2:04:23 as much as you want. You have your own little Play blockchain. 2:04:29 But in every other way, exactly, yeah, exactly. In every other way, it's the same. 2:04:36 So, you can click all the little buttons and things and see what happens. 2:04:47 So, I think I also should end the space soon, but if there are any pressing questions or comments, 2:05:04 then feel free to ask or speak or whatever. 2:05:12 It's good to see Crown again. I remember being in like clubhouse spaces with them like way back in the day. 2:05:27 Hey, man, I'm just making chicken. 2:05:34 Well, it doesn't really sound like anyone has anything else to say. So, 2:05:37 successful space, everyone can move on to the next cool space. 2:05:42 Unless Julian wants to say something. 2:05:44 Thanks, Paul. 2:05:45 No, not at all, man. I appreciate you having me up. 2:05:49 Thanks. I'll try to learn a little bit more about Drivechains and maybe have some more 2:05:54 cogent arguments. 2:05:57 Okay, great. 2:05:58 Well, that's good. 2:06:02 Okay, well, cool. Well, thanks again, Paul. 2:06:04 Okay, well, cool. Well, thanks, everyone. 2:06:10 See you later. Happy bitcoining.
