Key Takeaways

Bitcoin Core v30 (Oct 9, 2025) is an evolutionary hardening release: it removes legacy checkpoints in favor of a header pre-sync that reduces implicit trust, upgrades P2P robustness (stronger orphan/package relay so one honest peer keeps you synced and thwarts eclipse-style isolation), and deprecates the old BDB wallet for SQLite as part of years-long modularization. The contentious OP_RETURN/ordinals debate resurfaces, but the dev stance is to preserve neutrality, don’t damage Bitcoin’s “money-ness” with policy filters against valid transactions. Expect continued investment in fuzzing/security testing, careful tooling-first approaches to any scripting/covenant upgrades, and a pragmatic reminder: if your node secures money, stay updated, the real near-term risk is legal/regulatory pressure on privacy tech and open-source devs, not the code itself.

Best Quotes

“The checkpoint removal is philosophical, it says the Core devs are not in charge of what your chain is.”

“We hurt the money-ness of Bitcoin trying to save it.”

“An eclipse attack is trying to trick you into not keeping on to a good person.”

“If you don’t run your node with money, it doesn’t matter what you do. But if you do, stay up to date.”

“I’m firmly on team ‘nothing ever happens.’ Bitcoin won’t die tomorrow.”

“Running a node is for you, your sovereignty, your privacy, not for the network.”

“The biggest risk isn’t technical, it’s legal. Developers still don’t have real protections.”

“America could still be the base for freedom through code. If we lead, the world follows.”

“Freedom of speech has strengthened, except when it involves money, and that’s the loophole they exploit.”

“It’s okay if people run their own node software. That’s the point of self-sovereignty.”

Conclusion

V30 won’t “change Bitcoin,” it quietly secures it, reaffirming decentralization by removing trustful crutches, hardening the network’s relay paths, and modernizing internals. The path forward is sober: build assurance (testing/tooling) before new script capabilities, keep nodes current, and defend the ecosystem where it’s most vulnerable, in law and policy, so developers and users can exercise financial speech without fear. In a year, this release is likely remembered less for drama and more as the maintenance milestone that kept a multi-trillion-dollar protocol boring, resilient, and ready for the next decade.

Timestamps

0:00 - Intro
0:45 - Bitcoin Core v30 and the Release Process
8:34 - Checkpoint Removal and Code Modularization
13:59 - Bitkey & Obscura
15:44 - P2P Robustness and Performance Upgrades
26:23 - Security Fuzzing and Eclipse Attack Protection
36:35 - SLNT & Unchained
38:01 - The OP_RETURN Debate and Why Updates Matter
54:18 - Future Covenants and Scripting Proposals
1:06:48 - Privacy Threats and Payment Infrastructure
1:20:59 - Fighting for Developer Freedom

Transcript

(00:00) A lot of people are putting hundreds of millions, billions of dollars even into this asset or completely unaware of the sort of optimizations that you guys are working on. Greg, we meet here on the eve of Bitcoin's death. They could have gone to chain with an old version long ago and you just never heard about it. You're sitting there waiting. You're saying that's weird.
(00:16) I'm not getting blocks, but things must be okay. And then on the other side, they actually have taken your money and run. An eclipse attack is a way of using arbitrary network means trying to trick you into not keeping on to a good person. I think most things are happening within the colored lines. It just improves velocity.
(00:34) Aside from making sure that this multi-t trillion dollar asset doesn't fall over in the next few years, what would you contend as the biggest risk to Bitcoin right now? I mean, I think it's got to be spicy, Greg. We meet here on the on the eve of Bitcoin's death, October 9th, 2025. Bitcoin Core version 30. Yep. Drops tomorrow. very somber. Very somber.
(01:05) Uh, in all seriousness though, I think, uh, a lot of discussion, as we were just talking, um, before we hit record has revolved around obviously this OP op return um, debate whether or not the limit should be lifted or not and the potential consequences of doing that. Uh maybe we'll touch on that, but I think um there hasn't been enough discussion on everything else that's included in Bitcoin Core version 30.
(01:33) So wanted to sit down with you and talk about what Bitcoin Core has been working on with this particular version. And I think before we do that for the layman out there, maybe we just do like a highle um a highle refresher of what Bitcoin Core is, what in what is entailed in um basically releasing um new versions, particularly significant versions like version 30. And then we can jump into the nitty-gritty of of what's included.
(02:08) Sure. You want me to take the lead on this? Yes, sir. All right. So, basically, there's a Bitcoin core software is the reference client, so to speak, where has majority kind of mind share and running share of the Bitcoin protocol itself. Um, it includes a bunch of different parts. Um, peer-to-peer layer stuff, consensus stuff, um, a wallet, which people still use, uh, a bunch of other like bunch of other tools and pieces in there.
(02:41) Um, a major release is done every six months. So, on a six-month cadence, there's a what's called a feature freeze, which is, hey, stop adding new things. Um, we're going to continue just doing bug fixes until this time. there's a branch off which means okay now we have a new fork in the history that will turn into releases that will release binaries based off of this and then eventually a release right with series of release candidates which is happening right now and then eventually a final release. Um in addition to this you also have kind
(03:13) of using this forked history that if there's future bugs found if and if and when there are future bugs found and issues um the fixes could be applied directly on these forked off histories and do minor releases. So someday I will very highly likely have a 30.1 for various reasons. Um and this is how that done.
(03:36) That's that's done on a per need basis. So right now, if I understand correctly, there's uh 20 and 29 minor releases being cut right now for various reasons, bug fixes and improvements. Um so this can happen throughout this life cycle. Um and then eventually at some point these major releases or these major branches get marked as end of life. So saying basically we won't support this anymore.
(04:02) we won't do any effort to like update maintenance to this make buil and make binaries or anything like that and then it kind of gets stale and so that's kind of the the life cycle. Yeah. Yeah. And take an even further step back just on the concept of implementations, right? You have Bitcoin sort of consensus and then implementations like core not le bitcoin uh ptcd.
(04:30) They sort of have their own implementations that build software that is within consensus but does things a little differently. Correct. Yeah. So some are complete implementations. So BTCD is a good example that's been around a long time. Um it has it's it's programmed in go the Golang and it has a complete implementation of the consensus software.
(04:53) So when you get a string of bytes in the form of a blockchain, it needs to come out to the same exact answer as Bitcoin D or any other implementation that raises the reimplementation raises the chance that there is mismatches, but those can hopefully be ironed out and debugged and fixed over time.
(05:16) Um, but there's there's definitely like always it's a very demanding problem making sure they're in lock step of consensus and even between Bitcoin versions there's been historical problems with that uh where implementation details like how the database is stored causes forks in the future right with unforeseen events.
(05:39) Um it's been a long time since it's happened, but um it's always possible with updates or or not updating too. Yeah. And where would you say we are um in terms of the path of Bitcoin Core? Cuz like going back I remember my first Bit Devs in New York in 2015. Um Russ Yianowski basically presented on SegWit and obviously we had SegWit getting implemented but I think um one thing over the year over the last 12 years has been made clear to me is that Satoshi when he launched Bitcoin it was a bit of a spaghetti codebase and there's been a lot of work to sort of separate things within that code base
(06:20) particularly or not particularly but one thing being like the wallet and the guey um and it feels like the last decade aid of Bitcoin core development specifically has been trying to get the implementation to a point where um things are separated appropriately, more modular and you can begin to do um things that that make it uh more complex, make it easier to build more complex applications on top of the Bitcoin protocol layer.
(06:57) Yeah, there's definitely that's one of the major things happening is historically splitting out these functionalities, getting them into their own containers that can be tested separately. Um, so focusing on like the charlatan he's been working on, he's been continuing carrying this torch on the lipcoin kernel. So being able to separate the consensus parts out of the codebase completely exposes an API so people can use reuse this either in in an alternative implementation or just for tooling.
(07:28) Um it's not exactly you know a lot of this work is not glamorous in that there's cost benefits to be weighed. Uh the cost is here is that when you're refactoring these very critical parts of the codebase mostly consensus not wallet uh I mean wallet's important in its own way but uh the consensus parts making sure that you're when you're changing this code to make it modular you're not also changing the behavior which is very difficult.
(07:52) So as you said Satoshi started with main.cpp CPP, one big file that has wallet, consensus, peer-to-peer, it just has everything just jumbled in it. Um, and it's been a long process of carefully teasing these pieces out uh which is continuing today. U one big project is the uh interprocess communication interface. So there's this project basically split up to different binaries.
(08:18) So you can have your Bitcoin node communicate with your Bitcoin wallet over an interface different binaries or in the future you could have the peer-to-peer parts handled handled only by uh a separate binary or different ideas like that but this is like future roadmap stuff. Yeah. Well taking on current roadmap stuff like beyond op return which is obviously the most talked about feature in core version 30.
(08:44) I'm looking at my notes now. Looks like there's going to be removal of checkpoint support and depreciation of checkpoints. Uh changes to data carrier size. Um behavior and deprecation plan, support for multiple operates per transaction, P2P relay, mepool adjustments, rate limiting and denial services, protections, refactoring, internal cleanup, infrastructure.
(09:08) So there's much beyond. Yeah. Up return, up return as well. Yeah, let's start on checkpoints because I think that right has been uh not very controversial but I think people have very uh depending on who you talk to um very uh specific views on checkpoints. Are they good? Are they bad? Is removing them good or bad? Yeah.
(09:33) So checkpoints historically are a are anti-denile service mechanism. So back in the day, if you spun up a node and you didn't have these checkpoints, like let's say a few versions back, maybe 10 versions back, um a peer could connect to you and then hand you a bunch of data that they cheaply made using maybe they have like one ASIC, right, of one minor and they make a long block header chain, a very weak difficulty, and they intercept you right when you're getting connected to the network and it just feeds you these headers. These headers based on the current architecture at the time are just
(10:09) written to disk. And so these are 80 bytes each. And so if you do enough essentially just writing 80 bytes of data over and over and over to disk and this is called, you know, a header diskill attack. So these checkpoints are basically saying uh okay up until this point we're not going to accept any forks in the blockchain history.
(10:29) It must get to this point and then it continues doing validation after that. This this point that they picked is basically like, you know, it's oh, it would take 10% of the network's mining power yada yada long time to make a header chain this long. Therefore, um it makes the attack that much harder. That that was like the original motivation because it was a real attack.
(10:54) And correct me if I'm wrong, but wasn't there aren't the way the checkpoints are sort of like verified or um decided upon? You have like a number of developers basically just sign like this is the right checkpoint. This is the right add a new check exactly add a new checkpoint and all you need to do well let's see for check I haven't thought about this in a while but you want to make sure that reorg will not happen beyond that point.
(11:23) So it has to be very deep, right? It's a it's qualitatively different than another fe feature called assume valid. So this one you have to say we will never fork this one out. And so it's kind of labor intensive to like philosophically argue that is 300,000 blocks correct, 400,000 things like that.
(11:42) And it's because you really are saying like I will not diverge from this history. But yes, ostensibly you get a you know get into a GitHub uh pull request. Somebody says, "I'm updating it to this height, so 500,000 or something like that. This is the hash." And everyone sits there and makes sure that Yeah, there's been 500,000 blocks on top of it since then, and this hash matches.
(12:03) That would be a verification. Yeah. And how's that what's what's being replaced? There's a headers preync or something like that. Exactly. So there's this long this idea this is years and years of an idea where you could say okay what if we have a when we're first when we're fresh syncing with the network you just have a broad idea of like how many how how much proof of work you should be expecting.
(12:32) So you connect to network and say I'm expecting you know this many exa I can't even za hashes or whatever right and then you get this you get fed this header chain but instead of committing to disk you just walk the whole chain the whole way until you hit that minimum proof of work requirement that you've internally internalized once you hit it say okay that looks good I've gotten all this way and I've only stored one header at a time in memory now that I've gotten this way I'm going to do it backwards again you just sync it twice. So you sync the headers once to verify that your disk is not going to be filled
(13:03) and then you sync again to actually write to disk. And this along with a bunch of extra testing work allows you to remove checkpoints entirely from the codebase. Does that have any um IBD trade-offs in terms of time? Yeah, I think with the current implementation, if you have a flappy internet connection, which I had once when I was testing, I was testing by flapping the internet connection during the preync before you've finished the first pass. If it if it gets interrupted, like your peer drops for whatever reason, it has to restart. So,
(13:40) that shouldn't happen. I haven't seen that since uh since I was testing it, but that's one constraint there. So, you need to be able to download the header chain once. As soon as that's done, you do it. It goes like historical. And there are ways of improving this, but I think it's one of those engineering complexity trade-off things, which doesn't seem worth it. Sup, freaks. This RIP TFTC was brought to you by our good friends at BitKey.
(14:04) Bit Key makes Bitcoin easy to use and hard to lose. It is a hardware wallet that natively embeds into a 20 or three multisig. have one key on the hardware wallet, one key on your mobile device, and block stores a key in the cloud for you.
(14:24) This is an incredible hardware device for your friends and family or maybe yourself who have Bitcoin on exchanges and have for a long time but haven't taken a step to self-custody cuz they're worried about the complications of setting up a private public key pair, securing that seed phrase, setting up a pin, setting up a passphrase. Again, Bit Key makes it easy to use, hard to lose. It's the easiest zero to one step. Your first step to self-custody.
(14:43) If you have friends and family on the exchanges who haven't moved it off, tell them to pick up a big key. Go to bit.world. Use the key TFTC 20 at checkout for 20% off your order. That's bit.world, code TFTC20. Sup, this was brought to you by our good friends at Obscura. If you've been listening to the show long enough, you know we care deeply about privacy, particularly as you peruse the web.
(15:02) It is important to be using a VPN. And Obscura is our VPN of choice. That is because it is a VPN built by a Bitcoiner for Bitcoiners. It is the first VPN that can't log your activity and outsmarts internet censorship. ObscureVPN works even in the most restrictive Wi-Fi networks where other VPN simply fail to connect.
(15:19) With server locations across America and the globe, Obscura keeps your internet access unrestricted. Wherever you are, I've been using it since it launched. I see no problems with speed. I can get on YouTube TV without any problems. It simply works. They can't log. You can pay in Bitcoin. Go to obscura.net. Use the code TFTC25 for 25% off an annual subscription.
(15:37) It's already a good deal, their annual deal. The TFTC2 code gets you 25% more off. Go check it out. obscure.net. Use the code TFTC25. And so I guess again stepping back broadly speaking, how profound would you say that this major version releases in terms of improvement of the node software itself from an efficiency standpoint? So, are you talking about initial block download or just this IBD? You can even talk like peer-to-peer level um uh obviously or transactions going to be um metriculated through the the
(16:18) peer-to-peer network faster. Sure. So, on the the checkpoints front front, that doesn't improve efficiency at all. That's just a philosophical uh change to make it clear that the core devs are not in charge of what your chain is. Um but from a performance perspective, there's been a bunch of work done by Lawrence who has focused on especially on the lower end of hardware for initial block download. I haven't paid it very close attention to that um but I know it's happening.
(16:50) Um the other kind of transaction uh robustness right for the peerto-peer network there's been a bunch of work uh both on there's this thing called the transaction orphanage and also uh package relay so I'll start with the orphanage part where if you turn your node on for the first time and your mempool is empty people will start telling you about transactions which are have dependent dependencies in the mele itself but you don't have them.
(17:21) So for example you get a second generation transaction that depends on a first uh right now uh prior to 30 uh 30.0 um this process is a little flaky and can be interrupted by direct peers who are either malicious or malfunctioning. So 30 30.0 has a significant improvement to that.
(17:48) It was spearheaded by Gloria, Peter and others um to make this robust to single peers being malicious or even NP peers being malicious. So as long as you have one honest peer, you can make this kind of transaction catch up in the me pool. Is this for like child pays for parent and RBF only or? Yeah. Uh no, not only. So this it is it was aimed at it.
(18:15) So it was aimed at the kind of one parent one child package relay project which was deployed in full on I think 28.0. Um but the existing implementation had this weakness where if a single peer connects to you they can throw garbage at you and basically empty out this this cache right so basically it's the way of connecting the dots in your mempool basically get disrupted by a single peer and the new uh implementation of what's called the orphanage finding your parent uh this is robust even if you have n minus one connections being attackers so basically the one honest peer can take up a slot and make honest CPFs
(18:52) and like package relay attempts like at least one at a time. So yeah, I'm trying to visualize that in my head. So you have a let's say out of the out of the box eight peers, seven of them are malicious and your node is just so they're they're feeding you orphan garbage.
(19:17) So stuff they don't intend to ever fix, right? say it's stuff really it's just stuff that doesn't cost them anything. They're just handing you data to look at and hold. But basically, instead of one big global bucket, which it was before, there's like a global bucket. So, one peer could just go in and switch out the buckets contents, you have n buckets. And these end buckets can be shared.
(19:34) It uses some optimistic pathing like optimistic assumptions about using the whole space by one peer. But under kind of these loads where either things are very busy or the peer is being malicious then we protect at least uh we have a protections slots for each peer essentially to make sure that economically valid transactions are propagated.
(19:55) Yeah. I'm trying to think how would uh how does the node software determine that the one pier providing you good data is actually the right data. So it's not scoring or anything like that. Uh it's just saying I think the if I remember right it's saying a maximum transaction package can be like this big like 101 kilt bytes it says I'll protect that much per pier so whether or not the pier's malicious or not doesn't affect this number it's just something you allocate for that pier so it doesn't it doesn't take like
(20:31) historical note of who's given you useful things just allocates that Yeah, that makes a lot of sense. It's funny because uh many people I mean as Bitcoin we're hitting we hit all-time highs earlier this week. We're at a $2.5 trillion market cap and most of the world it's focused on Bitcoin just views it as this digital capital good um which it certainly is.
(21:04) And I think getting into the nitty-gritty of um policies like this or not even policies but uh sort of optimizations like this really reminds me at least in the the the Bitcoin protocol is extremely complex and a lot of people are putting hundreds of millions billions of dollars even into this asset are completely unaware of the sort of optimizations that you guys are working on.
(21:33) and and these kind of things don't require coordination with other groups. Uh so there's no new like peer-to-peer messages. No no new format here. So this is just piggybacking off things which have existed for many years which helps helps with velocity for moving forward with things but also limits what it can possibly do. Um larger changes might require more changes like from a higher level but then that requires more coordination with other projects. Yeah, like BCD as an example. Yeah.
(22:03) And on that note, like how how's that coordination improving or deprecating over time? Is it getting harder to coordinate or Well, like I said, I think most things are happening within within the colored lines. So, in the lines for coloring, which it just improves velocity. But yeah, like there are no commonly used from scratch implementations of Bitcoin today uh that are not Bitcoin core, right? So you have Bitcoin knots which is a fork of Bitcoin core but it has per version that has all the same features pretty much with extra things added on. So that doesn't take
(22:47) coordination. But for example, BTCD is a few versions behind on things like as far as I know they don't implement implement the way of sharing transactions in the network using witness transaction ID. So WTX ID gossip. So this can impact decisions that Bitcoin core makes internally how we try to save bandwidth for our peers.
(23:16) We have to be cognizant of what other nodes on the network, what are they doing and that it can affect things internally as well. Well, I mean sticking on BTCD, there was an example of that a couple years ago now at this point when Barack did that 999 of 1000 multi-IG. Yeah. That knocked uh that knocked BTCD off the network and some lightning nodes for a period of time. Mhm.
(23:40) Yeah. That was an tapper, right? Yeah. And there's been other ones with so some fuzzing work. I can't remember who did the fuzzing, but the slight difference in how the script interpreter uh executed a certain thing called find and delete. It's a very obscure function in the old script codebase.
(24:02) Like this is like like Bitcoin uh Satoshi era scripting that we don't use anymore in Segwit or Tap Routt. But like these minor differences can result in possible forking opportunities. Um, and if I remember right, that was even with transactions that were standard. So some someone who's malicious could have forked off BTCD but didn't.
(24:22) Um, so that was good. It's it's it's hard. Very hard. Yeah. I mean, since you mentioned scripting, is there anything in version 30 that um involves scripting? No. So the last I don't think script the the script interpreter is one big kind of scary area that's you're hesitant to touch unless you really need to.
(24:47) Um and during normal releases there's almost no reason to touch it. I would say the only thing that might touch is liquin kernel with interface stuff but I think not even then. Um the last time I touched it was a couple releases ago. So the pay to anchor update that's a very minor change that doesn't even doesn't even change the definition of what's happening.
(25:13) It's just like minor uh basically saying this is not an upgrade path anymore. Let let people use it. So I would say in general we don't touch scripting unless there's a consensus change we're trying to affect. Um my research I I thought I read something about ephemeral anchors with 30 is that okay no so that would be so go a bit of history so ephemeral anchors is kind of two concepts right there's the pay to anchor part which is the script that was 20 28.0 and then ephemeral dust was the other part and that was in 29.0 So, so those
(25:54) have been out for about one two release cycles. Um, obviously this this uh package relay buff that we're deploying in 30 is going to help, but those key parts were already uh deployed in place. All right, that's what I Yeah. And an ephemeral dust doesn't affect scripting whatsoever.
(26:15) It's just it's just a rule that basically says you're allowed to have one dust output if you spend it. It's pretty simple. Um, what are you most excited about in version 30? Um, yeah, a lot of the stuff is kind of just like not letting the network fall apart kind of stuff. I I think a lot of the uh if I'm not exactly answering the question, but I think a lot of the work has been done at the security level.
(26:45) Um, some excellent work with the the Brink fuzzing team. So like Nicholas and Marco uh DeLeon, not Marco Falke, uh they've and and team have been doing great work with the fuzzing infrastructure. So I feel like the asurances we have are much higher than prior years, including just going back a couple versions.
(27:10) Um I I can go more into that if you'd like. Well, I'd like you to go into more like not letting the network fall apart. What What uh that's part of it, right? I I can get into this. Yeah. So, historically, one problem with Bitcoin releases is that it's hard to test everything end to end in a robust fashion where you have, you know, you have a bunch of layers here.
(27:36) You have a networking stack where you where you're taking in random TCP IP data, you're talking to peers, you're receiving data from peers, you're processing data in like paths that depend on a bunch of context. So it's hard to enumerate all the possible paths and it's hard to do this in a test that's in a robust way. But basically um Nicholas and a few others have been working on a buzz harness which is like putting random intelligent but random data and inputting it directly into the binary and seeing if that if the um behavior follows the what we assume assume to happen. So basic ones is we assume that
(28:12) any message that a pure can send us won't make us crash. That's kind of obvious but trace making it uh try to trace all the different code paths to make sure it doesn't crash is like a non-trivial thing. The other thing you can do is do kind of this we call invariance checks which are things like any message that this one pier so let's say pier a pier a sends us a peerto-peer message it should never cause us to disconnect pier b so an attacker shouldn't be able to connect to me and make me disconnect with the honest pier and so you can essentially set up a harness like that do a few hundred
(28:49) iterations per second of different message patterns including block headers transaction announce announcements, pings, pongs, whatever. Basically spewing stuff, valid or not, at the node and making sure that this connection, this connection with PRB stays stays online.
(29:11) And so there's been a number of like historical kind of catches with this and I think it'll be very nice to have going forward, especially with peer-to-peer changes or policy changes too. Is that specifically to stop something like an Eclipse attack? Yeah. So that example, the invariance check of don't make me disconnect with my honest fear would be yes like I want to hear about all blocks that are honest or even transactions too.
(29:38) So one interesting with this orphanage update or how we're holding on to these orphan transactions, there's a fuzz harness that said is essentially this, you know, if if the honest peer is staying within their limits, then another peer should never be able to evict the honest peers's things, right? And you could basically have the same exact thing.
(29:58) Um, spews a bunch of data at it and make sure that nothing is ever evicted from this honest pier. And so the level of assurance you get uh gets much higher. I think I can go on all day about this, but you know, I'll scare you more because there's a bunch of there's definitely with the price going up a bunch of people are new to Bitcoin.
(30:18) But let's dig into this concept of an Eclipse attack. So trying to prevent this to make sure when you have a Bitcoin node, you have slots open that peers connect to so that you can receive and um pass on transactions and other other data. But the concept of an Eclipse attack is if you have malicious peers that take up all of the slots interacting with your node, they can begin feeding you bad data and basically ensure that you're not uh in consensus with the longest chain. Bit Bitcoin relies on the one honest peer assumption. So as long as one peer
(30:49) that you've reached out to or has reached to you is honest, then you can stay caught up on the best chain of blocks, the heaviest chain of blocks. And an Eclipse attack is a way of trying, it's an attacker using kind of arbitrary network means trying to trick you into not keeping on to a good person or letting them go or not letting them in at all.
(31:15) And so one way of doing that would be like send a message that causes you to disconnect a good person, right? So exactly why is it important to protect against these attacks as like how would well what what would what is the intent of yeah somebody an eclipse attack? So there's two two reasons why you wouldn't want why an attacker would well two major reasons why an attacker would want to stop you. uh your attacker is another minor and you're a minor.
(31:41) So you're mining blocks and they want to partition you from the network, get you alone. So you think you're doing good work and making the longest chain, but in reality you're falling behind the rest of the network. So you know if you're if you're 30% of the network, if you can partition off 1% pools off the network, suddenly your 30% becomes 35% 40% over time, right? Um, and this benefits you greatly because larger miners tend to fare better because they're just getting ahead.
(32:13) Um, the other would be if you're not a minor would be something like you run a lightning node or a node that has a watchtowwer of any sort. So you have like pre-signed vault transactions and you want to watch when things are happening, right? If a theft is occurring in lightning, it's the same idea.
(32:33) uh a lightning party counterparty is trying to defraud you going with an old state on chain. Uh you want to hear about the newest blocks as fast as possible and the fastest way to do that well if you're being if it's being stopped entirely then you just never hear about it and then your money goes out the window.
(32:50) So yeah on lightning specifically with the um what's it called? HTLC's. Well, the HTLC's, but if you get Eclipse attacked and you don't know that your channel counterparty has what the specific transaction with your channel part is not respond commitment transaction. Yeah.
(33:10) Yeah. So, they could have gone to chain with an old version long ago and you just never heard about it. You're sitting there waiting. You're saying that's weird. I'm not getting blocks, but things must be okay. You know, maybe miners are slow, right? And then on the other side, they actually have taken your money and run. Yeah.
(33:29) And that takes it's two weeks for that or two weeks depends. Yeah. So with lightning specifically that's up to the node operator uh and channel partner. So you can say I I feel comfortable waiting with you running off of my money after half a day or one day. That's really up to you. Um and that's the reactive security model. Basically it's for better security. You should turn turn that dial way up.
(33:54) So talking again about that L & D exploit crashing, like that's one example why you might want a longer delay because not only are you worried about Eclipse attacks, but you're worried about bugs and packages and your internet, you know, getting cut off and there's all sorts of reasons that you'd want to have these time locks be longer.
(34:18) And since you mentioned it, bugs, what um as it pertains to bugs in V30, what uh any being patched? Uh surely. So if you go to bitco.org, I'm pulling up right now. There's the let's see put my foot in my mouth here. Not find it. Releases security advis development security advisories. This is the place to track all the publicly known vulnerabilities.
(34:44) And so example um the latest one was a remote crash due to address spam. And there it'll give you all the details of who you know what severity it's ranked. So low, medium, high, which is basically a rough ranking of how easy it is it is it to do and how bad does it result in. So the worst would be something like chain split, right? forking off people and making double spending happen.
(35:22) Second least fast would be bad would be like I can send a message and it gets sent to everyone else and everyone crashes, right? That kind of and you can keep going down the list to this takes a bunch of setup. It might cost some money and if I know a minor that kind of thing and that's kind of like the strata there. But if it's a and then also the the the um severity also informs how long it takes to be told about it because if it's something if it's a chain split, if it's if it's unknown, it's kind of hard to do, they might not tell you about it till a few releases after the fact.
(35:53) Example, like if it could be like only after the last vulnerable version was out of end of life. So, we told you to update these last 3 years, you didn't. Here's here's the vulnerability versus something that's low, which is like, hey, here's a new version, and here's the vulnerability.
(36:17) So, if there is a I believe a if there's a low vulnerability for 30 that's patched in 30.0, you should hear about within a couple weeks. I believe that's how it works. Mhm. I'd have to I'd have to look at the process again, but it was a big it was a big job to get that process lined up to make sure that people are hearing about these things and understanding that the system still has flaws and needs to be continuously fixed. Sup freaks. This rep is brought to you by our good friends at Silent.
(36:40) Silent trades everyday Faraday gear that protects your hardware. We're in Bitcoin. We have a lot of hardware that we need to secure your wallet emit signals that could leave you vulnerable. You want to pick up Silence gear, put your hardware in that. I have a tap signer right here. I got the silent card holder. Replace my wallet.
(36:56) I was using Ridge wallet because it secured against RFID signal jacking. Uh silent the card holder does the same thing. It's much sleeker. Fits in my pocket much easier. I also have the Faraday phone sleeve which you can put a hardware wallet in. We're actually using it for our keys at the house too. There's been a lot of robberies. They have essential Faraday slings, Faraday backpacks. It's a Bitcoin company.
(37:13) They're running on a Bitcoin standard. They have a Bitcoin treasury. They accept Bitcoin via Strike. So, go to slt.com/tc to get 15% off anything or simply just use the code TFTC when shopping at slt.com. Patented technology, special operations approved. It has free shipping as well, so go check it out.
(37:32) What's up, freaks? Bitcoin's market cycles tend to follow the same old pattern. Parabolic spikes, brutal crashes. This time is measurably different. The Bitcoin check from Unchained and Check onChain shows how the 2023 to 2025 cycle has permanently reshaped Bitcoin's market structure. Inside you'll find why volatility has collapsed, why ETFs have anchored new five and six figure price floors, and why long-term hodlers remain firmly in control.
(37:54) Download now and you'll also get access to the online event featuring James Czech. Bitcoin has crossed the Rubicon. Get the report at unchained.com/tc. That's unchained.com/dftc being like updating to the latest version. I think that's been a big part of the conversation is this campaign to not update to V30, which is anybody can run any version they want to as long as it's back compatible.
(38:19) What um what would you say to the people out there telling people not to download the version 30? I would say if you don't run your node with money, it doesn't matter what you do. I mean, you might be missing out on new RPC or something for like looking at your memp pool or something, but it's not too interesting.
(38:39) Um, staying up to date matters when there's money at stake and your security of your node at stake. So, money, if you're a business, you should be updating within when possible, especially minor versions. So, 28 something will be released as a 3. Um, I would recommend you upgrade to that if you can't update to 29.1. or 29.2 or 30.0. Um, best case scenario, you update to the latest and greatest because some fixes can't even be some fixes are harder to do in a as a backport.
(39:13) So, all the way to old versions basically like this big change to like, you know, there'll be some big change to this script engine or or something like that. They're not going to mess with that for old versions unless unless the bug is easy to hit and becomes public or something like that. I'm not saying this is the case, but that's just kind of the the thought process here.
(39:38) So, I'd recommend stay off of end of life, you know. So, if you're on 27, get 28 at least 28 whatever the last release was and then try out the new versions too. um if you need to integrate it like like BTC pay server and all those need to keep trying these new versions to make sure that if there's any API breaks they get caught early and can get fixed or worked over an appropriate speed.
(40:05) Yeah. And what benefits would a project like BDC base server have upgrading to V30 beyond what we've already discussed with um the peering? I mean it's less it's a less a thing of benefits per se but I mean there's obviously the performance benefits that you get so faster IBD and whatnot but also just access to the latest tooling fixes.
(40:34) It's more about making sure that things aren't broken because uh as as an example um Bitcoin Core for a long time had maintained a series of patches for this thing called BDB which is a database format that the wallet used to use but this format is extremely not maintained.
(40:57) Uh basically the original project maintainers quit a long time ago or don't don't do the patches necessarily necessary. So, Bitcoin Core had to do that. That support is officially gone for 30.0. So, there's a tool in there to migrate your wallet from to the new version. But if you're like running a larger software stack like BTC Pay Server, there's probably more involvement on making sure that your users go from the old old format to the new format properly.
(41:24) And what is uh what is the new format? Did a bunch of developers simply just write new database? No, it's just SQLite, I think. Uh, yeah, just like a standard format that works for the sizes we care about. So, it's it's funny thing that like SQite that's become extremely popular in recent years.
(41:47) I've talked to Justin Moon a lot about the powers of esculite, but that's another dealing with with Bitcoin being released in 2009 and the tools that were at Satoshi's. Yeah. And every every time the project gets to get rid of a dependency like BDB, the better off we are because these like OpenSSL used to be a thing that we had to have in consensus that was removed a long time ago.
(42:13) there's all these different little projects that we basically reimplemented just the parts we need and then the rest is removed or we use or or we swap them out for really standard components. Yeah. Um so the last time we spoke about the OP return was when we saw each other in person in June May or June. May, I think May BTC++ where uh very uh very interesting get together of Bitcoin developers in Austin, Texas.
(42:49) And yeah, um I guess just to cover that whole debate of OP return, how would you frame it um from your perspective? So, I think that that was kind of where I stopped paying attention because I went in person and was able to finally get out kind of like what's their like what what do they think the solution really is? We all agree there's some level of problem. Some people think it's catastrophic.
(43:14) Some people think it's spammy and noisy, but we don't love the JPEGs, but what do we do about it? and Bitcoin Core kind of people have been saying, well, it's really hard to disentangle what's spam mechanically and automatically without without causing great centralization force and and and peer-to-peer problems in general, right? We we hurt we're trying to save the moneyiness by punishing JPEGs, but then we end up hurting hurting the moneyiness the fundamental moneyiness of Bitcoin. Whereas I asked like, "Hey, what is your ultimate vision for Bitcoin Core if we
(43:47) went down your path?" And essentially it ends up being this argument of we'll have kind of a scripting language or possibly like, you know, this this this list of bad scripts that we have to pass around to other nodes and people are automatically updating their configuration scripts to like filter these.
(44:12) And as you can see, like this kind of method is inherently centralizing. And I I basically came away with I don't think this is a this bridge is gappable. Um there's been some efforts in the knots community to do this where you essentially have a web of trust of filters and it it just breaks the inherent moneyiness of Bitcoin. And I don't know what else there is to say about that.
(44:33) I mean, you can you can ask more questions, of course. No, I mean I think I fall in the camp of I hate the JPEGs. I think they're annoying. I don't like that they're bloating UTXO set or it's not even JPEGs, just like the arbitrary ordinals. Yeah, ordinals arbitrary ordinal fills up the UTXO set. Yeah.
(44:58) Yeah. Well, I guess let's jump into that. Like the core argument for changing up return and um increasing the limit or taking the limit cap off altogether um basically comes down to the fact that people that are injecting arbitrary data into transactions are doing it in a nonoptimal way that's bloating the UTXO set. Correct. Yeah.
(45:26) Mo almost everyone does what's called the description which means uh in segwit or tap routt uh you can put the JPEG essentially in the input side and you get the witness discount for it so you pay four times less oper is an older way of doing it which costs four times as much and the the argument is that if you need it to be in the if you need some sort of payload to be in the output like let's say a cryptographic proof uh it's called a groth 16 zero knowledge proof that's too big for it's bigger than 80 bytes um but it needs to be somewhere in the transaction. So what what people would were theorizing about doing and actually had software to do is
(46:03) stuff it in UTXO's that look like public keys and so nodes have to store this forever just in case someone tries to spend that output. Um, so if there's already these myriad of ways of embedding data, more or less harmful, then basically we hand them the least harmful method and say, "Here, use this one.
(46:27) " I also have personal opinions on kind of how opinionated we should be about what the best wallet software is. So I I worry that if people set their own, you know, hypersp specific arguments like knots like arguments and knobs that it really causes mistakes and ends up kneecapping the moneyiness of Bitcoin in other ways. So I'll give you one example.
(46:52) For the not 29 release, which is the latest release they have, um the new version of lightning channels would not be able to propagate on their nodes. if you use the default settings. And so I think that's a great example of either lack of communication on their part of what they're trying to filter or just ignorance, right, of what they're doing is causing the moneyiness of Bitcoin to be hurt for the sake of saving Bitcoin, so to speak, supposedly. I can go more into that if you want.
(47:23) Yeah. Like how would it mess up the lightning channels? So, the new style lightning channels as well as the Arc, Spark, uh there's probably a few others, they're all using this pattern of the truck transactions, so version three transactions. Um, not only is it the version three being valid to relay, but it allows them to be zero fee if paid for by a child.
(47:52) So, specifically in Knots 29, the current release, those are invalid. um it does not allow those to propagate. So your commitment transaction will simply be dropped by your local node. Even if that was fixed, then they also ban ephemeral dust. So remember this ephemeral dust is the rule where you're allowed to have a single dust output in transaction as long as it's cleaned up immediately after in a package.
(48:17) and they disallow the function where this dust could be like one satoshi, two satoshi all the way up to the dust limit. So tap routt the smallest output is allowed normally as 330 satoshi's. So 1 through 329 would be considered invalid and simply dropped even if it's spent.
(48:41) And again the motivation here is to stop JPEGs because ordinal theory whatnot. But in reality, this is just like this feature is being used in the new lightning channels like that that space of the feature is intended to be used. And so this is essentially going to kneecap anyone using the software and trying to do self-custodial payments using lightning.
(49:06) And when you say V3 transactions, is that is that like version three of Beck 32 or No, no, no. uh is it's the transaction version number. So there's a version field. Mhm. The version field three on 28.0 and and newer is it's is considered standard for relay, but it also enables things like uh zero fee transactions for technical reasons that I won't get into here, but that's kind of like the gist of it.
(49:36) Yeah. No, like I you told me before we hit record that you really haven't been paying attention since BT plus PTC++ but I think I came away from that week because I was um highly uh I don't want to say triggered but I was like a little emotional like what is going on here? I don't want to I was a little I was a little demotivated.
(50:06) Uh I thought I thought there was a chance that we'd bridge some some of this gap and come to an understanding where there's some solution but I just after that I didn't think so and I think it was it was born out to be true. I just I don't you know I don't see it months later. No, you know, get a lot of and it's funny.
(50:27) I've been uh a lot of people hopping in my benches on X and on YouTube and other places saying, "Why aren't you talking about this?" Like, I don't want to breathe air into it. And I can't I think I walked away from BTC++ with the conclusion in my mind like these things are consensus valid. Like there's nothing you can do to stop valid transactions from getting in. um if you want to change it, you got to have the harder conversation of a soft fork to change off return or something like that.
(51:00) And if you're not focused on that, then um I don't I think it's a you're you're looking for a pirick victory there. And then I mean I guess to be critical of Bitcoin core the project and I think we talked about this in May in person too like I think just and I it's just a massive communication PR failure that um I think that's why many people have gotten so triggered um and remain triggered is uh the perception is that Bitcoin core is changing policy rules arbitrarily without um without talking to the broader Bitcoin user base. Yeah, it's a little disappointing and I
(51:40) I find it a little baffling that the response to that is to switch to a distribution that changes policy on a whim of one guy. Um, and completely ignorant too. Like no, I mean I guess I'm being pointed here, but mentioning these like they did not know that they're breaking people's expectations of the network and as far as I know they haven't changed course.
(52:06) So, who's defending the moneyiness of Bitcoin? I don't see how it would be them. Well, what do you think happens tomorrow? Do you think Bitcoin dies tomorrow when 30 is released? I I'm firmly on nothing ever happens team. Uh I think it's not a black spawn event no matter what. Um it's like a very very minor thing.
(52:33) So, I'm happy if people just update to relatively minor uh relatively recent releases um just for the health of the network for security reasons and also just the V transactions, emerald dust, all those things getting out there. It's good to see these getting uh traction in real life. Yeah, the uh I said this on rabbit hole recap. I forget it was two or 3 weeks ago, but I I proclaimed stated um during that episode like we're going to look back a year from now and we're going to be laughing that I think this is what I think is going to happen.
(53:09) Who knows what's going to happen? But um I am also firmly in the nothing ever happens camp. And yeah, I think we'll look back and be like, "Ah, remember we were fighting about that." Yeah, I think I think it's important to try to take some lessons from it. uh whatever those lessons are and then I mean some of the lessons are negative right but basically doing what you can to keep your brand as far as like a infrastructure project which doesn't lose people's money I think making that really your focus rather than trying to cater to every user at once which is
(53:45) impossible but also just trying to communicate that it's okay if people run their own node software that differs Right? It really is up to people how to be like the person, right? Self- sovereignty. And I think people keep forgetting this fact that running the node 99.9% of the time is for you, right? It's it's for your sovereignty, your security, your privacy.
(54:11) It's you're not generally helping the network doing this. There's almost all the time. It's just for you. And that's where the focus should be. Yeah. I I think there is a broad misconception about the power of an individual full node and its influence on the rest of the network. um you know rehashing these conversations that happened during the World Wars concept of an economic node and think you can definitely socially signal by running a certain version of a certain certain implementation but um yeah policy ends up being kind of like the mirror inverse of that right so the block size wars was the intolerant
(54:50) minority or intolerant minority where basically it's like uh if a small fraction of economically motivated users will reject things consensus and it kind of there's brinksmanship involved that might enable softwork. But with policy it's the inverse where a small percent of people who are tolerant of a certain transaction format lets them through in practice even if 90% of the network doesn't.
(55:21) And I think there's a bunch of metaphors here like technical allegorories pretty much or parallels. That's a really good insight. I never thought of it that way. The inverse consensus versus policy. Intolerant minority can affect consensus more than they could policy. Uh a an intoler a tolerant minority can make more things relay. Uh they can't make less things relay. An intolerant minority can affect consensus.
(55:53) like shrinking consensus is the hard is the uh easier part while expanding policy is the easier part in the on the policy side of things. It's easy to expand, it's hard to restrict is kind of like the mirror universe here. It's it's hard to hard fork, it's easier to soft fork, it's in relay, it's easier to expand, harder to restrict.
(56:15) So moving forward when uh doomsday comes and goes tomorrow uh we move on I think the dust will settle. Um a lot of questions around oification, what changes are needed in Bitcoin? Like obviously Bitcoin core isn't going to stop working on Bitcoin after version 30's released tomorrow and the same can be said for any other developer working on any other implementation.
(56:50) But in your mind, what are some of the top priorities that um people need to be focusing on beyond what what gets released uh tomorrow? Well, I mean, doubling down on the security infrastructure, but I already talked about that. Um, so aside from making sure that this multi- trillion dollar asset doesn't fall over in the next few years, um, there is a continuing conversation on what people call covenants or scripting softworks.
(57:15) I think that'll continue. Um Rusty Russell has submitted a somewhat serious like more concrete proposal for his kind of rewrite of Bitcoin script where um taking Bitcoin script and turning it up to 11. Um but there's like a number of different ways that script updates can be done like for uh what what you're trying to accomplish and how you do and that informs how you do it.
(57:47) So he has one way uh Russell Okconor has like simplicity if you if you've read up about that and then AJ also has his own bullish kind of list based programming language and I think beyond the near term we need a bigger discussion about if we want to do if we want to continue iterating on scripting in Bitcoin what's the best way to do it and that's a big engineering question as well as you know theoretical and engineering Yeah, I pulled Sher on a couple of months ago to talk about Simplicity launching on liquid mainet.
(58:19) Um, and we talked about the potential of it getting implemented at the protocol level and it seems like simplicity I mean obviously Blockstream's been working on it. I think the paper dropped what 12 years ago maybe even long time ago. Um, and it's been talked about since then.
(58:38) finally got it live on mainet on liquid um to basically show showcase what what could be done there. But it seems like I mean simplicity's always sort of appealed to me but I I think the common push back is like how are you going to get this into um well yeah common common push back is oh it's very complicated it's a lot of lines of code but if you look at any other proposal it they're making severe trade-offs too and I think the community will have to have an honest discussion that doesn't involve brinksmanship of like you shouldn't be arguing necessarily that Bitcoin isn't worth the work. I
(59:15) would say like this um because there are facets of simplicity or simplicity like solutions that really appeal to me as well um that aren't maintained with the great script restoration or bullish and so I think this discussion has to be made more near term uh Antoine and I have been working on a kind of smaller proposal which is template hash check from stack and internal key think have you had Antoine on for that? No. Okay.
(59:47) But a few months back um basically it's a it's a slight revision and reframing of another proposal where it's like CTV as well as chicks from stack and we basically we became intrigued with this kind of pairing and did a groundup rethink of how we would do it post tap routt era and that was our proposal.
(1:00:12) Essentially, it's a CTV like widget that's typic from stack which is bit 348 and internal key which is bit 349 as is. Mhm. What would you say to the oifiers who are worried about the unforeseen consequences of messing with something like Bitcoin script? cuz they would argue I would argue too there was unforeseen consequences with the combination of SegWit Taproot with the ordinals manifestation.
(1:00:44) Um I guess how do you how do you have conversations around that in really war game through potential for stuff like that? Yeah, I mean that's an interesting question because the things I felt that were deficient in tap routt are probably not the same ones like from an un unforeseen perspective. So when I look at lessons learned from I mean there's probably a bunch from SegWit but let's say from Taproot since it's more recent um we learn things like hey maybe we should have more tooling in place before we actually talk about activation because in taproot the way keys are
(1:01:21) published on the network there are these 32 byt keys what we call xon keys um and this ended up it's may or may not be the right decision in the end but we didn't have a fuller discussion from the tooling side of things.
(1:01:40) How do you make cryptographic protocols with this slightly different public key format and it ended up compliment uh complicating certain protocols. I think it ended up okay but the lessons I took away were essentially hey tooling needs to be like rock like much more defined before these kind of larger changes are done and we take we're taking that to heart. So part of our efforts is not only saying, "Hey, these capabilities, these op codes and capabilities enable some cool use cases. Hey, look at these blog posts we made.
(1:02:13) " But much further than that, um, we want to be have the tooling ready to go, applications deployed in like Signet and and uh maybe custom test nets um before we even talk about things like activation. and we're far from that. Uh even from a mind share perspective, we're far away, but from a quality assurance perspective, we're also far away.
(1:02:37) So that's kind of like the lesson I took away, I guess, from from Tap Routt. Yeah. So like if if it activated tomorrow, ideally we'd be able to have wallets that just spin up and and use things the next day, right? Or, you know, practically the next day. in with Taproot it ended up being like this activated in 2019 or whatever and then like oh it took four more years for MUIG to to be formalized and another two years to be standardized and P PSP support is taking years and ideally this ideally more of this would have been done prior to activation. Yeah.
(1:03:17) And it's insane problem we have as a Bitcoiners as species as we're becoming more dependent to a degree on this in this monetary protocol. It's approaching $2.5 trillion in value. Not only that, I mean you mentioned it earlier, we have all these different second layer solutions whether it's lightning liquid um arc spark charm and mint in the uh in the bag as well. Um, silent not silent payments.
(1:03:46) Um, what does Spark use? Uh, state chains. State chains. State chains. Silent payments too, right? All these, you have this whole tech stack that's all kind of interlin in certain ways. And the velocity is just kind of slow because there's a lot more layers to it. Even if I snap my fingers and we got some magical software, it would still take years for adoption.
(1:04:08) Yeah. This is out of left field, but just because it's a big topic of conversation, uh when it comes like fuzz testing, is AI help at all with this? Is there any uh any vibe coding that helps? I was I was briefly considering today, could you get reasonable vibecoded fuzz harnesses? So making but with fuzz testing, you really want to make sure like you need a lot of subject matter expertise to define it.
(1:04:43) Otherwise, it does like basically really random and if it's really random data, then it doesn't really make any meaningful progress. It's trying random numbers essentially with no understanding of what it's doing. But the way you can write the harness with intelligence, so maybe there's like maybe there is, you know, I wouldn't rule it out.
(1:05:00) I think AI for writing testing is probably one of the best avenues to go forward with in this space. And I'm not sure how much people have been doing it. I was just going to ask, is anybody working on that? probably what um what would you obviously there's been a lot of controversy and [ __ ] slinging going on over the last eight months.
(1:05:24) What would you say is the uh the mental state of your average developer right now? I mean it depends. Um obviously this kind of drama makes maintainers more risk averse in some ways, right? So risk averse could mean they're going to ignore issues longer or they're just going to make snap decisions and just say like this is the way it is. Um outside of that I think people are ready to get back to work uh working on interesting things.
(1:05:52) So like one project that I think will become more important as time goes on possibly is uh AJ's working on this thing called template sharing which is and we basically want these future relay discussions to be less political. And so one way of doing that is solving some parts of it technically that you kind of allow you're more likely to allow people to have different mele policies as long as it doesn't affect convergence of the network in in blockchain terms.
(1:06:27) So we don't want to slow down block propagation on the network to make mining fair. So if there are like technical ways of mitigating this even when people disagree on meal policies that would be a big win. And so I think arguing less about what an what a default number should be in a config file, I think going this way is more fruitful. Yeah.
(1:06:54) What would you contend is the biggest risk to Bitcoin right now? That's a great question. biggest risk I I mean I think it's the legal one um for users and developers still um it's it's a polit you know stable coin people I would say are are political force in America but still not quite there for Bitcoin right uh we still don't have legal like explicit legal protections in congressional writing promising that they won't jail us for writing code that helps people move money, right? Um, privacy is going to be a big bear to to tackle. I think privacy is essentially illegal on the internet and they're going to want to keep it that way even
(1:07:40) if people figure out how to do coin joins and mass and keep offchain the legal I mean just yesterday I was talking about spark the spark uh service how it's their policy to on an indexer publish every single transaction for every single account so if you have someone's spark Spark address or you get a single bolt 11 invoice from them from a Spark user.
(1:08:09) You can look up their entire transaction history including balance. And my guess is they have their stated reasons, but my guess is they're worried about push back from the federal government. um whether that's invasive data requests or you know regulatory crackdown on their service for being you know not for money transmission.
(1:08:38) I mean they they'll try to claim it, right? So the government could still try to claim that they're money transmitters even though they claim they're not. And this could be instigated by a service offering practical privacy. So I think that those are some of the finer tight ropes they're walking these these wallet services. Yeah, I saw you tweet your quote tweeting walls Satoshi which is move to Spark. Yeah, as their back end.
(1:09:02) Exactly. That's insane. It's like anybody who's technical enough can sort of probe that data. Yeah, it's a little surprising. Um, I'm obviously not happy with it, but I think to be clear for that thread, um, I'm bringing this up because wallets like end wallets like wallets Satoshi have to somehow communicate these expectations of non-privacy to their users and I think it's very difficult.
(1:09:33) Um, prior like in previous iterations there they they were the custodian and so Wall Satoshi says I'm not going to publish everything on a database. but now they're relying on a a backend that does. How do you update the mental framework of you know how do you get informed consent from your users for that? That that's really challenging and I'm not sure what the solution is for that. Yeah, I'm just going to pull this up.
(1:10:00) Yeah, there isn't real privacy against the Spark operators that everyone should be searchable in a public index. So, it's like, yeah, they're not even that is their stated that's what they said. So, I feel comfortable saying that's what they said.
(1:10:18) Um, and then you can like, uh, Ben Carman whipped up a tool for me in about 10 minutes. Probably vibe coded it. Uh, there we go. So, if you get someone's Wallace Satoshi invoice, it immediately pulls up their account. And so I tested it on my own which I don't use it seriously but you know it it would show my test transactions to my real Lightning wallet.
(1:10:39) So you know it's like h how do you communicate that to a user especially a new user? How do you communicate that to a user of Venmo which has one you know they're maybe okay with the service knowing but not everyone in the world knowing if they can switch a button. Um yeah. No, that's what I was going to say.
(1:11:02) It's like even if the operator knows every transaction doesn't mean new broadcast. I' I'd be more sympathetic if they just if they just said Yeah. and we give you a button in the API or whatever to say don't publish and then they just didn't do that. I'd be pretty sympathetic to that. Yeah. Yeah. Now, the privacy war is going to be uh going to be a big one.
(1:11:24) But, uh, I saw Dan Gold from Pagein Devkit, uh, a couple weeks ago. It seems like they're making good progress. And when it comes to pay page specifically, I think we're going to have to position it as a way to uh, as a sort of cost-saving technology for exchanges specifically. Yeah, that's I mean, that's the tough thing.
(1:11:46) It seems like to make it palatable regulator regulation wise, we have to say it's something else. It is, right? Pay join and coin joins in general can be potential savings. Lightning is a potential fe is a fee savings vehicle that gets you practical certain certain levels of privacy better than onchain.
(1:12:10) Um an arc spark well all these other systems can also potentially offer those kind of privacy tradeoffs. maybe Trojan horse using the the original systems, right? Yeah. That's why like I I don't know what your thoughts are on Chamoms, but I'm I love them. I I love the uh the Cashew wallets and the petty mint wallets that I interact with and yeah, I think the big challenge is who runs the mint, right? They can't they cannot claim they're non-custodial like by any stretch of the imagination.
(1:12:46) No. So who runs them? You know how much of a centralizing force is that? Right? Cuz it's more efficient if everyone's on the same mint. Um maybe there's, you know, decentralization back pressure from like well we have the lightning network as that inter interconnects everything.
(1:13:10) So maybe the centralization pressure isn't as big, right? You just have like thousands of operators. I mean, I guess we'll see. Some people think the AIS are going to run the mints. They're going to recognize it's superior money for the agentic framework and they're just going to run. No, conspiracy theories there. Yeah.
(1:13:33) And now, but now we're getting into like the philosophical side of things because like no matter what part of the stack we're talking about, like Spark has to make this privacy trade-off because of the government. Um maybe other things like Payjoin won't get implemented by exchanges because they're worried about the regulatory and compliance blowback. Uh, obviously Chamom can provide not only incredible privacy, but since they're separate from Bitcoin and very modular, you can build a literal new banking stack from scratch that gives you all the functionalities you'd want um from a banking service with better,
(1:14:04) more secure tech um minus the centralization pressures of the min operator. Uh it's like we have the potential to build an incredibly robust secure private financial system which arguably should be what everybody wants. Um but for some or not for some reason but the uh the government just messes that up and yeah also the user demand just isn't there for censorship existent payments.
(1:14:36) I mean there obviously is some but in the west as an example no one seems to care and what would make them care right what what events might transpire that will make them care and will we will we be ready for them that's the other one too right we're building I think like general hodddle tech is pretty much solved I would say like Coinbase can seems to be doing okay with eight quadrillion Bitcoin or whatever but you know the the payment technology still isn't there. And so if Bitcoin payments actually need to take off in a non-custodial way in the future, the
(1:15:15) infrastructure needs to be there. And I think that's kind of what we're looking at looking at this future. Hey, made a good step in the right direction yesterday with the uh the Square announcement. People were waiting for seven years for that. Yeah.
(1:15:35) No, I think I think the pressure is going to be digital ID and uh my theory is that they're going to try and thrust something world coin or something like it on the masses and people are not going to be fond of uh staring into the orb and then they'll care maybe. Yeah. Yeah.
(1:15:57) Yeah, that I mean now we're getting to something like do you have uh are you optimistic about the potential for the user experience and the products built on top of Bitcoin to get to a point where regardless of people's um desire to use peer-to-peer cash the experience is simply superior to um the incumbent system that just gets adopted because it's better UX. I mean it depends on the layer. It's already better than some things.
(1:16:21) International wires are trash and will continue to be trash for a long time. But I think you'll I mean some of the payment UXs are really nice in Bitcoin, but a lot of them take steep tradeoffs in the the self-custody dimension. Um you know, if you just park your money on Well, actually, it's this is where it still works, right? uh parking your Bitcoin on Coinbase is only useful if you're willing if you're only interested in trading on Coinbase or using base chain or whatever. But if you want to actually send someone over the light network of payment, I think it still works, but
(1:16:59) there's all this regulatory pressure to not let it succeed, right? And I think that's where all the friction is. So if you can Hey, go ahead. I did this last week. We had uh we had a 1031 offsite with the portfolio companies.
(1:17:20) We're at this resort and over the course of the three days, got to know um some of the the people working at the resort, particularly the bar. And uh last night go to tip him. He's got a Coinbase account. I was like, I'll send it over Lightning. And the UX was just completely abysmal. And I thought like I got a confirmation on my end, but it never hit his account. And I got a confirmation that the payment was received.
(1:17:40) But from what I understand, and I didn't realize this till after I left him, Coinbase is asking users that accept Bitcoin over Lightning to ask for personal information of the counterparty. Exactly. Yeah. The transaction. It's like what? Yeah. That's I think it's it's incredibly centralizing in that no one will want to do that.
(1:18:03) Um, but if transactions if payments payments volume isn't high enough, then people won't jump that hurdle to go on the other side because if if money is sitting in an ETF or what, everyone's happy with it. They don't need to ask permission because it's not going anywhere.
(1:18:23) Um, but if you want to make payments, this is where all this friction shows up, especially especially if you're trying to send from a Coinbase or regulated regulated institution. Well, I don't I don't know if we can fix that aside from legal changes. It's completely immoral though. Like I sent the bitco like I sent it from my wallet. Very descriptive. Yeah. Oh, I know. But like just like I'm thinking about I was thinking about it through.
(1:18:44) I was like wait I I sent $15 $20 worth of Bitcoin whatever it was to this wallet. Like obviously it's centralized. Coinbase is presenting and running the lightning node presenting the invoice. They have the bitcoin sitting somewhere in their account. The guy that I sent it to light does I think but yeah. Yeah. Light Spark, whatever.
(1:19:02) It's sitting somewhere in a centralized third party and that guy's never going to get the money. And I send 20 bucks that I'm never going to get back cuz I I don't think this guy's going to be able to find me to ask me for my home address and all that. And when he does, I'm not going to give it to him.
(1:19:19) I I'll say spin up another invoice using using Zeus or something like that and I'll send you the Bitcoin there. But like Coinbase just holds that money now. Yeah. So I think I think that's where you'll see the riot like if Spark does take off that that's the niche it will fit. Uh there's an unfortunate privacy thing but if you if you're willing to accept a system that says it's self self-custodial and it kind of is custodial at least um maybe that's enough for users to get on boarded.
(1:19:51) Um but is that a world we want to go to versus something more private? This is like big challenge. Yeah, I mean talking to Macaralo earlier this year, he's pretty optimistic that uh self-custodial lightning will see a step function improvement uh better. Yeah, it's it's definitely better than before. Um, I think a lot you you'll hear like, oh, this new layer 2 will fix all Lightning's, you know, all the issues Lightning has, but you look under the hood, it's either making custody tradeoffs, security trade-offs, or it's or it's making the same assumptions as like Lightning needs improvement. So,
(1:20:29) it's like, oh, it's instant transactions. And you said, how do you get instant transactions? Oh, you just trust this person not to sign twice. You're like, come on. like you know that's zero comp trust right so I think there's a in this industry there's still a bit of that even in the Bitcoin side it's kind of hiding what models people are buying into but I mean I'm optimistic too so I think there's enough there for another 5 10 years of development and smoothing of processes yeah and in the meantime in parallel to
(1:21:02) your point we need to wage the campaign to abolish the bank secrecy act where all this insane uh privacy infringing compliance and regulation comes from. Can we somehow get Yeah. Can we somehow get the BSA as a person to insult Trump or something? Trying to think of way of, you know, instigating constitutional crisis because then maybe the courts will strike it down anyways. It's like ah wasn't constitutional anyways, you know. Yeah.
(1:21:34) No, it isn't saying we're dealing with the remnants of uh mistakes made many decades ago. Funnily enough, 1970 I think is when the BSA was uh implemented. It's interesting to see the thing that was vaguely probably not constitutional at the time accepted because we didn't have computing widely. Now that's flipped and kind of seeing the straws being grasped by the statists who want everything to be reported at all times.
(1:22:05) It's really stark, I guess. Yeah. And admittedly, I haven't been following it as closely as it probably should be, but last I heard there was, this doesn't have anything to do with privacy, but to your earlier point about legal ramifications of writing open source software that allows people to use Bitcoin in a peer-to-peer fashion, there was positive language in the Clarity Act, which hasn't been passed yet.
(1:22:35) I don't know if it's been taken out or revised out, but has not has not yet been taken out, but there's always a worry that until the job's done, it's going to get horse traded for something else, right? Because again, you have the stable coin bros, the stable coin contingent, and you've got the kind of Elizabeth Warren contingent at the moment. And people are worried that Elizabeth Warren actually hates Bitcoin more than she hates to stable coins. So maybe a trade would happen there.
(1:22:59) Yeah, we'll see. I'm optimistic long term, but you need to actually battle this out in in Congress and in the courts. Well, I mean, I think my uh I wouldn't call it a pipe dream, but would be incredibly badass is that if they did push and put the regulatory pressure on if you just got back to the site for Punk Roots and you just had a bunch of synonymous devs pop up and just start launching things without anybody knowing who they are.
(1:23:32) So, I have a slightly contrarian point of view on this, I guess. Yeah, I think it's a good idea of something like that. But I see America as a potential base for freedom through freedom of speech and computing. And if if I just snap my fingers and America became the place where all all development, all non-costial development is blessed legally and protected 100%.
(1:23:57) And there's no question that you're going to be dragged out of your house because your system helped enable someone else to do money laundering. I think that'd be a huge win for the world. And I think we can push that way. I I don't think that everything bad for me as a developer is good for Bitcoin, I guess, is my point. I think we can kind of push the other direction.
(1:24:20) make it easier in countries with law and order, potentially more law and order, and export that goodness worldwide through the internet. You know, Greg, I like that. I like that optimistic view. We should lead by example. I still like I said earlier, I mean, the potential, the tools, the potential is all right. Like we can build Yeah.
(1:24:43) an incredibly transparent, robust, resilient, secure, relatively private financial system. The potential is there. In general, freedom of speech has gotten stronger and stronger in the United States. The one caveat is, oh, but you did talked about money and suddenly this is like a legal loophole to throw you in jail forever.
(1:25:04) So, I think like just keep maximizing these First Amendment gains as far as we can in the next few years, right? I think I think it's possible. I do, too. Let's keep pushing. Yep. It's been awesome. This is the uh this is the first time in a while I've uh gone deep on Bitcoin Core stuff and uh it always reignites the uh the sub subdued nerd in me.
(1:25:37) Uh and it makes me miss New York bit devs in the in the heydays when uh when I went nerd out with this stuff for you. I mean, I think I went to probably 80% of the bit devs between 2015 and 2020, and it's uh easy to forget the intricacies and the complexity involved in actually maintaining and uh improving the Bitcoin protocol. Yeah. And most people are completely unaware.
(1:26:11) Yeah. Like with anything else, there's a lot going under the hood. It doesn't directly it's not a feature for the user so it's hard to see and show value. No, I'm thinking too like as more institute like do you have faith that uh the last question you have faith that like as more institutions get in if banks get in that they'll have tech departments that will understand the importance of understanding the intricacies of the protocol level that I don't know I can't I think it's kind of we're also in an eternal September kind of situation um I would
(1:26:50) have expected more industry feedback you know direct correct way. Um, but you don't get that. People don't even really complain when things are broken. Uh, it's it is like a there's a feedback loop problem with development. So, I looking forward find ways to solve that too, especially as things get bigger, right? Think about it, freaks. All right.
(1:27:22) Any final thoughts before we wrap up here? I appreciate you having me on and uh excited for the future still. future two days from now. The uh Bitcoin dies tomorrow. So yeah, enjoy it while it lasts for free because you got to 24 hours. Yeah. All all Bitcoin transactions are legal the next 24 hours. All right. See you. Thanks. Peace and love, freaks. Okay. Thank you for listening to this episode of TFTC. If you've made it this far, I imagine you got some value out of the episode.
(1:27:53) If so, please share it far and wide with your friends and family. We're looking to get the word out there. Also, wherever you're listening, whether that's YouTube, Apple, Spotify, make sure you like and subscribe to the show. And if you can leave a rating on the podcasting platforms, that goes a long way.
(1:28:13) Last but not least, if you want to get these episodes a day early and add free, make sure you download the Fountain podcasting app. You can go to fountain.fm to find that. $5 a month get you every episode a day early ad free helps the show gives you incredible value. So please consider subscribing via fountain as well. Thank you for your time and until next time.

Spread the signal,
earn Bitcoin.

Get your unique referral link when you subscribe.

Learn more →